هذه المقالة يتيمة. ساعد بإضافة وصلة إليها في مقالة متعلقة بها

ذكاء البرمجيات

من أرابيكا، الموسوعة الحرة
اذهب إلى التنقل اذهب إلى البحث

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

التاريخ

اسُخدم ذكاء البرمجيات من قبل كيرك بول لافلر، وهو مهندس أمريكي ورائد أعمال ومستشار ومؤسس شركة Software Intelligence Corporation في عام 1979. في ذلك الوقت كان متعلقًا بشكل أساسي بأنشطة SAS، التي كان خبيرًا فيها منذ عام 1979.[3] في أوائل الثمانينيات شارك فيكتورباسيلي أوراقً مختلفة توضح بالتفصيل منهجية لجمع بيانات هندسة البرمجيات الصحيحة وتقييم تطوير البرمجيات والاختلافات.[4][5] في عام 2004 بدأ بائعو البرمجيات المختصين بتحليل البرمجيات باستخدام المصطلحات كجزء من استراتيجيتهم لتسمية المنتجات وتسويقها. ثم في عام 2010، عرّف أحمد حسن وتاو شي ذكاء البرمجيات بأنها «ممارسة تقدم لممارسي البرمجيات معلومات محدثة وذات صلة لدعم عمليات صنع القرار اليومية ويجب أن تدعم ذكاء البرمجيات عمليات صنع القرار طوال عمر نظام البرمجيات». يستمر بائعو البرمجيات بتعريف ذكاء البرمجيات على أنه «تأثير قوي على ممارسة البرمجيات الحديثة» للعقود القادمة.[6]

القدرات

بسبب التعقيد والنطاق الواسع من المكونات والموضوعات الضمنية في البرمجيات، يجري اشتقاق ذكاء البرمجيات من جوانب مختلفة من البرمجيات:

  • تكوين البرمجيات هو بناء مكونات تطبيقات البرمجيات.[7] المكونات ناتجة عن ترميز البرمجيات، وكذلك تكامل كود المصدر من المكونات الخارجية: المصدر المفتوح ومكونات الطرف الثالث أو الأطر. يمكن دمج المكونات الأخرى باستخدام واجهة برمجة التطبيقات مع المكتبات أو الخدمات.
  • تشير بنية البرمجيات إلى هيكل وتنظيم عناصر النظام والعلاقات والخصائص فيما بينها.
  • عيوب البرامج هي التي تحدد المشكلات التي يمكن أن تسبب الأمن والاستقرار والمرونة والنتائج غير المتوقعة. لا يوجد تعريف قياسي لعيوب البرامج ولكن الأكثر قبولًا هو من شركة MITRE حيث يجري تصنيف العيوب الشائعة على أنها تعداد الضعف الشائع.[8]
  • تقييم درجات البرمجيات هي سمات البرنامج. تاريخيًا، جرى استخلاص تصنيف ومصطلحات الصفات من 9126-3 المنظمة الدولية للتوحيد القياسي والمعيار الدولي لتوحيد المقاييس 25000:2005[9] نموذج الجودة.
  • يشير اقتصاد البرمجيات إلى تقييم موارد البرمجيات في الماضي أو الحاضر أو المستقبل لاتخاذ القرارات والحكم.[10]

المكونات

تشمل منصات ذكاء البرمجيات عددًا متزايدًا من المكونات:

  • محلل الرموز ليكون بمثابة أساس معلومات لمكونات ذكاء البرمجيات الأخرى التي تحدد الكائنات التي تُنشأ بواسطة لغة البرمجة، أو الكائنات الخارجية من المصدر المفتوح، أو كائنات الأطراف الثالثة، أو الأطر، أو واجهة برمجة التطبيقات، أو الخدمات.
  • التصور الرسومي والتخطيط للبنية الداخلية لمنتج البرمجيات أو التطبيق الذي جرى النظر فيه [11] بما في ذلك التبعيات، بدءًا من الحصول على البيانات (التقاط البيانات آليًا وفي الوقت الفعلي وإدخالات المستخدم النهائي) وحتى تخزين البيانات والطبقات المختلفة [12] داخل البرنامج والاقتران بين جميع العناصر.
  • قدرات التنقل ضمن المكونات وسمات تحليل الأثر.
  • قائمة بالعيوب والانتهاكات المعمارية والترميزية ضد أفضل الممارسات الموحدة،[13] يمنع مانع السحابة التنقل إلى بيئة سحابية [14] والمكالمات المتحايلة للبيانات التي تمس أمن البرمجيات وسلامتها.[15]
  • تتماشى درجات الجودة الهيكلية والبرمجية مع معايير الصناعة مثل OMG أو CISQ أو SEI لتقييم الموثوقية والأمان والكفاءة والصيانة وإمكانية التوسع في السحابة أو الأنظمة الأخرى.
  • قياسات وتقدير اقتصاديات البرمجيات بما في ذلك جهد العمل والحجم والديون التقنية.[16]
  • تسمح المراجع الصناعية والمعايير المرجعية بإجراء مقارنات بين نواتج التحليل ومعايير الصناعة.

