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

📅 آخر تحديث: ٢٣ يوليو ٢٠٢٦
✍️ نُشر في: ٢٣ يوليو ٢٠٢٦
📷 يحتوي على 1 صور
الموسوعة الحرة

في سياق هندسة البرمجيات ، تشير جودة البرمجيات إلى مفهومين مرتبطين ولكنهما متميزان: [ 1 ]

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

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

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

يمكن أن يساعد استخدام الاختبارات الآلية ووظائف اللياقة البدنية في الحفاظ على بعض السمات المتعلقة بالجودة. [ 7 ]

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

تاريخيًا، استُمدّت بنية وتصنيف ومصطلحات السمات والمقاييس المطبقة على إدارة جودة البرمجيات من معيار ISO 9126 ومعيار ISO/IEC 25000 اللاحق . [ 8 ] واستنادًا إلى هذه النماذج (انظر النماذج)، حدد اتحاد جودة برمجيات تكنولوجيا المعلومات (CISQ) خمس خصائص هيكلية رئيسية مرغوبة ضرورية لكي يُحقق البرنامج قيمة تجارية : [ 9 ] الموثوقية، والكفاءة، والأمان، وسهولة الصيانة، والحجم (المناسب). [ 10 ] [ 11 ] [ 12 ]

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

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

تلعب جودة البرمجيات دورًا هامًا في مرحلة إصدار أي مشروع برمجي. فعلى وجه التحديد، تُعد جودة عمليات الإصدار (بما في ذلك عمليات التصحيح ) [ 14 ] [ 15 ] وإدارة التكوين [ 16 ] عناصر أساسية في عملية هندسة البرمجيات الشاملة. [ 17 ] [ 18 ] [ 19 ]

تحفيز

تتأثر جودة البرمجيات بمنظورين رئيسيين على الأقل:

  • إدارة المخاطر : لم يقتصر فشل البرمجيات على مجرد الإزعاج، بل قد تتسبب أخطاء البرمجيات في وفيات بشرية (انظر على سبيل المثال: قائمة أخطاء البرمجيات ). وتراوحت الأسباب بين تصميم واجهات المستخدم الرديء وأخطاء البرمجة المباشرة ، [ 20 ] [ 21 ] [ 22 ] انظر على سبيل المثال حالة طائرة بوينغ 737 أو حالات التسارع غير المقصود [ 23 ] [ 24 ] أو حالات جهاز ثيراك-25 . [ 25 ] وقد أدى ذلك إلى متطلبات لتطوير أنواع معينة من البرمجيات، ولا سيما تاريخيًا، البرمجيات المدمجة في الأجهزة الطبية وغيرها من الأجهزة التي تنظم البنى التحتية الحيوية: "يرى [المهندسون الذين يكتبون البرمجيات المدمجة] برامج جافا تتوقف لمدة ثلث ثانية لإجراء عملية جمع البيانات المهملة وتحديث واجهة المستخدم، فيتخيلون الطائرات وهي تسقط من السماء". [ 26 ] في الولايات المتحدة، ضمن إدارة الطيران الفيدرالية (FAA)، تُقدّم خدمة اعتماد الطائرات التابعة لها برامج حاسوبية وسياسات وإرشادات وتدريبات، مع التركيز على البرمجيات والأجهزة الإلكترونية المعقدة التي تؤثر على المنتج المحمول جوًا (ويُقصد بـ "المنتج" الطائرة أو المحرك أو المروحة). [ 27 ] وتُوفّر معايير الاعتماد، مثل DO-178C و ISO 26262 و IEC 62304 وغيرها، إرشادات في هذا الشأن.
  • إدارة التكاليف : كما هو الحال في أي مجال هندسي آخر، فإن منتجًا أو خدمة برمجية تتميز بجودة برمجية عالية تُقلل من تكاليف صيانتها، وتسهل فهمها، ويمكن تعديلها بفعالية أكبر من حيث التكلفة استجابةً لاحتياجات العمل الملحة. [ 28 ] تُظهر بيانات القطاع أن ضعف جودة البنية التحتية للتطبيقات في تطبيقات الأعمال الأساسية (مثل تخطيط موارد المؤسسات (ERP)، وإدارة علاقات العملاء (CRM)، أو أنظمة معالجة المعاملات الكبيرة في الخدمات المالية) يؤدي إلى تجاوزات في التكاليف والجداول الزمنية، ويُسبب هدرًا في شكل إعادة عمل (انظر مودا (مصطلح ياباني) ). [ 29 ] [ 30 ] [ 31 ] علاوة على ذلك، يرتبط ضعف جودة البنية التحتية ارتباطًا وثيقًا باضطرابات الأعمال ذات التأثير الكبير نتيجة لتلف البيانات، وانقطاع التطبيقات، والاختراقات الأمنية، ومشاكل الأداء. [ 32 ]
    • يقدم مركز CISQ تقارير عن تكلفة التقديرات ذات الجودة الرديئة وتأثيرها على:
    • يقدر تقرير تكلفة اختراق البيانات لعام 2020 الصادر عن شركة IBM أن متوسط ​​التكاليف العالمية لاختراق البيانات هو: [ 35 ]
      • 3.86 مليون دولار

التعريفات

ISO

جودة البرمجيات هي "قدرة منتج برمجي على تلبية المتطلبات". [ 36 ] [ 37 ] بينما يراها البعض الآخر مرادفةً لخلق قيمة للعميل أو خلق قيمة مضافة [ 38 ] [ 39 ] أو حتى مستوى العيوب. [ 40 ] يمكن تقسيم مقاييس جودة البرمجيات إلى ثلاثة أجزاء: جودة العملية، وجودة المنتج التي تشمل الخصائص الداخلية والخارجية، وأخيرًا، جودة الاستخدام، وهي تأثير البرنامج. [ 41 ]

ASQ

تستخدم الجمعية الأمريكية للجودة (ASQ) التعريف التالي: جودة البرمجيات تصف السمات المرغوبة لمنتجات البرمجيات. وهناك منهجان رئيسيان: إدارة العيوب وسمات الجودة. [ 42 ]

