هذه المقالة يتيمة. ساعد بإضافة وصلة إليها في مقالة متعلقة بها
يرجى إضافة وصلات داخلية للمقالات المتعلّقة بموضوع المقالة.
يرجى مراجعة هذه المقالة وإزالة وسم المقالات غير المراجعة، ووسمها بوسوم الصيانة المناسبة.

التدقيق البرمجي

من أرابيكا، الموسوعة الحرة

هذه هي النسخة الحالية من هذه الصفحة، وقام بتعديلها عبود السكاف (نقاش | مساهمات) في 19:53، 5 مايو 2023 (حذف تصنيف:تدقيق، إضافة تصنيف:تدقيق نظم المعلومات باستخدام المصناف الفوري). العنوان الحالي (URL) هو وصلة دائمة لهذه النسخة.

(فرق) → نسخة أقدم | نسخة حالية (فرق) | نسخة أحدث ← (فرق)
اذهب إلى التنقل اذهب إلى البحث

مراجعة تدقيق البرامج ، أو تدقيق البرامج ، هي نوع من مراجعة البرامج التي يقوم فيها مدقق واحد أو أكثر ليسوا أعضاء في مؤسسة تطوير البرمجيات بإجراء "فحص مستقل لمنتج برمجي أو عملية برمجية أو مجموعة عمليات برمجية لتقييمها الامتثال للمواصفات أو المعايير أو الاتفاقات التعاقدية أو معايير أخرى ". [1]

يشير "المنتج البرمجي" في الغالب ، ولكن ليس حصريًا ، إلى نوع من المستندات الفنية. IEEE Std. 1028 [2] يقدم 32 مثال لمنتجات برمجية خاضعة للمراجعة ، بما في ذلك المنتجات الوثائقية مثل الأنواع المختلفة من الخطط والعقود والمواصفات والتصاميم والإجراءات والمعايير والتقارير ، وكذلك المنتجات غير الوثائقية مثل البيانات وبيانات الاختبار والوسائط القابلة للتسليم.

تختلف عمليات تدقيق البرامج عن مراجعات الأقران للبرامج ومراجعات إدارة البرامج من حيث أنها يتم إجراؤها بواسطة موظفين خارجيين ومستقلين عن منظمة تطوير البرمجيات ، وتهتم بتوافق المنتجات أو العمليات ، بدلاً من محتواها التقني ، والجودة الفنية. ، أو الآثار الإدارية.

تم اعتماد مصطلح "مراجعة تدقيق البرامج" هنا لتعيين شكل تدقيق البرامج الموضح في IEEE Std. 1028.

الأهداف والمشاركين

"الغرض من تدقيق البرامج هو تقديم تقييم مستقل لمطابقة منتجات البرامج والعمليات مع اللوائح والمعايير والخطط والإجراءات المعمول بها". [3] يوصى باستخدام الأدوار التالية:

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

مبادئ تدقيق البرامج

يجب أن تجد المبادئ التالية لعملية التدقيق انعكاسًا: [4]

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

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

المراجع العلمية لوجهات نظر التعلم: يجب أن يصف كل تدقيق النتائج بالتفصيل في السياق وأن يسلط الضوء أيضًا على التقدم واحتياجات التطوير بشكل بناء. المدقق ليس والد البرنامج ، ولكنه يعمل في دور المرشد إذا تم اعتبار المدقق جزءًا من دائرة التعلم PDCA (PDCA = Plan-Do-Check-Act). يجب أن يكون هناك بعد وصف نقاط الضعف المكتشفة أيضًا وصفًا للفرص المبتكرة وتطوير الإمكانات.

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

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

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

تصف قائمة مبادئ التدقيق هذه لتطبيقات التشفير - بما يتجاوز أساليب التحليل الفني - خاصة القيم الأساسية التي يجب أخذها في الاعتبار

أدوات

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

مراجع

  1. ^ معهد مهندسي الكهرباء والإلكترونيات Std. 1028-1997, IEEE Standard for Software Reviews, clause 3.2
  2. ^ "IEEE 1028-2008 - IEEE Standard for Software Reviews and Audits". standards.ieee.org. مؤرشف من الأصل في 2023-03-15. اطلع عليه بتاريخ 2019-03-12.
  3. ^ IEEE Std. 10281997, clause 8.1
  4. ^ References to further core audit principles, in: Adams, David / Maier, Ann-Kathrin (2016): BIG SEVEN Study, open source crypto-messengers to be compared - or: Comprehensive Confidentiality Review & Audit of GoldBug, Encrypting E-Mail-Client & Secure Instant Messenger, Descriptions, tests and analysis reviews of 20 functions of the application GoldBug based on the essential fields and methods of evaluation of the 8 major international audit manuals for IT security investigations including 38 figures and 87 tables., URL: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf - English / German Language, Version 1.1, 305 pages, June 2016 (ISBN: DNB 110368003X - 2016B14779) نسخة محفوظة 2023-04-07 على موقع واي باك مشين.