جانب المستخدم

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

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

على مستوى الحوكمة، يغطي قبول المستخدم لذكاء البرمجيات مجالات مختلفة تتعلق بالأداء الداخلي للنظام وكذلك ناتج النظام. وهي تشمل هذه المتطلبات:

  • شامل: قد يؤدي نقص المعلومات إلى قرار خاطئ أو غير مناسب، كما أنه عامل يؤثر على قبول المستخدم للنظام.[19]
  • دقيق: تعتمد الدقة على كيفية جمع البيانات لضمان رأي وحكم عادلين لا جدال فيهما.[20]
  • الدقة: عادة ما يُحكم على الدقة من خلال مقارنة عدة قياسات من نفس المصادر أو من مصادر مختلفة.[21]
  • قابل للتطوير: يعد نقص قابلية التوسع في صناعة البرمجيات عاملاً حاسمًا يؤدي إلى الفشل.[22]
  • مصداقية: يجب الوثوق بالنواتج والتصديق بها.
  • قابل للنشر وقابل للاستخدام.

التطبيقات

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

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

السوق

الذكاء البرمجي هو نظام رفيع المستوى وقد نما تدريجياً ليغطي التطبيقات المذكورة أعلاه. هناك العديد من الأسواق التي تدفع الحاجة إليها:

  • تحليل محفظة التطبيقات (APA) بهدف تحسين أداء المؤسسة.[26][27]
  • تقييم البرمجيات لإنتاج برمجيات KPI [28] وتحسين الجودة والإنتاجية.
  • تدابير أمن البرمجيات ومرونتها والتحقق من صحتها.
  • تطور البرامج الحاسوبية أو التحديث الموروث، ولا يلزم وضع مخطط لنظم البرمجيات ولا أدوات لتحسين وتيسير التعديلات

مراجع