المعهد الوطني للمعايير والتكنولوجيا

يغطي ضمان البرمجيات (SA) كلاً من الخاصية والعملية اللازمة لتحقيقها: [ 43 ]

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

مدير المشروع

لا يُعرّف دليل PMBOK الخاص بمعهد إدارة المشاريع "امتداد البرمجيات" "جودة البرمجيات" بحد ذاتها، بل يُعرّف ضمان جودة البرمجيات (SQA) بأنه "عملية مستمرة تُدقق عمليات البرمجيات الأخرى للتأكد من اتباع تلك العمليات (تتضمن على سبيل المثال خطة إدارة جودة البرمجيات)." بينما تعني مراقبة جودة البرمجيات (SCQ) "الاهتمام بتطبيق الأساليب والأدوات والتقنيات لضمان استيفاء منتجات العمل لمتطلبات الجودة لبرنامج قيد التطوير أو التعديل." [ 44 ]

معلومات عامة وتاريخية أخرى

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

ويحدد كيتشنهام وفليجر، في تقريرهما عن تعاليم ديفيد جارفين، خمسة وجهات نظر مختلفة حول الجودة: [ 46 ] [ 47 ]

  • يتناول المنظور المتعالي الجانب الميتافيزيقي للجودة. ففي هذا المنظور، تُعدّ الجودة "شيئًا نسعى إليه كمثال أعلى، ولكن قد لا نتمكن من تحقيقه بالكامل". [ 48 ] يصعب تعريفها، ولكنها تُشبه ما قاله قاضٍ فيدرالي ذات مرة عن الفحش: "أعرفه عندما أراه". [ 49 ]
  • يهتم منظور المستخدم بمدى ملاءمة المنتج لسياق استخدام معين. فبينما يتسم المنظور المتعالي بالتجريد، فإن منظور المستخدم أكثر واقعية، إذ يستند إلى خصائص المنتج التي تلبي احتياجات المستخدم. [ 48 ]
  • يمثل منظور التصنيع الجودة على أنها مطابقة للمتطلبات. ويؤكد هذا الجانب من الجودة معايير مثل ISO 9001، التي تعرف الجودة بأنها "المدى الذي تفي به مجموعة من الخصائص المتأصلة بالمتطلبات" (ISO/IEC 9001 [ 50 ] ).
  • يشير منظور المنتج إلى أنه يمكن تقدير الجودة من خلال قياس الخصائص الجوهرية للمنتج.
  • المنظور الأخير للجودة قائم على القيمة. [ 38 ] يقر هذا المنظور بأن وجهات النظر المختلفة للجودة قد يكون لها أهمية أو قيمة مختلفة بالنسبة لمختلف أصحاب المصلحة.

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

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

لكلمة "الجودة" معانٍ متعددة، يهيمن منها معنيان على استخدامها: 1. الجودة هي خصائص المنتج التي تلبي احتياجات العملاء، وبالتالي تحقق رضاهم عنه. 2. الجودة هي خلو المنتج من العيوب. ومع ذلك، في دليل كهذا، من الأنسب اعتماد تعريف مختصر للجودة بأنه "ملاءمة المنتج للاستخدام". [ 53 ]

اقترح توم ديماركو أن "جودة المنتج تعتمد على مدى تأثيره الإيجابي على العالم". ديماركو، توم (1999). "الإدارة قادرة على جعل الجودة (مستحيلة)". قمة كتر لتكنولوجيا المعلومات.{{cite web}}: مفقود أو فارغ |url=( مساعدة ) يمكن تفسير هذا على أنه يعني أن الجودة الوظيفية ورضا المستخدم أكثر أهمية من الجودة الهيكلية في تحديد جودة البرمجيات.

وهناك تعريف آخر، صاغه جيرالد واينبرغ في كتابه "إدارة جودة البرمجيات: التفكير النظمي"، وهو "الجودة هي قيمة لشخص ما". [ 54 ] [ 55 ]

معانٍ أخرى وخلافات

أحد التحديات في تعريف الجودة هو أن "الجميع يشعرون أنهم يفهمونها" [ 56 ] ويمكن أن تستند تعريفات أخرى لجودة البرمجيات إلى توسيع الأوصاف المختلفة لمفهوم الجودة المستخدم في الأعمال التجارية.

غالبًا ما يُخلط بين جودة البرمجيات وضمان الجودة أو إدارة حل المشكلات [ 57 ] أو مراقبة الجودة [ 58 ] أو DevOps . وهي تتداخل مع هذه المجالات (انظر أيضًا تعريفات PMI)، لكنها تتميز عنها بأنها لا تركز فقط على الاختبار، بل أيضًا على العمليات والإدارة والتحسينات والتقييمات، وما إلى ذلك [ 58 ].

يصعب قياس جودة البرمجيات بطريقة عملية قابلة للتطبيق على عملية اتخاذ القرارات لدى المطورين. وتنشأ هذه الصعوبة جزئياً لأن العديد من سمات الجودة، مثل التعقيد أو سهولة الصيانة، متعددة الأبعاد ولا يمكن قياسها بالكامل بمقياس واحد. [ 59 ]

قياس

على الرغم من أن المفاهيم الواردة في هذا القسم تنطبق على كلٍ من جودة البرمجيات الهيكلية والوظيفية، إلا أن قياس الأخيرة يتم أساسًا من خلال اختبار البرمجيات . [ 60 ] الاختبار وحده لا يكفي: فبحسب إحدى الدراسات، "لا تتجاوز كفاءة المبرمجين الأفراد 50% في اكتشاف الأخطاء في برامجهم. ومعظم أنواع الاختبارات لا تتجاوز كفاءتها 35%. وهذا ما يجعل تحديد جودة البرمجيات أمرًا صعبًا." [ 61 ]

مقدمة

