تحليل أثر التغيير

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

أنواع أساليب تحليل الأثر

يمكن تصنيف أساليب تحليل الأثر في ثلاثة أنواع:[3]

  • إمكانية التتبع
  • الاعتمادية
  • التجريبي

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

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

إدارة الحزم وتحليل أثر الاعتمادية

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

  • البرامج النصية مثل whatrequires [10] الخاص بتنسيق حزم آر بي إم وديب

تعليمات المصدر البرمجية وتحليل أثر الاعتمادية

توجد أيضًا التبعيات في تعليمات المصدر البرمجية. ومن بين الأدوات الداعمة التي تظهر هذه التبعيات:

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

المتطلبات وإمكانية تتبع تعليمات المصدر البرمجية

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

تتضمن الأدوات التجارية في هذا المجال Telelogic DOORS وIBM Rational.

انظر أيضًا
  • إدارة التغيير (هندسة)

مراجع
  1. Bohner and Arnold, 1996, pg.3
  2. Pfleeger and Atlee, 2006, pg.526
  3. Kilpinen, 2008
  4. Bohner and Arnold, 1996
  5. Eisner, 2002, pg.236-237
  6. Rajlich, 2000
  7. Ren et al., 2005
  8. Endres and Rombach, 2003, pg.17
  9. Ambler, 2002, pg.244
  10. https://web.archive.org/web/20190804110451/http://www.pixelbeat.org/scripts/whatrequires. مؤرشف من الأصل في 4 أغسطس 2019. الوسيط |CitationClass= تم تجاهله (مساعدة); مفقود أو فارغ |title= (مساعدة)
  11. ohloh, discover, track, and compare open source. نسخة محفوظة 21 أغسطس 2012 على موقع واي باك مشين.
  12. Change Impact Analysis for Requirement Evolution using Use Case Maps, Jameleddine Hassine, Juergen Rilling, Jacqueline Hewitt, Department of Computer Science, Concordia University, 2005. نسخة محفوظة 05 مارس 2016 على موقع واي باك مشين.

    كتابات أخرى
    • Ambler, S. (2002). Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. New York, New York, USA, John Wiley & Sons.
    • Bohner, S.A. and R.S. Arnold, Eds. (1996). Software Change Impact Analysis. Los Alamitos, California, USA, IEEE Computer Society Press.
    • Eisner, H. (2002). Essentials of Project and Systems Engineering Management. New York, New York, USA, John Wiley & Sons.
    • Endres, A. and D. Rombach (2003). A Handbook of Software and Systems Engineering: Empirical Observations, Laws and Theories. New York, New York, USA, Addison-Wesley.
    • Kilpinen, M.S. (2008). The Emergence of Change at the Systems Engineering and Software Design Interface: An Investigation of Impact Analysis. PhD Thesis. University of Cambridge. Cambridge, UK.
    • Pfleeger, S.L. and J.M. Atlee (2006). Software Engineering: Theory and Practice. Upper Saddle River, New Jersey, USA, Prentice Hall.
    • Rajlich, V. (2000). "A Model and a Tool for Change Propagation in Software." ACM SIGSOFT Software Engineering Notes 25(1):72.
    • Ren, X., F. Shah, et al. (2005). Chianti: A Tool for Change Impact Analysis of Java Programs. International Conference on Software Engineering (ICSE 2005), St Louis, Missouri, USA.
    • بوابة علم الحاسوب
    This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.