مراجع

  1. ^ Dąbrowski R. (2012) On Architecture Warehouses and Software Intelligence. In: Kim T., Lee Y., Fang W. (eds) Future Generation Information Technology. FGIT 2012. Lecture Notes in Computer Science, vol 7709. Springer, Berlin, Heidelberg
  2. ^ Ahmed E. Hassan and Tao Xie. 2010. Software intelligence: the future of mining software engineering data. In Proceedings of the FSE/SDP workshop on Future of software engineering research (FoSER '10). ACM, New York, NY, USA, 161–166
  3. ^ "Mr. Kirk Paul Lafler". 21 ديسمبر 2015. مؤرشف من الأصل في 2022-10-30.
  4. ^ Basili، Victor R. (1981). Data collection, validation and analysis. Software Metrics: An Analysis and Evaluation (PDF). MIT Press. ص. 143. ISBN:0-262-16083-8. مؤرشف من الأصل (PDF) في 2023-01-11.
  5. ^ Basili، Victor R.؛ Weiss، David M. (نوفمبر 1984). A Methodology for Collecting Valid Software Engineering Data. IEEE Trans. Softw. Eng. 10, 6 (November 1984). ص. 728–738. DOI:10.1109/TSE.1984.5010301. hdl:1903/7513. مؤرشف من الأصل في 2022-10-30.
  6. ^ Ahmed E. Hassan and Tao Xie. 2010. Software intelligence: the future of mining software engineering data. In Proceedings of the FSE/SDP workshop on Future of software engineering research (FoSER '10). ACM, New York, NY, USA, 161–166. دُوِي:10.1145/1882362.1882397
  7. ^ Nierstrasz, Oscar, and Theo Dirk Meijler. "Research directions in software composition." ACM Computing Surveys 27.2 (1995): 262-264 دُوِي:10.1145/210376.210389
  8. ^ Kanashiro, L., et al. "Predicting software flaws with low complexity models based on static analysis data." Journal of Information Systems Engineering & Management 3.2 (2018): 17 دُوِي:10.20897/jisem.201817
  9. ^ "ISO 25000:2005" (PDF). مؤرشف (PDF) من الأصل في 2013-04-14. اطلع عليه بتاريخ 2013-10-18.
  10. ^ Boehm, Barry W., and Kevin J. Sullivan. "Software economics: a roadmap." Proceedings of the conference on The future of Software engineering. 2000. دُوِي:10.1145/336512.336584
  11. ^ Renato Novais, José Amancio Santos, Manoel Mendonça, Experimentally assessing the combination of multiple visualization strategies for software evolution analysis, Journal of Systems and Software, Volume 128, 2017, pp. 56–71, ISSN 0164-1212, دُوِي:10.1016/j.jss.2017.03.006.
  12. ^ Rolia, Jerome A., and Kenneth C. Sevcik. "The method of layers." IEEE transactions on software engineering 21.8,1995, 689-700,دُوِي:10.1109/32.403785
  13. ^ Software Engineering Rules on code quality. http://it-cisq.org/standards/code-quality-standards/ نسخة محفوظة 2022-10-30 على موقع واي باك مشين.
  14. ^ Balalaie, Armin, , Abbas Heydarnoori, and Pooyan Jamshidi. "Microservices architecture enables devops: Migration to a cloud-native architecture." Ieee Software 33.3 ,May–June 2016, 42-52,دُوِي:10.1109/MS.2016.64
  15. ^ Q. Feng, R. Kazman, Y. Cai, R. Mo and L. Xiao, "Towards an Architecture-Centric Approach to Security Analysis," 2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), Venice, 2016, pp. 221-230, دُوِي:10.1109/WICSA.2016.41.
  16. ^ R. Haas, R. Niedermayr and E. Juergens, "Teamscale: Tackle Technical Debt and Control the Quality of Your Software," 2019 IEEE/ACM International Conference on Technical Debt (TechDebt), Montreal, QC, Canada, 2019, pp. 55-56, دُوِي:10.1109/TechDebt.2019.00016.
  17. ^ Storey MA. (2003) Designing a Software Exploration Tool Using a Cognitive Framework. In: Zhang K. (eds) Software Visualization. The Springer International Series in Engineering and Computer Science, vol 734. Springer, Boston, MA.
  18. ^ Seonah Lee, Sungwon Kang, What situational information would help developers when using a graphical code recommender?, Journal of Systems and Software, Volume 117, 2016, pp. 199–217, ISSN 0164-1212, دُوِي:10.1016/j.jss.2016.02.050.
  19. ^ Linda G. Wallace, Steven D. Sheetz, The adoption of software measures: A technology acceptance model (TAM) perspective, Information & Management, Volume 51, Issue 2, 2014, pp. 249–259, ISSN 0378-7206, دُوِي:10.1016/j.im.2013.12.003
  20. ^ Lippert, S.K., & Forman, H. (2005). Utilization of information technology: examining cognitive and experiential factors of post-adoption behavior. IEEE Transactions on Engineering Management, 52, 363–381.
  21. ^ Rajiv D. Banker and Chris F. Kemerer (1992). Performance Evaluation Metrics for Information Systems Development: A Principal-Agent Model. Information Systems Research, volume 3, number 4, 379–400.
  22. ^ M. Crowne, "Why software product startups fail and what to do about it. Evolution of software product development in startup companies," IEEE International Engineering Management Conference, 2002, pp. 338–343 vol.1. دُوِي:10.1109/IEMC.2002.1038454
  23. ^ Parnas, David Lorge, Precise Documentation: The Key to Better Software, The Future of Software Engineering, 2011, 125–148, دُوِي:10.1007/978-3-642-15187-3_8
  24. ^ "Data and Digital Platform". مؤرشف من الأصل في 2022-10-30.
  25. ^ LaValle S, Lesser E, Shockley R, Hopkins MS and Kruschwitz N (2011) Big data, analytics and the path from insights to value. MIT Sloan Management Review 52 (2), 21–32.
  26. ^ "Definition of Applications Portfolio Analysis (APA) - Gartner Information Technology Glossary". مؤرشف من الأصل في 2022-10-30.
  27. ^ "Effective Strategies to Deliver Sustainable Cost Optimization in Application Services". مؤرشف من الأصل في 2022-11-29.
  28. ^ "About the Automated Function Points Specification Version 1.0". مؤرشف من الأصل في 2022-10-30.
مجلوبة من «https://3rabica.org/index.php?title=ذكاء_البرمجيات&oldid=3463359»