|
تضامنًا مع حق الشعب الفلسطيني |
النظام القديم (حاسوب)
النظام القديم وبالانجليزية (legacy system) في الحوسبة هو طريقة أو تقنية أو نظام كمبيوتر أو برنامج تطبيق قديم، «من نظام كمبيوتر سابق أو قديم»، [1] ومع ذلك لا يزال قيد الاستخدام. غالبًا ما تعني الإشارة إلى نظام ما على أنه «تراث» أنه مهد الطريق للمعايير التي ستتبعه. يمكن أن يعني هذا أيضًا أن النظام قديم أو بحاجة إلى استبدال.
الكود القديم هو كود مصدر أقدم للكمبيوتر. يمكن أن يشير ببساطة إلى قاعدة التعليمات البرمجية الحالية للمؤسسة والتي تمت كتابتها على مدى سنوات عديدة، أو قد تشير ضمنًا إلى قاعدة بيانات قديمة أو تدعم شيئًا قديمًا. الكود طويل العمر عرضة لتعفن البرامج، حيث قد تتطلب التغييرات في بيئة وقت التشغيل أو البرامج أو الأجهزة المحيطة صيانة أو محاكاة من نوع ما لمواصلة العمل. قد يكون الرمز القديم موجودًا لدعم الأجهزة القديمة، أو نظام قديم منفصل، أو عميل قديم يستخدم ميزة قديمة أو إصدار برنامج.
بينما يشير المصطلح عادةً إلى التعليمات البرمجية المصدر، فإنه يمكن أن ينطبق أيضًا على التعليمات البرمجية القابلة للتنفيذ التي لم تعد تعمل على إصدار لاحق من النظام، أو تتطلب طبقة توافق للقيام بذلك. من الأمثلة على ذلك تطبيق Macintosh الكلاسيكي الذي لن يعمل أصلاً على نظام التشغيل Mac OS X ، ولكنه يعمل داخل بيئة Classic ، أو تطبيق Win16 يعمل على Windows XP باستخدام ميزة Windows على Windows في XP.
من الأمثلة على الأجهزة القديمة المنافذ القديمة مثل منافذ PS / 2 و VGA ووحدات المعالجة المركزية ذات مجموعات التعليمات القديمة غير المتوافقة. تتضمن الأمثلة في البرامج القديمة تنسيقات الملفات القديمة مثل.swf لـ Adobe Shockwave أو.123 لـ Lotus 1-2-3 والملفات النصية المشفرة باستخدام ترميزات الأحرف القديمة مثل EBCDIC .
الملخص
ربما حدث أول استخدام لمصطلح تراث لوصف أنظمة الكمبيوتر في السبعينيات. بحلول الثمانينيات من القرن الماضي، كان يُستخدم للإشارة إلى أنظمة الكمبيوتر الحالية لتمييزها عن تصميم وتنفيذ الأنظمة الجديدة. غالبًا ما كان يتم سماع الإرث أثناء عملية التحويل، على سبيل المثال، عند نقل البيانات من النظام القديم إلى قاعدة بيانات جديدة.
في حين أن هذا المصطلح قد يشير إلى أن بعض المهندسين قد يشعرون أن النظام قديم، إلا أنه يمكن الاستمرار في استخدام النظام القديم لعدة أسباب. قد يكون الأمر ببساطة أن النظام لا يزال يوفر احتياجات المستخدمين. بالإضافة إلى ذلك، قد يتأثر قرار الاحتفاظ بنظام قديم لأسباب اقتصادية مثل تحديات العائد على الاستثمار أو قيود البائع ، أو التحديات الكامنة في إدارة التغيير، أو مجموعة متنوعة من الأسباب الأخرى غير الوظيفة. يعد التوافق مع الإصدارات السابقة (مثل قدرة الأنظمة الأحدث على التعامل مع تنسيقات الملفات القديمة وتشفير الأحرف) هدفًا غالبًا ما يدرجه مطورو البرامج في عملهم.
حتى إذا لم يعد مستخدمًا، فقد يستمر النظام القديم في التأثير على المنظمة نظرًا لدورها التاريخي. ربما لم يتم تحويل البيانات التاريخية إلى تنسيق النظام الجديد وقد تكون موجودة داخل النظام الجديد باستخدام مخطط مخصص، أو قد توجد فقط في مستودع بيانات. في كلتا الحالتين، يمكن أن يكون التأثير على ذكاء الأعمال والتقارير التشغيلية كبيرًا. قد يتضمن النظام القديم إجراءات أو مصطلحات لم تعد ذات صلة بالسياق الحالي، وقد تعيق أو تخلط بين فهم الأساليب أو التقنيات المستخدمة.
يمكن أن يكون لدى المنظمات أو الشركات أسباب مقنعة للاحتفاظ بنظام قديم، مثل:
- يعمل النظام بشكل مُرضٍ، ولا يرى المالك أي سبب لتغييره.
- تكاليف إعادة تصميم النظام أو استبداله باهظة لأنه كبير ومتآلف و / أو معقد.
- إعادة التدريب على نظام جديد سيكون مكلفًا من حيث الوقت والمال الضائعين، مقارنة بالفوائد الملموسة المتوقعة لاستبداله (والتي قد تكون صفرًا).
- يتطلب النظام توفرًا شبه ثابت، لذلك لا يمكن إخراجها من الخدمة، كما أن تكلفة تصميم نظام جديد بمستوى إتاحة مماثل عالية. تشمل الأمثلة أنظمة للتعامل مع حسابات العملاء في البنوك، وأنظمة حجز الكمبيوتر، ومراقبة الحركة الجوية، وتوزيع الطاقة (شبكات الطاقة)، ومحطات الطاقة النووية، ومنشآت الدفاع العسكري، وأنظمة مثل قاعدة بيانات TOPS.
- الطريقة التي يعمل بها النظام ليست مفهومة جيدًا. يمكن أن يحدث مثل هذا الموقف عندما يغادر مصممو النظام المؤسسة، ويكون النظام إما غير موثق بشكل كامل أو يتم فقد الوثائق.
- يتوقع المستخدم إمكانية استبدال النظام بسهولة عندما يصبح ذلك ضروريًا.
- تؤدي الأنظمة الأحدث وظائف ثانوية غير مرغوب فيها (خاصة للمستخدمين الفرديين أو غير المؤسسيين) مثل أ) تتبع نشاط المستخدم والإبلاغ عنه و / أو ب) التحديث التلقائي الذي يخلق ثغرات أمنية "من الباب الخلفي " ويترك المستخدمين النهائيين معتمدين على السلعة إيمان وصدق البائع الذي يقدم التحديثات. هذه المشكلة حادة بشكل خاص عندما لا يمكن تعطيل هذه الوظائف الثانوية لنظام أحدث.
المشاكل التي تطرحها الحوسبة القديمة
تعتبر الأنظمة القديمة مشكلة محتملة من قبل بعض مهندسي البرمجيات لعدة أسباب.[2]
- إذا كانت البرامج القديمة تعمل على أجهزة قديمة فقط، فإن تكلفة صيانة النظام قد تفوق في النهاية تكلفة استبدال كل من البرامج والأجهزة ما لم يسمح شكل من أشكال المحاكاة أو التوافق مع الإصدارات السابقة للبرنامج بالعمل على أجهزة جديدة.[3]
- قد يكون من الصعب صيانة هذه الأنظمة وتحسينها وتوسيعها نظرًا لوجود نقص عام في فهم النظام؛ الموظفون الذين كانوا خبراء في هذا المجال قد تقاعدوا أو نسوا ما عرفوه عنه، والموظفون الذين دخلوا الميدان بعد أن أصبح «إرثًا» لم يعلموا عنه في المقام الأول. يمكن أن يتفاقم هذا بسبب نقص أو فقدان الوثائق. أطلقت شركة الخطوط الجوية Comair رئيسها التنفيذي في عام 2004 بسبب فشل نظام جدولة الطاقم القديم الذي واجه قيودًا غير معروفة لأي شخص في الشركة.[4]
- قد تحتوي الأنظمة القديمة على ثغرات أمنية في أنظمة التشغيل أو التطبيقات القديمة بسبب نقص تصحيحات الأمان المتوفرة أو المطبقة. يمكن أن يكون هناك أيضًا تكوينات إنتاج تسبب مشاكل أمنية. يمكن أن تعرض هذه المشكلات النظام القديم لخطر التعرض للخطر من قبل المهاجمين أو المطلعين المطلعين.[5]
- قد يكون التكامل مع الأنظمة الأحدث صعبًا أيضًا لأن البرامج الجديدة قد تستخدم تقنيات مختلفة تمامًا. يعد التكامل عبر التكنولوجيا أمرًا شائعًا في مجال الحوسبة، ولكن التكامل بين التقنيات الأحدث والأقدم إلى حد كبير ليس شائعًا. ببساطة قد لا يكون هناك طلب كاف لتطوير تكنولوجيا التكامل. يتم تطوير بعض هذه التعليمات البرمجية «اللاصقة» أحيانًا بواسطة البائعين والمتحمسين لتقنيات قديمة معينة.
- غالبًا ما تؤدي قيود الميزانية الشركات إلى عدم معالجة الحاجة إلى استبدال أو ترحيل نظام قديم. ومع ذلك، غالبًا ما لا تأخذ الشركات في الاعتبار تكاليف الدعم المتزايدة (الأشخاص والبرامج والأجهزة، كل ما هو مذكور أعلاه) ولا تأخذ في الاعتبار الخسارة الهائلة في القدرة أو استمرارية الأعمال في حالة فشل النظام القديم. بمجرد فهم هذه الاعتبارات جيدًا، فإن استنادًا إلى عائد الاستثمار المثبت لمنصة مكدس تقنية جديدة وأكثر أمانًا ومحدثة، لن تكون مكلفة مثل البديل - ويتم العثور على الميزانية.
- نظرًا لحقيقة أن معظم المبرمجين القدامى يدخلون سن التقاعد وأن عدد المهندسين الشباب الذين سيحلون محلهم صغير جدًا، فهناك نقص ينذر بالخطر في القوى العاملة المتاحة. يؤدي هذا بدوره إلى صعوبة الحفاظ على الأنظمة القديمة، فضلاً عن زيادة تكاليف شراء المبرمجين ذوي الخبرة.[6]
تحسينات على أنظمة البرمجيات القديمة
عندما يكون من المستحيل استبدال الأنظمة القديمة من خلال ممارسة سحب التطبيق، فلا يزال من الممكن تعزيزها (أو «إعادة مواجهتها»). غالبًا ما يذهب التطوير إلى إضافة واجهات جديدة إلى نظام قديم. الأسلوب الأكثر بروزًا هو توفير واجهة قائمة على الويب لتطبيق حاسب مركزي قائم على المحطة الطرفية. قد يقلل هذا من إنتاجية الموظفين بسبب أوقات الاستجابة البطيئة وإجراءات المشغل البطيئة التي تعتمد على الماوس، ومع ذلك غالبًا ما يُنظر إليه على أنه «ترقية»، لأن نمط الواجهة مألوف للمستخدمين غير المهرة ويسهل عليهم استخدامه. يناقش جون ماكورميك مثل هذه الاستراتيجيات التي تتضمن برمجيات وسيطة.[7]
تعد تحسينات الطباعة مشكلة لأن أنظمة البرامج القديمة غالبًا لا تضيف إرشادات التنسيق، أو تستخدم بروتوكولات غير قابلة للاستخدام في طابعات الكمبيوتر Windows الحديثة. يمكن استخدام خادم الطباعة لاعتراض البيانات وترجمتها إلى رمز أكثر حداثة. يمكن إنشاء مستندات Rich Text Format (RTF) أو PostScript في التطبيق القديم ثم تفسيرها على جهاز كمبيوتر قبل طباعتها.
من الصعب تنفيذ تدابير الأمن البيومترية على الأنظمة القديمة. الحل العملي هو استخدام Telnet أو خادم وكيل HTTP للجلوس بين المستخدمين والإطار الرئيسي لتنفيذ الوصول الآمن إلى التطبيق القديم.
التغيير الذي يتم إجراؤه في بعض المنظمات هو التحول إلى برنامج العمليات التجارية المؤتمتة (ABP) الذي يولد أنظمة كاملة. يمكن لهذه الأنظمة بعد ذلك التفاعل مع الأنظمة القديمة للمؤسسات واستخدامها كمستودعات للبيانات. يمكن أن يوفر هذا النهج عددًا من الفوائد المهمة: يتم عزل المستخدمين عن أوجه القصور في أنظمتهم القديمة، ويمكن دمج التغييرات بسرعة وسهولة في برنامج ABP.
يمكن أيضًا استخدام مناهج الهندسة العكسية والأمامية التي يحركها النموذج لتحسين البرامج القديمة. [8]
مثال ناسا
أندرياس هاين، من جامعة ميونيخ التقنية، أجرى أبحاثًا حول استخدام الأنظمة القديمة في استكشاف الفضاء. وفقًا لهين، تعد الأنظمة القديمة جذابة لإعادة الاستخدام إذا كانت لدى المؤسسة القدرات للتحقق والتحقق من الصحة والاختبار والتاريخ التشغيلي.[9][10] يجب دمج هذه الإمكانات في مختلف مراحل دورة حياة البرنامج مثل التطوير أو التنفيذ أو الاستخدام أو الصيانة. بالنسبة لأنظمة البرامج، تعد القدرة على استخدام النظام وصيانته أمرًا بالغ الأهمية. وإلا سيصبح النظام أقل قابلية للفهم والصيانة.
وفقًا لـ Hein ، يزيد التحقق والتحقق من الصحة والاختبار والتاريخ التشغيلي من الثقة في موثوقية النظام وجودته. ومع ذلك، فإن تراكم هذا التاريخ غالبًا ما يكون مكلفًا. استخدم برنامج مكوك الفضاء المتقاعد التابع لوكالة ناسا كمية كبيرة من تكنولوجيا حقبة السبعينيات. كان الاستبدال باهظ التكلفة بسبب المتطلبات الباهظة للحصول على شهادة الطيران. أكملت الأجهزة الأصلية متطلبات التكامل والاعتماد الباهظة للرحلة، ولكن أي معدات جديدة كان يجب أن تخضع لهذه العملية بأكملها مرة أخرى. تطلبت هذه العملية الطويلة والمفصلة اختبارات مكثفة للمكونات الجديدة في تكويناتها الجديدة قبل أن يمكن استخدام وحدة واحدة في برنامج مكوك الفضاء. وبالتالي، فإن أي نظام جديد بدأ عملية الاعتماد يصبح نظامًا قديمًا بحكم الواقع بحلول وقت الموافقة عليه للرحلة.
بالإضافة إلى ذلك، تم تصميم نظام مكوك الفضاء بأكمله، بما في ذلك أصول المركبات الأرضية ومركبات الإطلاق، للعمل معًا كنظام مغلق. نظرًا لأن المواصفات لم تتغير، فقد أدت جميع الأنظمة والمكونات المعتمدة أداءً جيدًا في الأدوار التي تم تصميمها من أجلها.[11] حتى قبل أن يتقاعد المكوك في عام 2010، وجدت وكالة ناسا أنه من المفيد الاستمرار في استخدام العديد من تقنيات السبعينيات بدلاً من ترقية تلك الأنظمة وإعادة اعتماد المكونات الجديدة.
وجهات نظر حول الكود القديم
يفضل البعض في هندسة البرمجيات وصف «التعليمات البرمجية القديمة» دون الإشارة إلى كونها قديمة. من بين المفاهيم الحيادية الأكثر انتشارًا هي الكود المصدري الموروث من شخص آخر وشفرة المصدر الموروثة من إصدار أقدم من البرنامج . عرّف Eli Lopian ، الرئيس التنفيذي لشركة Typemock ، بأنه «رمز يخشى المطورون تغييره».[12] قدم مايكل فيذرز [13] تعريفًا للشفرة القديمة كرمز بدون اختبارات ، مما يعكس منظور الكود القديم الذي يصعب التعامل معه جزئيًا بسبب الافتقار إلى اختبارات الانحدار الآلي. كما حدد اختبارات التوصيف للبدء في وضع الكود القديم قيد الاختبار.
وصف جيني هندري إنشاء الكود بأنه تحدٍ للمبرمجين الحاليين لإنشاء كود «مثل الموروثات الأخرى في حياتنا - مثل التحف والموروثات والقصص التي يتم الاعتزاز بها وتناقلها بحب من جيل إلى آخر. ماذا لو كانت الشفرة القديمة شيئًا نفخر به؟».[14]
استخدامات إضافية لمصطلح تراث في الحوسبة
غالبًا ما يستخدم مصطلح الدعم القديم بالاقتران مع الأنظمة القديمة. قد يشير المصطلح إلى إحدى ميزات البرامج الحديثة. على سبيل المثال، يمكن لأنظمة التشغيل ذات «الدعم القديم» اكتشاف الأجهزة القديمة واستخدامها. يمكن استخدام المصطلح أيضًا للإشارة إلى وظيفة العمل؛ على سبيل المثال، بائع برامج أو أجهزة يدعم أو يوفر صيانة البرامج للمنتجات القديمة.
قد يكون المنتج «القديم» منتجًا لم يعد يُباع، أو فقد حصة كبيرة في السوق، أو هو نسخة من منتج غير حديث. قد يكون للمنتج القديم بعض المزايا على منتج حديث مما يجعله جذابًا للعملاء للاحتفاظ به. يكون المنتج «عفا عليه الزمن» حقًا فقط إذا لم يكن لديه ميزة لأي شخص - إذا لم يختار أي شخص يتخذ قرارًا عقلانيًا الحصول عليه جديدًا.
غالبًا ما يشير مصطلح «الوضع القديم» بشكل خاص إلى التوافق مع الإصدارات السابقة. يُقال إن منتج البرنامج القادر على الأداء كما لو كان إصدارًا سابقًا من نفسه، «يعمل في الوضع القديم». هذا النوع من الميزات شائع في أنظمة التشغيل ومتصفحات الإنترنت، حيث تعتمد العديد من التطبيقات على هذه المكونات الأساسية.
شهد عصر الحاسوب المركزي العديد من التطبيقات التي تعمل في الوضع القديم. في بيئة حوسبة الأعمال الحديثة، من الصعب وضع البنى ذات المستوى n أو 3-tier في الوضع القديم لأنها تتضمن العديد من المكونات التي تشكل نظامًا واحدًا.
تقنية المحاكاة الافتراضية هي ابتكار حديث يسمح للأنظمة القديمة بمواصلة العمل على الأجهزة الحديثة من خلال تشغيل أنظمة التشغيل والمتصفحات القديمة على نظام برمجي يحاكي الأجهزة القديمة.
العمارة براونفيلد
استعار المبرمجون مصطلح الحقل البني من صناعة البناء، حيث توصف الأرض المطورة سابقًا (غالبًا ما تكون ملوثة ومهجورة) بالحقل البني.[15]
- بنية براونفيلد هي نوع من البرامج أو بنية الشبكات التي تدمج الأنظمة القديمة.
- يعد نشر Brownfield ترقية أو إضافة إلى برنامج موجود أو بنية شبكة تحتفظ بالمكونات القديمة.
رأي بديل
هناك رأي مؤيد بديل — تزايد منذ نهاية فقاعة الدوت كوم في عام 1999 — مفاده أن الأنظمة القديمة هي مجرد أنظمة كمبيوتر قيد الاستخدام
يقدر محللو تكنولوجيا المعلومات أن تكلفة استبدال منطق الأعمال تبلغ حوالي خمسة أضعاف تكلفة إعادة الاستخدام، حتى مع استبعاد مخاطر فشل النظام وانتهاكات الأمان. من الناحية المثالية، لن تضطر الشركات أبدًا إلى إعادة كتابة معظم منطق الأعمال الأساسي: المدين = الائتمانات مطلب دائم.
تستجيب صناعة تكنولوجيا المعلومات بـ «التحديث القديم» و «التحول القديم»: تجديد منطق الأعمال الحالي بواجهات مستخدم جديدة، وأحيانًا باستخدام كشط الشاشة والوصول الممكّن للخدمة من خلال خدمات الويب. تسمح هذه التقنيات للمؤسسات بفهم أصول الكود الموجودة لديها (باستخدام أدوات الاكتشاف)، وتوفير واجهات مستخدم وتطبيقات جديدة للتعليمات البرمجية الحالية، وتحسين سير العمل، واحتواء التكاليف، وتقليل المخاطر، والاستمتاع بصفات الخدمة الكلاسيكية (ما يقرب من 100٪ من وقت التشغيل والأمان وقابلية التوسع، إلخ.).
يدعو هذا الاتجاه أيضًا إلى التفكير في ما يجعل الأنظمة القديمة متينة للغاية. يعيد التقنيون تعلم أهمية هندسة الصوت منذ البداية، لتجنب إعادة الكتابة المكلفة والمحفوفة بالمخاطر. تميل الأنظمة القديمة الأكثر شيوعًا إلى أن تكون تلك التي احتضنت المبادئ المعمارية لتكنولوجيا المعلومات المعروفة، مع التخطيط الدقيق والمنهجية الصارمة أثناء التنفيذ. غالبًا ما لا تدوم الأنظمة المصممة بشكل سيئ، لأنها تبلى ولأن عيوبها المتأصلة تستدعي الاستبدال. وبالتالي، فإن العديد من المنظمات تعيد اكتشاف قيمة كل من أنظمتها القديمة والأسس النظرية لتلك الأنظمة.
انظر أيضًا
المراجع
- ^ "Merriam-Webster". مؤرشف من الأصل في 2021-10-09. اطلع عليه بتاريخ 2013-06-22.
- ^ (for example, see Bisbal et al., 1999).
- ^ Lamb، John (يونيو 2008). "Legacy systems continue to have a place in the enterprise". Computer Weekly. مؤرشف من الأصل في 2021-04-30. اطلع عليه بتاريخ 2014-10-27.
- ^ Stephanie Overby (1 مايو 2005). "Comair's Christmas Disaster: Bound To Fail - CIO.com - Business Technology Leadership". CIO.com. مؤرشف من الأصل في 2021-10-25. اطلع عليه بتاريخ 2012-04-29.
- ^ Razermouse (3 مايو 2011). "The Danger of Legacy Systems". Mousesecurity.com. مؤرشف من الأصل في 2012-03-23. اطلع عليه بتاريخ 2012-04-29.
- ^ "Benefits of Mainframe Modernization". Modernization Hub (بen-US). Archived from the original on 2021-05-11. Retrieved 2017-08-23.
{{استشهاد ويب}}: صيانة الاستشهاد: لغة غير مدعومة (link) - ^ McCormick، John (2 يونيو 2000). "Mainframe-web middleware". Gcn.com. مؤرشف من الأصل في 2021-10-27. اطلع عليه بتاريخ 2012-04-29.
- ^ Menychtas، Andreas؛ Konstanteli، Kleopatra؛ Alonso، Juncal؛ Orue-Echevarria، Leire؛ Gorronogoitia، Jesus؛ Kousiouris، George؛ Santzaridou، Christina؛ Bruneliere، Hugo؛ Pellens، Bram (2014)، "Software modernization and cloudification using the ARTIST migration methodology and framework"، Scalable Computing: Practice and Experience، ج. 15، DOI:10.12694/scpe.v15i2.980
- ^ A.M. Hein (2014)، How to Assess Heritage Systems in the Early Phases?، 6th International Systems & Concurrent Engineering for Space Applications Conference 2014، ESA، مؤرشف من الأصل في 2021-04-27
- ^ A.M. Hein (2016)، Heritage Technologies in Space Programs - Assessment Methodology and Statistical Analysis، PhD thesis Faculty of Mechanical Engineering، Technical University of Munich، مؤرشف من الأصل في 2021-04-17
- ^ A.M. Hein (2014)، How to Assess Heritage Systems in the Early Phases?، 6th International Systems & Concurrent Engineering for Space Applications Conference 2014، ESA، ص. 3، مؤرشف من الأصل في 2021-04-27
- ^ Lopian، Eli (15 مايو 2018). "Defining Legacy Code". مؤرشف من الأصل في 2021-09-05. اطلع عليه بتاريخ 2019-06-10.
- ^ Michael Feathers' Working Effectively with Legacy Code ((ردمك 0-13-117705-2))
- ^ "Take Pride in Your Legacy (Code)". 11 يوليو 2014. مؤرشف من Author=Ginny Hendry الأصل في 2021-10-29. اطلع عليه بتاريخ 2021-10-07.
{{استشهاد ويب}}: تحقق من قيمة|مسار=(مساعدة) - ^ "Definition of greenfield and brownfield deployment". Searchunifiedcommunications.techtarget.com. مؤرشف من الأصل في 2021-05-11. اطلع عليه بتاريخ 2012-04-29.
| النظام القديم في المشاريع الشقيقة: | |