العلاقة بين الخصائص المرغوبة للبرمجيات (على اليمين) والسمات القابلة للقياس (على اليسار)

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

استُمدّت بنية وتصنيف ومصطلحات السمات والمقاييس المطبقة على إدارة جودة البرمجيات من معيار ISO 9126-3 ونموذج الجودة اللاحق ISO/IEC 25000:2005. وينصبّ التركيز الرئيسي على جودة البنية الداخلية. وقد أُنشئت فئات فرعية لمعالجة مجالات محددة مثل بنية تطبيقات الأعمال والخصائص التقنية كوصول البيانات ومعالجتها، أو مفهوم المعاملات.

يتم تمثيل شجرة التبعية بين خصائص جودة البرمجيات وسماتها القابلة للقياس في الرسم البياني على اليمين، حيث تعتمد كل خاصية من الخصائص الخمس المهمة للمستخدم (على اليمين) أو مالك نظام الأعمال على السمات القابلة للقياس (على اليسار):

  • ممارسات هندسة التطبيقات
  • ممارسات البرمجة
  • تعقيد التطبيق
  • الوثائق
  • سهولة الحمل
  • المجلد التقني والوظيفي

تكشف العلاقات بين أخطاء البرمجة وعيوب الإنتاج أن أخطاء الكود الأساسية تمثل 92% من إجمالي الأخطاء في الكود المصدري. لا تمثل هذه المشكلات العديدة على مستوى الكود في نهاية المطاف سوى 10% من العيوب في بيئة الإنتاج. أما ممارسات هندسة البرمجيات السيئة على مستوى البنية، فتمثل 8% فقط من إجمالي العيوب، لكنها تستنزف أكثر من نصف الجهد المبذول في إصلاح المشكلات، وتؤدي إلى 90% من مشكلات الموثوقية والأمان والكفاءة الخطيرة في بيئة الإنتاج. [ 62 ] [ 63 ]

التحليل القائم على الشفرة

تعتمد العديد من مقاييس البرمجيات الحالية على حساب العناصر الهيكلية للتطبيق الناتجة عن تحليل شفرة المصدر للحصول على تعليمات فردية [ 64 ] ورموز [ 65 ] وهياكل تحكم ( التعقيد ) وكائنات. [ 66 ]

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

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

يتضمن قياس خصائص التطبيق الأساسية قياس السمات الهيكلية لبنية التطبيق، وبرمجته، وتوثيقه المضمن، كما هو موضح في الصورة أعلاه. وبالتالي، تتأثر كل خاصية بسمات على مستويات تجريد متعددة في التطبيق، ويجب تضمين جميع هذه السمات في حساب مقياس الخاصية لكي تكون مؤشرًا قيّمًا لنتائج الجودة التي تؤثر على العمل. وقد اقترح بوهم وزملاؤه في شركة TRW (بوهم، 1978) [ 69 ] النهج الطبقي لحساب مقاييس الخصائص الموضح في الشكل أعلاه ، وهو النهج المتبع في معايير سلسلة ISO 9126 و25000. ويمكن قياس هذه السمات من نتائج التحليل الثابت لشفرة مصدر التطبيق. حتى الخصائص الديناميكية للتطبيقات، مثل الموثوقية وكفاءة الأداء، لها جذورها السببية في البنية الثابتة للتطبيق.

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

مصداقية

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

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

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

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

كفاءة

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

يتطلب تقييم كفاءة الأداء التحقق من أفضل ممارسات هندسة البرمجيات والخصائص التقنية التالية على الأقل:

  • ممارسات هندسة التطبيقات
  • التفاعلات المناسبة مع الموارد باهظة الثمن و/أو البعيدة
  • أداء الوصول إلى البيانات وإدارة البيانات
  • إدارة الذاكرة والشبكة ومساحة القرص
  • الامتثال لممارسات البرمجة [ 70 ] ( أفضل ممارسات البرمجة )

حماية

تشمل جودة البرمجيات أمنها . [ 71 ] تنجم العديد من الثغرات الأمنية عن ممارسات برمجة وهندسة سيئة، مثل حقن SQL أو البرمجة النصية عبر المواقع. [ 72 ] [ 73 ] هذه الثغرات موثقة جيدًا في قوائم يحتفظ بها مركز هندسة البرمجيات (CWE)، [ 74 ] ومركز الاستجابة للطوارئ الحاسوبية (CERT) التابع لمعهد هندسة البرمجيات (SEI) في جامعة كارنيجي ميلون. [ 70 ]

يتطلب تقييم الأمن على الأقل التحقق من أفضل ممارسات هندسة البرمجيات والخصائص التقنية التالية:

  • تنفيذ وإدارة عملية تطوير واعية بالأمن ومعززة له، على سبيل المثال دورة حياة تطوير الأمن (مايكروسوفت) أو إطار عمل الهندسة الآمنة لشركة IBM. [ 75 ]
  • ممارسات هندسة التطبيقات الآمنة [ 76 ] [ 77 ]
  • الامتثال للتصميم متعدد الطبقات
  • أفضل الممارسات الأمنية (التحقق من صحة المدخلات، حقن SQL، البرمجة النصية عبر المواقع، التحكم في الوصول، إلخ.) [ 78 ] [ 79 ]
  • ممارسات البرمجة الآمنة والجيدة [ 70 ]
  • معالجة الأخطاء والاستثناءات

قابلية الصيانة

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

يتطلب تقييم قابلية الصيانة التحقق من أفضل ممارسات هندسة البرمجيات والخصائص التقنية التالية:

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

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

مقاس

