نظرة عامة على صيانة البرمجيات في هندسة البرمجيات
Software Engineering Maintenance Overview#
صيانة البرمجيات هي جزء مقبول على نطاق واسع من SDLC الآن أيام. إنه يمثل جميع التعديلات والتحديثات التي تتم بعد تسليم منتج البرنامج. هناك عدد من الأسباب التي تتطلب التعديلات ، وبعضها مذكور بإيجاز أدناه:
ظروف السوق - قد تؤدي السياسات ، التي تتغير بمرور الوقت ، مثل الضرائب والقيود المفروضة حديثًا ، وكيفية الحفاظ على مسك الدفاتر ، إلى الحاجة إلى التعديل.
متطلبات العميل - مع مرور الوقت ، قد يطلب العملاء ميزات أو وظائف جديدة في البرنامج.
تعديلات المضيف - إذا كان أي من الأجهزة و / أو النظام الأساسي (مثل نظام التشغيل) من التغييرات المضيف الهدف ، هناك حاجة إلى تغييرات البرنامج للحفاظ على القدرة على التكيف.
تغييرات المنظمة - إذا كان هناك أي تغيير على مستوى العمل في نهاية العميل ، مثل الحد من قوة المنظمة ، قد تنشأ الحاجة إلى تعديل في البرنامج الأصلي ، أو الحصول على شركة أخرى ، أو تنظيم مغامرة في أعمال جديدة.
أنواع الصيانة
في عمر البرنامج ، قد يختلف نوع الصيانة حسب طبيعته. قد تكون مجرد مهمة صيانة روتينية مثل بعض الأخطاء التي اكتشفها بعض المستخدمين أو قد تكون حدثًا كبيرًا بحد ذاته استنادًا إلى حجم الصيانة أو طبيعتها. فيما يلي بعض أنواع الصيانة استنادًا إلى خصائصها:
الصيانة التصحيحية - ويشمل ذلك التعديلات والتحديثات التي تم إجراؤها من أجل تصحيح أو إصلاح المشكلات ، التي يتم اكتشافها بواسطة المستخدم أو يتم الانتهاء منها بواسطة تقارير أخطاء المستخدم.
الصيانة التكييفية - ويشمل ذلك التعديلات والتحديثات المطبقة للحفاظ على تحديث منتج البرنامج وضبطه في عالم التكنولوجيا وبيئة الأعمال المتغير باستمرار.
الصيانة المثالية - ويشمل ذلك التعديلات والتحديثات التي تمت من أجل الحفاظ على البرنامج قابلاً للاستخدام على مدار فترة زمنية طويلة. ويشمل ميزات جديدة ومتطلبات مستخدم جديد لتحسين البرنامج وتحسين موثوقيته وأدائه.
الصيانة الوقائية - ويشمل ذلك التعديلات والتحديثات لمنع حدوث مشاكل في المستقبل في البرنامج. إنه يهدف إلى معالجة المشكلات التي ليست مهمة في هذا الوقت ولكنها قد تسبب مشكلات خطيرة في المستقبل.
تكلفة الصيانة
تشير التقارير إلى أن تكلفة الصيانة مرتفعة. وجدت دراسة عن تقدير صيانة البرمجيات أن تكلفة الصيانة تصل إلى 67٪ من تكلفة دورة عملية البرنامج بالكامل.
في المتوسط ، تبلغ تكلفة صيانة البرامج أكثر من 50٪ من جميع مراحل SDLC. هناك العديد من العوامل التي تؤدي إلى ارتفاع تكاليف الصيانة ، مثل:
العوامل الحقيقية التي تؤثر على تكلفة الصيانة
يعتبر العمر القياسي لأي برنامج حتى 10 إلى 15 عامًا.
لا يمكن للبرامج الأقدم ، التي كان من المفترض أن تعمل على أجهزة بطيئة ذات ذاكرة وسعة تخزين أقل ، مواجهة التحديات التي تواجهها البرامج المحسّنة حديثًا على الأجهزة الحديثة.
مع تقدم التكنولوجيا ، أصبحت صيانة البرامج القديمة مكلفة.
معظم المهندسين الصيانة مبتدئ واستخدام طريقة التجربة والخطأ لتصحيح المشكلة.
في كثير من الأحيان ، يمكن أن تؤدي التغييرات التي تم إجراؤها إلى الإضرار بسهولة بالبنية الأصلية للبرنامج ، مما يجعل من الصعب إجراء أي تغييرات لاحقة.
غالبًا ما تُترك التغييرات بدون وثائق والتي قد تتسبب في المزيد من الصراعات في المستقبل.
عوامل نهاية البرنامج التي تؤثر على تكلفة الصيانة
هيكل برنامج البرمجيات
لغة البرمجة
الاعتماد على البيئة الخارجية
موثوقية الموظفين وتوافرهم
أنشطة الصيانة
يوفر IEEE إطارًا لأنشطة عملية الصيانة المتسلسلة. يمكن استخدامه بطريقة تكرارية ويمكن تمديده بحيث يمكن تضمين العناصر والعمليات المخصصة.
تسير هذه الأنشطة جنبًا إلى جنب مع كل مرحلة من المراحل التالية:
التعريف والتتبع - يشمل الأنشطة المتعلقة بتحديد متطلبات التعديل أو الصيانة. يتم إنشاؤه من قبل المستخدم أو النظام قد الإبلاغ نفسه عن طريق سجلات أو رسائل خطأ ، وهنا ، يتم تصنيف نوع الصيانة أيضا.
تحليل - يتم تحليل التعديل لتأثيره على النظام بما في ذلك الآثار المترتبة على السلامة والأمن. إذا كان التأثير المحتمل شديدًا ، فسيتم البحث عن حل بديل. ثم يتم وضع مجموعة من التعديلات المطلوبة في مواصفات المتطلبات. يتم تحليل تكلفة التعديل / الصيانة ويتم الانتهاء من التقدير.
التصميم - الوحدات النمطية الجديدة ، التي تحتاج إلى استبدال أو تعديل ، مصممة وفقًا لمتطلبات المتطلبات المحددة في المرحلة السابقة. يتم إنشاء حالات الاختبار للتحقق من الصحة والتحقق.
التنفيذ - يتم ترميز الوحدات الجديدة بمساعدة تصميم منظم تم إنشاؤه في خطوة التصميم. من المتوقع أن يقوم كل مبرمج بإجراء اختبار وحدة على التوازي.
اختبار النظام - يتم اختبار التكامل بين الوحدات التي تم إنشاؤها حديثًا. كما يتم إجراء اختبار التكامل بين الوحدات الجديدة والنظام. أخيرًا ، يتم اختبار النظام ككل ، باتباع إجراءات الاختبار التراجعي.
اختبار القبول - بعد اختبار النظام داخليًا ، يتم اختباره للقبول بمساعدة المستخدمين. إذا كان المستخدم في هذه الحالة ، يشكو من بعض المشكلات التي تتم معالجتها أو تتم الإشارة إليه لمعالجتها في التكرار التالي.
التسليم - بعد اختبار القبول ، يتم نشر النظام في جميع أنحاء المؤسسة إما عن طريق حزمة تحديث صغيرة أو تثبيت جديد للنظام. يتم الاختبار النهائي في نهاية العميل بعد تسليم البرنامج.
يتم توفير مرفق التدريب إذا لزم الأمر ، بالإضافة إلى نسخة مطبوعة من دليل المستخدم.
إدارة الصيانة - إدارة التكوين هي جزء أساسي من صيانة النظام. إنه مزود بأدوات التحكم في الإصدار للتحكم في الإصدارات ، أو إدارة النسخ أو التصحيحات.
إعادة هندسة البرمجيات
عندما نحتاج إلى تحديث البرنامج لإبقائه في السوق الحالية ، دون التأثير على وظائفه ، يطلق عليه إعادة هندسة البرمجيات. إنها عملية شاملة حيث تم تغيير تصميم البرنامج وإعادة كتابة البرامج.
يتعذر على البرامج القديمة الاستمرار في التوليف مع أحدث التقنيات المتاحة في السوق. عندما تصبح الأجهزة قديمة ، يصبح تحديث البرنامج صداعًا. حتى إذا أصبح البرنامج قديمًا مع مرور الوقت ، فإن وظائفه لا تفعل ذلك.
على سبيل المثال ، في البداية تم تطوير يونكس بلغة التجميع. عندما ظهرت لغة C إلى حيز الوجود ، تمت إعادة هندسة Unix في لغة C ، لأن العمل بلغة التجميع كان صعبًا.
بخلاف ذلك ، يلاحظ المبرمجون في بعض الأحيان أن بعض أجزاء البرنامج تحتاج إلى صيانة أكثر من غيرها وأنها تحتاج أيضًا إلى إعادة هندسة.
إعادة هندسة العملية
تقرر ما لإعادة هندسة. هل كل البرامج أو جزء منها؟
أداء الهندسة العكسية ، من أجل الحصول على مواصفات البرامج الموجودة.
برنامج إعادة الهيكلة إذا لزم الأمر. على سبيل المثال ، تغيير البرامج الموجهة إلى الوظائف إلى برامج موجهة للكائنات.
إعادة هيكلة البيانات كما هو مطلوب.
تطبيق مفاهيم الهندسة Forward من أجل الحصول على برامج معاد هندستها.
هناك بعض المصطلحات المهمة المستخدمة في إعادة هندسة البرمجيات
الهندسة العكسية
إنها عملية لتحقيق مواصفات النظام من خلال التحليل الشامل وفهم النظام الحالي. يمكن اعتبار هذه العملية كنموذج SDLC عكسي ، على سبيل المثال نحاول الحصول على أعلى مستوى التجريد من خلال تحليل مستويات التجريد أقل.
نظام حالي تم تصميمه مسبقًا ، ولا نعرف عنه شيئًا. يقوم المصممون بعد ذلك بالهندسة العكسية من خلال النظر في الكود ومحاولة الحصول على التصميم. مع التصميم في متناول اليد ، يحاولون إبرام المواصفات. وبالتالي ، الانتقال في الاتجاه المعاكس من التعليمات البرمجية إلى مواصفات النظام.
إعادة هيكلة البرنامج
إنها عملية لإعادة هيكلة البرنامج الحالي وإعادة بنائه. الأمر كله يتعلق بإعادة ترتيب الكود المصدري ، إما بلغة البرمجة نفسها أو من لغة برمجة واحدة إلى أخرى مختلفة. يمكن أن تتضمن إعادة الهيكلة إما إعادة هيكلة الكود المصدر وإعادة هيكلة البيانات أو كليهما.
لا تؤثر إعادة الهيكلة على وظائف البرنامج ولكنها تعزز الموثوقية وسهولة الصيانة. يمكن تغيير مكونات البرنامج ، التي تتسبب في حدوث أخطاء بشكل متكرر ، أو تحديثها مع إعادة الهيكلة.
يمكن إزالة الاعتماد على البرنامج على النظام الأساسي للأجهزة القديمة عن طريق إعادة الهيكلة.
الهندسة الأمامية
الهندسة الأمامية هي عملية للحصول على البرامج المطلوبة من المواصفات الموجودة والتي تم إسقاطها عن طريق الهندسة العكسية. يفترض أنه كان هناك بعض هندسة البرمجيات التي تم القيام بها بالفعل في الماضي.
الهندسة الأمامية هي نفسها عملية هندسة البرمجيات مع اختلاف واحد فقط - يتم تنفيذها دائمًا بعد الهندسة العكسية.
إعادة استخدام المكون
المكون هو جزء من كود البرنامج ، الذي ينفذ مهمة مستقلة في النظام. يمكن أن يكون وحدة صغيرة أو النظام الفرعي نفسه.
مثال
يمكن اعتبار إجراءات تسجيل الدخول المستخدمة على الويب مكونات ، ويمكن اعتبار نظام الطباعة في البرنامج مكونًا من مكونات البرنامج.
تتميز المكونات بتماسك عالٍ للوظائف ومعدل أقل للربط ، أي أنها تعمل بشكل مستقل ويمكن أن تؤدي المهام دون الاعتماد على وحدات أخرى.
في OOP ، تم تصميم الكائنات بحيث تكون محددة جدًا لمخاوفهم ولديها فرص أقل في بعض البرامج الأخرى.
في البرمجة المعيارية ، يتم ترميز الوحدات النمطية لأداء مهام محددة يمكن استخدامها عبر عدد من البرامج الأخرى.
هناك رأسي جديد تمامًا ، يستند إلى إعادة استخدام مكون البرنامج ، ويعرف باسم هندسة البرمجيات القائمة على المكونات (CBSE).
إعادة الاستخدام يمكن القيام به على مختلف المستويات
مستوى التطبيق - حيث يتم استخدام التطبيق بأكمله كنظام فرعي للبرنامج الجديد.
مستوى المكون - حيث يتم استخدام النظام الفرعي للتطبيق.
مستوى الوحدات - حيث يتم إعادة استخدام الوحدات الوظيفية.
توفر مكونات البرنامج واجهات ، والتي يمكن استخدامها لإقامة اتصال بين المكونات المختلفة.
عملية عملاقة
يمكن اعتماد نوعين من الطريقة: إما عن طريق الحفاظ على المتطلبات وتعديل المكونات أو عن طريق الحفاظ على المكونات وتعديل المتطلبات.
مواصفات المتطلبات - يتم تحديد المتطلبات الوظيفية وغير الوظيفية ، والتي يجب أن يلتزم بها منتج البرنامج ، بمساعدة النظام الحالي أو إدخال المستخدم أو كليهما.
التصميم - هذه أيضًا خطوة عملية قياسية لـ SDLC ، حيث يتم تحديد المتطلبات من حيث لغة البرنامج. يتم إنشاء بنية النظام الأساسية ككل وأنظمتها الفرعية.
تحديد المكونات - من خلال دراسة تصميم البرنامج ، يقوم المصممون بفصل النظام بأكمله إلى مكونات أصغر أو أنظمة فرعية. يتحول تصميم البرنامج الكامل إلى مجموعة من مجموعة كبيرة من المكونات تعمل معًا.
Search Suitable Components - يتم إحالة مستودع مكونات البرنامج بواسطة المصممين للبحث عن المكون المطابق ، على أساس الوظيفة ومتطلبات البرنامج المقصودة.
دمج المكونات - يتم تجميع جميع المكونات المتطابقة معًا لتكوينها كبرنامج كامل.