يتطلب قياس حجم البرمجيات جمع كامل شفرة المصدر بشكل صحيح، بما في ذلك نصوص بنية قاعدة البيانات، وشفرة المصدر لمعالجة البيانات، ورؤوس المكونات، وملفات التكوين، وما إلى ذلك. هناك نوعان أساسيان من أحجام البرمجيات التي يجب قياسها، وهما الحجم التقني (البصمة) والحجم الوظيفي:

  • هناك العديد من طرق تحديد الحجم التقني للبرمجيات التي تم وصفها على نطاق واسع. الطريقة الأكثر شيوعًا لتحديد الحجم التقني هي عدد أسطر التعليمات البرمجية (#LOC) لكل تقنية، وعدد الملفات، والوظائف، والفئات، والجداول، وما إلى ذلك، والتي يمكن من خلالها حساب نقاط الوظائف العكسية؛
  • تُعدّ تحليلات نقاط الوظائف الطريقة الأكثر شيوعًا لقياس حجم البرمجيات . تقيس هذه التحليلات حجم البرمجيات المُخرَجة من منظور المستخدم، حيث تُحدَّد بناءً على متطلباته، وتُقدِّم تمثيلًا دقيقًا لحجم البرمجيات بالنسبة للمطور/المُقدِّر، بالإضافة إلى قيمتها (الوظائف المطلوب تقديمها)، كما تعكس وظائف الأعمال المُقدَّمة للعميل. تتضمن هذه الطريقة تحديد وترجيح المدخلات والمخرجات ومخازن البيانات التي يُمكن للمستخدم تمييزها. بعد ذلك، تُصبح قيمة الحجم متاحة للاستخدام مع العديد من المقاييس لتقييم أداء البرمجيات وتسليمها (تكلفة التطوير لكل نقطة وظيفة، العيوب المُخرَجة لكل نقطة وظيفة، نقاط الوظائف لكل شهر عمل).

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

منذ ظهور تحليل نقاط الوظائف، تطورت عدة أشكال منه، وتوسعت مجموعة تقنيات قياس حجم الوظائف لتشمل مقاييس مثل COSMIC وNESMA ونقاط حالات الاستخدام وFP Lite ونقاط الوظائف المبكرة والسريعة، ومؤخرًا نقاط القصص. تتمتع نقاط الوظائف بتاريخ من الدقة الإحصائية، وقد استُخدمت كوحدة قياس عمل شائعة في العديد من مشاريع إدارة تطوير التطبيقات (ADM) أو مشاريع التعهيد، حيث تُعتبر بمثابة "العملة" التي تُقدم بها الخدمات ويُقاس بها الأداء.

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

يُعرّف مركز CISQ عملية تحديد حجم البرمجيات بأنها تقدير حجمها لدعم تقدير التكاليف، وتتبع التقدم، أو غيرها من أنشطة إدارة مشاريع البرمجيات ذات الصلة. ويُستخدم معياران: نقاط الوظائف الآلية لقياس الحجم الوظيفي للبرمجيات، ونقاط التحسين الآلية لقياس حجم كلٍ من التعليمات البرمجية الوظيفية وغير الوظيفية في مقياس واحد. [ 84 ]

تحديد أخطاء البرمجة الحرجة

أخطاء البرمجة الحرجة هي ممارسات معمارية و/أو برمجية سيئة محددة تؤدي إلى أعلى مخاطر تعطيل الأعمال، سواء على المدى القريب أو البعيد. [ 85 ]

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

يمكن أيضًا تصنيف أخطاء البرمجة الحرجة وفقًا لخصائص CISQ. مثال أساسي أدناه:

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

نماذج الجودة التشغيلية

تُروّج المقترحات الحديثة لنماذج الجودة، مثل Squale وQuamoco [ 86 ] ، لدمجٍ مباشر بين تعريف سمات الجودة وقياسها. فمن خلال تبسيط سمات الجودة، أو حتى إضافة طبقاتٍ أخرى، تصبح سمات الجودة المعقدة والمجردة (مثل الموثوقية أو سهولة الصيانة) أكثر قابليةً للإدارة والقياس. وقد طُبّقت هذه النماذج في سياقاتٍ صناعية، لكنها لم تحظَ بانتشارٍ واسع.

انظر أيضاً

للمزيد من القراءة

مراجع

ملحوظات

  1. ↑ فاغنر، ستيفان؛ غويب، أندرياس؛ هاينمان، لارس؛ كلاس، مايكل؛ لامباسونا، كونستانزا؛ لوخمان، كلاوس؛ ماير، ألويس؛ بلوش، راينهولد؛ سيدل، أندرياس (2015). "نماذج جودة المنتج التشغيلية وتقييمها: منهج كواموكو" (ملف PDF) . تكنولوجيا المعلومات والبرمجيات . 62 : 101-123 . arXiv : 1611.09230 . doi : 10.1016/j.infsof.2015.02.009 . S2CID 10992384 . 
  2. ↑ "التعلم من التاريخ: حالة هندسة متطلبات البرمجيات - مجلة هندسة المتطلبات" . التعلم من التاريخ: حالة هندسة متطلبات البرمجيات - مجلة هندسة المتطلبات . تاريخ الاسترجاع: ٢٥ فبراير ٢٠٢١ .
  3. ↑ بريسمان، روجر س. (2005). هندسة البرمجيات: منهج عملي ( الطبعة الدولية السادسة). ماكجرو هيل للتعليم. ص 388. ISBN   0071267824.
  4. ↑ "حول مواصفات مقاييس جودة شفرة المصدر الآلية، الإصدار 1.0" . www.omg.org . تاريخ الاطلاع: 25 فبراير 2021 .
  5. ↑ "كيفية إجراء اختبار شامل من البداية إلى النهاية" . smartbear.com . تم الاطلاع عليه بتاريخ 25 فبراير 2021 .
  6. ↑ "كيفية تقديم أنظمة تكنولوجيا معلومات مرنة وآمنة وفعّالة وسهلة التغيير بما يتماشى مع توصيات CISQ" (ملف PDF) . مؤرشف (PDF) من الأصل بتاريخ 28 ديسمبر 2013. تم الاطلاع عليه بتاريخ 18 أكتوبر 2013 .
  7. ↑ أساسيات هندسة البرمجيات: منهج هندسي . دار نشر أورايلي. 2020. رقم ISBN 978-1492043454.
  8. ↑ "ISO/IEC 25010:2011" . المنظمة الدولية للمقاييس . تم الاطلاع عليه بتاريخ 23 فبراير 2021 .
  9. ↑ أرمور، فيليب ج. (2012-06-01). "مقياس للتحكم" . مجلة اتصالات رابطة مكائن ​​الحوسبة . 55 (6): 26-28 . doi : 10.1145/2184319.2184329 . ISSN 0001-0782 . S2CID 6059054 .  
  10. ↑ فواس، ج. (نوفمبر 2011). "سر نجاح البرمجيات: "الخصائص" [جودة البرمجيات]". مجلة IEEE للبرمجيات . 21 (6): 14-15 . doi : 10.1109/MS.2004.54 . ISSN 1937-4194 . 
  11. ↑ "معايير جودة الكود | CISQ - اتحاد جودة المعلومات والبرمجيات" . www.it-cisq.org . تاريخ الاسترجاع: 25 فبراير 2021 .
  12. ↑ "معايير تحديد حجم البرمجيات | CISQ - اتحاد جودة المعلومات والبرمجيات" . www.it-cisq.org . تاريخ الاسترجاع: 25 فبراير 2021 .
  13. ↑ ج. بونيت، ج. دولنر، مؤرشف في 27-04-2014 على موقع Wayback Machine ، "مراقبة جودة الكود ونشاط التطوير بواسطة خرائط البرمجيات". وقائع ورشة عمل IEEE ACM ICSE حول إدارة الديون التقنية، الصفحات 9-16، 2011.
  14. ↑ "دليل التدقيق التكنولوجي العالمي الصادر عن معهد المدققين الداخليين: إدارة تغيير تكنولوجيا المعلومات: أمر بالغ الأهمية لنجاح المؤسسة" . na.theiia.org . تم الاطلاع عليه بتاريخ 26 فبراير 2021 .
  15. ↑ بورسييه، جيروم (11 يناير 2018). "تداعيات ثغرتي ميلتداون وسبكتر: استمرار مشاكل الترقيع" . مختبرات مالويربايتس . تم الاطلاع عليه بتاريخ 26 فبراير 2021 .
  16. ↑ "أفضل الممارسات لتحديثات البرامج - مدير التكوين" . docs.microsoft.com . تم الاطلاع عليه بتاريخ 26-02-2021 .
  17. ↑ رايت، هايروم ك. (25 أغسطس/آب 2009). "عمليات هندسة الإصدار، والنماذج، والمقاييس" . وقائع ندوة الدكتوراه لـ ESEC/FSE حول ندوة الدكتوراه . ندوة ESEC/FSE للدكتوراه 2009. أمستردام، هولندا: رابطة آلات الحوسبة. ص 27-28 . doi : 10.1145/1595782.1595793 . ISBN  978-1-60558-731-8. S2CID 10483918 . 
  18. ^ فان دير هوك، أندريه؛ هول، ريتشارد س. هايمبجنر، دينيس؛ وولف، الكسندر L. (نوفمبر 1997). "إدارة إصدار البرامج" . ACM SIGSOFT ملاحظات هندسة البرمجيات . 22 (6): 159-175 . دوى : 10.1145 / 267896.267909 . ISSN 0163-5948 . 
  19. ↑ ساتون، مايك؛ مور، تيم (30 يوليو 2008). "7 طرق لتحسين إدارة إصدار البرامج" . CIO . تم الاسترجاع في 26 فبراير 2021 .
  20. ↑ كلارك، ميتشل (24 فبراير 2021). "شركة iRobot تقول إنها ستستغرق بضعة أسابيع قبل أن تتمكن من إصلاح فوضى تحديث برنامج Roomba الأخير" . ذا فيرج . تم الاطلاع عليه بتاريخ 25 فبراير 2021 .
  21. ↑ "أهم 25 خطأ برمجي" . www.sans.org . تاريخ الاسترجاع: 25 فبراير 2021 .
  22. ↑ ""إعادة تشغيلها كل 149 ساعة" حلٌّ مثير للقلق لخلل برمجي في طائرة إيرباص تبلغ قيمتها 300 مليون دولار . جيزمودو . 30 يوليو 2019. تاريخ الاطلاع: 25 فبراير 2021 .
  23. ↑ "ميسرا سي، تويوتا ونهاية المهمة إكس" . تم الاطلاع عليه بتاريخ 25-02-2021 .
  24. ↑ "تحديث حول تويوتا والتسارع غير المقصود « بارك كود"" . embeddedgurus.com . تم الاطلاع عليه بتاريخ 25-02-2021 . 
  25. ↑ الأجهزة الطبية: جهاز ثيراك-25* مؤرشف بتاريخ 16 فبراير 2008 في أرشيف الإنترنت ، نانسي ليفيسون، جامعة واشنطن
  26. ↑ برمجيات مضمنة مؤرشفة بتاريخ 2010-07-05 على موقع Wayback Machine ، إدوارد أ. لي، ستُنشر في Advances in Computers ( مارفن فيكتور زيلكوفيتز ، محرر)، المجلد 56، دار النشر الأكاديمية، لندن، 2002، مُنقحة من مذكرة UCB ERL رقم M01/26، جامعة كاليفورنيا، بيركلي، كاليفورنيا 94720، الولايات المتحدة الأمريكية، 1 نوفمبر 2001
  27. ↑ "برامج اعتماد الطائرات والأجهزة الإلكترونية المحمولة جواً" . مؤرشف من الأصل في 4 أكتوبر 2014. تم الاطلاع عليه في 28 سبتمبر 2014 .
  28. ↑ "تكلفة رداءة جودة البرمجيات في الولايات المتحدة: تقرير 2020 | CISQ - اتحاد جودة المعلومات والبرمجيات" . www.it-cisq.org . تاريخ الاطلاع: 25 فبراير 2021 .
  29. ↑ "ما هو الهدر؟ | تحالف أجايل" . تحالف أجايل | . 20 أبريل 2016. تم الاطلاع عليه بتاريخ 25 فبراير 2021 .
  30. ↑ ماتيسون، سكوت (26 يناير 2018). "تقرير: تسبب عطل في البرمجيات بخسائر مالية بلغت 1.7 تريليون دولار في عام 2017" . TechRepublic . تاريخ الاسترجاع: 25 فبراير 2021 .
  31. ↑ كوهان، رايان (16 نوفمبر 2017). "التكلفة المالية لأخطاء البرمجيات" . ميديوم . تم الاسترجاع في 25 فبراير 2021 .
  32. ↑ إيلوف، جان؛ بيلا، مادلين بيهينا (2018)، "أعطال البرمجيات: نظرة عامة" ، تحقيق في أعطال البرمجيات ، تشام: دار نشر سبرينغر الدولية، ص 7-24 ، doi : 10.1007/978-3-319-61334-5_2 ، ISBN  978-3-319-61333-8تم الاطلاع عليه بتاريخ 25 فبراير 2021
  33. ↑ "كلّفت رداءة جودة البرمجيات الشركات تريليوني دولار العام الماضي وعرّضت الأمن للخطر" . CIO Dive . تم الاطلاع عليه بتاريخ 26 فبراير 2021 .
  34. ↑ "تقدّر دراسة CISQ التي ترعاها شركة Synopsys تكلفة رداءة جودة البرمجيات في الولايات المتحدة بـ 2.08 تريليون دولار في عام 2020" . finance.yahoo.com . تاريخ الاطلاع: 26 فبراير 2021 .
  35. ↑ "تقرير تكلفة اختراق البيانات 2020 | آي بي إم" . www.ibm.com . 2020. تاريخ الاطلاع: 8 مارس 2021 .
  36. ↑ "ISO - عائلة ISO 9000 - إدارة الجودة" . ISO . تم الاطلاع عليه بتاريخ 24-02-2021 .
  37. ↑ "ISO/IEC/IEEE 24765:2017" . المنظمة الدولية للمقاييس . تم الاطلاع عليه بتاريخ 24-02-2021 .
  38. 1 2 "إتقان برمجيات السيارات" . www.mckinsey.com . تم الاطلاع عليه بتاريخ 25-02-2021 .
  39. ↑ "ISO/IEC 25010:2011" . المنظمة الدولية للمقاييس . تم الاطلاع عليه بتاريخ 24-02-2021 .
  40. ↑ والاس، د. ر. (2002). "نمذجة موثوقية البرمجيات العملية". وقائع ورشة عمل ناسا غودارد السنوية السادسة والعشرين لهندسة البرمجيات . غرينبيلت، ماريلاند، الولايات المتحدة الأمريكية: جمعية مهندسي الكهرباء والإلكترونيات. ص 147-155 . doi : 10.1109/SEW.2001.992668 . ISBN  978-0-7695-1456-7. S2CID 57382117 . 
  41. ↑ "ISO/IEC 25023:2016" . المنظمة الدولية للمقاييس . تم الاطلاع عليه بتاريخ 2023-11-06 .
  42. ↑ "ما هي جودة البرمجيات؟ | الجمعية الأمريكية للجودة" . asq.org . تم الاطلاع عليه بتاريخ 24-02-2021 .
  43. ↑ "الصفحة الرئيسية لمشروع SAMATE - مقاييس ضمان جودة البرمجيات وتقييم الأدوات" . المعهد الوطني للمعايير والتكنولوجيا (NIST) . 3 فبراير 2021. تاريخ الاسترجاع : 26 فبراير 2021 .
  44. ↑ ملحق برمجي لدليل PMBOK . معهد إدارة المشاريع ( الطبعة الخامسة). نيوتاون سكوير، بنسلفانيا. 2013. ISBN  978-1-62825-041-1. OCLC 959513383 . {{cite book}}: صيانة CS1: موقع الناشر مفقود ( رابط ) صيانة CS1: أخرى ( رابط )
  45. ↑ شيوارت، والتر أ. (2015). الرقابة الاقتصادية على جودة المنتج المصنّع . [مكان النشر غير محدد]: مارتينو فاين بوكس. ISBN 978-1-61427-811-5. OCLC 1108913766 . 
  46. ↑ كيتشنهام، ب .؛ بفليجر، إس إل (يناير 1996). "جودة البرمجيات: الهدف المنشود [قسم القضايا الخاصة]". مجلة IEEE للبرمجيات . 13 (1): 12-21 . رمز Bibcode : 1996ISoft..13a..12K . doi : 10.1109/52.476281 . ISSN 1937-4194 . 
  47. ↑ غارفين، ديفيد أ. (1988). إدارة الجودة : الميزة الاستراتيجية والتنافسية . نيويورك: فري برس. ISBN  0-02-911380-6. OCLC 16005388 . 
  48. 1 2 ب. كيتشنهام وس. فليجر، "جودة البرمجيات: الهدف المراوغ"، IEEE Software، المجلد 13، العدد 1، الصفحات 12-21، 1996.
  49. ↑ كان، ستيفن هـ. (2003). المقاييس والنماذج في هندسة جودة البرمجيات ( الطبعة الثانية). بوسطن: أديسون-ويسلي. ISBN  0-201-72915-6. OCLC 50149641 . 
  50. ↑ المنظمة الدولية للتوحيد القياسي، "ISO/IEC 9001: أنظمة إدارة الجودة - المتطلبات"، 1999.
  51. ↑ دبليو إي ديمينغ، "الخروج من الأزمة: الجودة والإنتاجية والموقع التنافسي". مطبعة جامعة كامبريدج، 1988.
  52. ↑ إيه في فيجنباوم، "التحكم الشامل في الجودة"، ماكجرو هيل، 1983.
  53. ↑ JM Juran, "Juran's Quality Control Handbook", McGraw-Hill, 1988.
  54. ↑ واينبرغ، جيرالد م. (1991). إدارة جودة البرمجيات: المجلد 1، التفكير النظمي . نيويورك، نيويورك: دار دورست هاوس. ISBN 0-932633-22-6. OCLC 23870230 . 
  55. ↑ واينبرغ، جيرالد م. (1993). إدارة جودة البرمجيات: المجلد 2، القياس من الدرجة الأولى . نيويورك، نيويورك: دار دورست هاوس. ISBN 0-932633-22-6. OCLC 23870230 . 
  56. ↑ كروسبي، ب.، الجودة مجانية ، ماكجرو هيل، 1979
  57. ↑ "SUP.9 – إدارة حل المشكلات - شركة كوجلر ماج" . www.kuglermaag.com . تاريخ الاسترجاع: 25 فبراير 2021 .
  58. 1 2 هوبت (29 نوفمبر 2019). "كثيراً ما تستخدم المنظمات مصطلحي "ضمان الجودة" (QA) مقابل "مراقبة الجودة" (QC)..." . ميديوم . تم الاطلاع عليه بتاريخ 25 فبراير 2021 .
  59. ↑ تيمبيرو، إيوان؛ رالف، بول (2026-03-16). "جعل مقاييس البرمجيات مفيدة". arXiv : 2603.16012 [ cs.SE ].
  60. ↑ والاس، د.؛ واتسون، أ.هـ.؛ مكابي، ت.ج. (1996-08-01). "الاختبار المنظم: منهجية اختبار باستخدام مقياس التعقيد الحلقي" . المعهد الوطني للمعايير والتكنولوجيا .
  61. ↑ بيليرز، ريتشارد. "ما هي جودة الكود؟ وكيفية تحسين جودة الكود" . شركة بيرفورس للبرمجيات . تم الاطلاع عليه بتاريخ 28 فبراير 2021 .
  62. ↑ "ورقة بيضاء من OMG | CISQ - اتحاد جودة المعلومات والبرمجيات" . www.it-cisq.org . تم الاطلاع عليها بتاريخ 26 فبراير 2021 .
  63. ↑ "كيفية تقديم أنظمة تكنولوجيا معلومات مرنة وآمنة وفعّالة وسريعة الاستجابة بما يتماشى مع توصيات CISQ - ورقة بيضاء | مجموعة إدارة الكائنات" (ملف PDF) . مؤرشف (PDF) من الأصل بتاريخ 28 ديسمبر 2013. تم الاطلاع عليه بتاريخ 18 أكتوبر 2013 .
  64. ↑ "قياس حجم البرمجيات: إطار عمل لحساب عبارات المصدر" . resources.sei.cmu.edu . 31 أغسطس 1992. تم الاطلاع عليه بتاريخ 24 فبراير 2021 .
  65. ↑ هالستيد، موريس هـ. (1977). عناصر علم البرمجيات (سلسلة أنظمة التشغيل والبرمجة) . الولايات المتحدة الأمريكية: إلسيفير ساينس إنك. ISBN 978-0-444-00205-1.
  66. ↑ شيدامبر، إس آر؛ كيميرر، سي إف (يونيو 1994). "مجموعة مقاييس لتصميم البرمجيات الموجهة للكائنات". معاملات IEEE في هندسة البرمجيات . 20 (6): 476-493 . Bibcode : 1994ITSEn..20..476C . doi : 10.1109/32.295895 . hdl : 1721.1/48424 . ISSN 1939-3520 . S2CID 9493847 .  
  67. ↑ نايجارد، مايكل (2007). أطلقها! . شركة أورايلي ميديا ​​سفاري ( الطبعة الأولى). براغماتيك بوكشيلف. ISBN  978-0978739218. OCLC 1102387436 . 
  68. ↑ "CWE - تعداد نقاط الضعف الشائعة" . cwe.mitre.org . مؤرشف من الأصل بتاريخ 10-05-2016 . تم الاطلاع عليه بتاريخ 20-05-2016 .
  69. ↑ بوهم، ب.، براون، جيه آر، كاسبار، إتش.، ليبو، إم.، ماكلويد، جي جي، وميريت، إم جي (1978). خصائص جودة البرمجيات. نورث هولاند.
  70. 1 2 3 "معايير ترميز SEI CERT - ترميز CERT الآمن - Confluence" . wiki.sei.cmu.edu . تم الاطلاع عليه بتاريخ 24-02-2021 .
  71. ↑ "جودة الكود وأمن الكود: ما العلاقة بينهما؟ | سينوبسيس" . مدونة سلامة البرمجيات . 24 مايو 2019. تاريخ الاسترجاع: 9 مارس 2021 .
  72. ↑ "تقرير تكلفة اختراق البيانات 2020 | آي بي إم" . www.ibm.com . 2020. تاريخ الاطلاع: 9 مارس 2021 .
  73. ↑ "النقاط الرئيسية المستخلصة من تقرير تكلفة اختراق البيانات لعام 2020" . بلوفين . 27 أغسطس 2020. تاريخ الاطلاع: 9 مارس 2021 .
  74. ↑ "CWE - تعداد نقاط الضعف الشائعة" . Cwe.mitre.org. مؤرشف من الأصل بتاريخ 14-10-2013 . تم الاطلاع عليه بتاريخ 18-10-2013 .
  75. ↑ الأمن في التطوير: إطار عمل IBM للهندسة الآمنة | كتب IBM الحمراء . 30-09-2016.
  76. ↑ بنية أمن المؤسسات باستخدام حلول IBM Tivoli الأمنية | IBM Redbooks . 2016-09-30.
  77. ↑ "تعريفات تصميم البنية الآمنة | وكالة الأمن السيبراني وأمن البنية التحتية (CISA)" . us-cert.cisa.gov . تم الاطلاع عليه بتاريخ 9 مارس 2021 .
  78. ↑ "مؤسسة OWASP | مؤسسة المصادر المفتوحة لأمن التطبيقات" . owasp.org . تم الاطلاع عليه بتاريخ 24-02-2021 .
  79. ↑ "أفضل 25 موقعًا في CWE" . Sans.org . تم الاطلاع عليه بتاريخ 18-10-2013 .
  80. ↑ IfSQ المستوى 2 معيار المستوى التأسيسي لشفرة مصدر برنامج الكمبيوتر مؤرشف في 2011-10-27 في Wayback Machine ، الطبعة الثانية أغسطس 2008، غراهام بولتون، ستيوارت جونستون، IfSQ، معهد جودة البرمجيات.
  81. ↑ فاولر، مارتن (14 أكتوبر 2009). "مربع الدين التقني" . مؤرشف من الأصل في 2 فبراير 2013. تم الاطلاع عليه في 4 فبراير 2013 .
  82. ↑ "جودة الكود: مصدر قلق للشركات، والنتائج النهائية، والمبرمجين المتعاطفين" . ستاك أوفرفلو . 18 أكتوبر 2021. تم الاطلاع عليه بتاريخ 5 ديسمبر 2023 .
  83. ↑ براوز، كريستيان؛ دورديك، زويا (3 يونيو 2012). "التصميم المعماري والتوثيق: هدر في التطوير الرشيق؟". المؤتمر الدولي لعام 2012 حول عمليات البرمجيات والأنظمة (ICSSP) . جمعية مهندسي الكهرباء والإلكترونيات (IEEE). الصفحات 130-134 . doi : 10.1109/ICSSP.2012.6225956 . ISBN  978-1-4673-2352-9. S2CID 15216552 . 
  84. ↑ "معايير تحديد حجم البرمجيات | CISQ - اتحاد جودة المعلومات والبرمجيات" . www.it-cisq.org . تاريخ الاسترجاع: 28 يناير 2021 .
  85. ↑ "لماذا تفشل البرمجيات؟" . مجلة IEEE Spectrum: أخبار التكنولوجيا والهندسة والعلوم . 2 سبتمبر 2005. تاريخ الاسترجاع: 20 مارس 2021 .
  86. ↑ فاغنر، ستيفان؛ غويب، أندرياس؛ هاينمان، لارس؛ كلاس، مايكل؛ لامباسونا، كونستانزا؛ لوخمان، كلاوس؛ ماير، ألويس؛ بلوش، راينهولد؛ سيدل، أندرياس (2015). "نماذج جودة المنتج التشغيلية وتقييمها: منهج كواموكو" (ملف PDF) . تكنولوجيا المعلومات والبرمجيات . 62 : 101-123 . arXiv : 1611.09230 . doi : 10.1016/j.infsof.2015.02.009 . S2CID 10992384 . 
  87. ↑ سوريانارايانا، جيريش (2015). "عملية تطوير البرمجيات مقابل جودة التصميم: صراع محتدم؟" . مجلة IEEE للبرمجيات . 32 (4): 7-11 . Bibcode : 2015ISoft..32d...7S . doi : 10.1109/MS.2015.87 . S2CID 9226051 . 
  88. ↑ "محترف جودة البرمجيات | الجمعية الأمريكية للجودة" . asq.org . تم الاطلاع عليه بتاريخ 28 يناير 2021 .
  89. ↑ "مجلة جودة البرمجيات" . سبرينغر . تم الاطلاع عليه بتاريخ 28-01-2021 .

فهرس

  • ألبريشت، أ. ج. (1979)، قياس إنتاجية تطوير التطبيقات. في وقائع ندوة SHARE/GUIDE IBM المشتركة لتطوير التطبيقات. ، IBM
  • بن مناحيم، م.؛ مارليس، ج. س. (1997)، جودة البرمجيات: إنتاج برمجيات عملية ومتسقة ، دار نشر تومسون للكمبيوتر
  • Boehm, B.; Brown, JR; Kaspar, H.; Lipow, M.; MacLeod, GJ; Merritt, MJ (1978), Characteristics of Software Quality , North-Holland.
  • شيدامبر، إس.؛ كيميرر، سي. (1994)، مجموعة مقاييس للتصميم الموجه للكائنات. معاملات IEEE في هندسة البرمجيات، 20 (6) ، ص 476-493 
  • إيبرت، كريستوف؛ دومكي، راينر، قياس البرمجيات: التأسيس - الاستخراج - التقييم - التنفيذ ، نسخة كيندل، ص  91
  • غارموس، د.؛ هيرون، د. (2001)، تحليل نقاط الوظائف ، أديسون ويسلي
  • هالستيد، م. إي. (1977)، عناصر علم البرمجيات ، إلسيفير نورث هولاند
  • هاميل، م.؛ غوسيفا-بوبستويانوفا، ك. (2009)، الأخطاء الشائعة في بيانات أعطال البرمجيات وفشلها. معاملات IEEE لهندسة البرمجيات، 35 (4) ، ص 484-496 
  • جاكسون، دي جيه (2009)، طريق مباشر إلى برامج موثوقة. اتصالات ACM، 52 (4).
  • مارتن، ر. (2001)، "إدارة الثغرات الأمنية في الأنظمة الشبكية"، مجلة الكمبيوتر ، 34 (11)، IEEE Computer.: 32، Bibcode : 2001Compr..34k..32M ، doi : 10.1109/2.963441
  • مكابي، ت. (ديسمبر 1976)، مقياس التعقيد. معاملات IEEE في هندسة البرمجيات
  • ماكونيل، ستيف (1993)، كود كومبليت (  الطبعة الأولى)، مطبعة مايكروسوفت
  • Nygard, MT (2007), Release It! Design and Deploy Production Ready Software , The Pragmatic Programmers.
  • بارك، ر. إي. (1992)، قياس حجم البرمجيات: إطار عمل لحساب عبارات المصدر. (CMU/SEI-92-TR-020). ، معهد هندسة البرمجيات، جامعة كارنيجي ميلون
  • بريسمان، روجر س. (2005). هندسة البرمجيات: منهج عملي (  الطبعة الدولية السادسة). ماكجرو هيل للتعليم. ISBN 0071267824.
  • سبينليس، د. (2006)، جودة الكود ، أديسون ويسلي