عندما ترث نظاماً بلا شيفرة مصدريّة ولا مواصفات ── الإجراءات العمليّة لتشغيله وصيانته دون توقّف

«الشركة التي طوّرته لم تعد موجودة» أو «الموظّف الذي بناه استقال ولا يمكن الوصول إليه» أو «الملفّ التنفيذيّ وقاعدة البيانات موجودان داخل الخادم، لكن لا الشيفرة المصدريّة ولا المواصفات موجودتان» ── حالة ليست نادرة أبداً في استشارات أنظمة الأعمال الخاصّة بالشركات الصغيرة والمتوسّطة. ومع ذلك يستمرّ النظام في العمل اليوم أيضاً، ويعتمد عليه سير العمل.

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

1. الخلاصة أوّلاً

• ما ينبغي فعله أوّلاً ليس التعديل، بل «صون الوضع الحاليّ». بيئة الإنتاج العاملة نفسها هي أهمّ أصل. احصل على نسخة احتياطيّة لصورة القرص (كتحويلها إلى جهاز افتراضيّ عبر Disk2vhd مثلاً) ونسخة احتياطيّة لقاعدة البيانات، وتحقّق حتّى من إمكانيّة الاستعادة قبل الانتقال إلى الخطوة التالية.¹
• حتّى بلا مواصفات مكتوبة، يمكن استعادة المواصفات. المواد الأساسيّة هي مقابلة مستخدمي النظام في العمل، والشاشات والتقارير، ومخطّط قاعدة البيانات، والسجلّات، وملاحظة السلوك الفعليّ عبر Process Monitor.²
• تختلف إمكانيّة استعادة الشيفرة المصدريّة اختلافاً كبيراً باختلاف مجموعة التقنيّات (technology stack). فمنتَجات .NET يمكن قراءتها إلى حدّ بعيد عبر مُفكِّكات (decompilers) مثل ILSpy، بينما استعادة شيفرة أصليّة (native code) مثل VB6 أو C++ لا يُرتجى منها واقعيّاً.³⁴
• لفكّ التجميع (decompile) نقاط قانونيّة يجب مراعاتها. بموجب المادّة 30-4 من قانون حقوق التأليف والنشر، يُنظَّم استخدام أغراض التحليل والفحص على أنّه مسموح به من حيث المبدأ، لكنّ التحقّق من العقد (بنود ترخيص الاستخدام) أمر لا بدّ منه.⁵
• لا تنتظر «بعد الفهم الكامل». افهم أوّلاً، على سبيل الأولويّة، المواضع التي يتوقّف بها سير العمل إذا توقّفت والمواضع القريبة من الحاجة للتغيير، واجعل التغيير صغيراً وواحداً في كلّ مرّة وبشكل قابل للتراجع.
• عقد الصيانة يكون أساساً شبه وكالة. لا يمكن الوعد بمسؤوليّة إتمام النتيجة (عقد المقاولة) لتحقيق نظام مجهول المحتوى. يُعقَد العقد بفصل مرحلة التحقيق عن مرحلة التعديل.

2. لماذا تنشأ حالة «انعدام كلّ شيء»

قبل التفكير في المعالجة، يفيد التحقّق من النمط الذي تنتمي إليه شركتك، إذ يعطي فكرة عن الأدلّة المتبقّية.

النمط الأخير يُغفَل عنه غالباً، لكنّه من الناحية العمليّة يحتاج معاملة مماثلة لحالة «لا توجد شيفرة». التعديل باعتبار الشيفرة القديمة أصلاً صحيحاً، بينما كان الملفّ التنفيذيّ الفعليّ للإنتاج يحمل تعديلات امتدّت سنوات حادثة فشل نموذجيّة. حتّى إن عُثر على الشيفرة، لا تثق بها حتّى تبنيها وتقارنها بالملفّ التنفيذيّ للإنتاج.

في أيّ نمط من هذه الأنماط، تكون البحث عن العقد وإشعار التسليم وشهادة الاستلام قيّماً منذ البداية. فإن دُوِّن فيها انتماء حقوق التأليف والتزام تسليم الشيفرة المصدريّة، يصبح ذلك أساساً للتفاوض أو للتسوية القانونيّة لاحقاً.

3. ما ينبغي فعله في الأسبوع الأوّل ── صون الوضع الحاليّ والجرد

3.1 تجميد التغييرات

الأصل هو عدم المساس بالخادم أو الجهاز المستهدَف حتّى ينتهي التحقيق. فـ«لنُحدِّث نظام التشغيل احتياطاً» أو «لنُرتِّب الملفّات التي تبدو غير مستخدَمة» قد يكونان قاتلَين. لأنّه لا توجد شيفرة مصدريّة، لا يوجد خيار «الإصلاح» عند حدوث عطل. يُستحسَن أيضاً التفكير في وضع توقيت تطبيق التحديثات تحت السيطرة، بحيث لا تُغيِّر التحديثات التلقائيّة (تحديث Windows، وتغيّر سلوك برنامج مكافحة الفيروسات) البيئة من تلقاء نفسها.

3.2 النسخ الاحتياطيّ ── استنساخ البيئة نفسها كأصل

النسخ الاحتياطيّ على مستوى الملفّات وحده غير كافٍ. في هذا النوع من الأنظمة، من المحتمل أن يكون إعداد نظام التشغيل، والسجلّ (registry)، ووقت التشغيل (runtime)، وموضع النشر جميعها جزءاً من «سبب عمله»، لذا يُصان صورة القرص كاملةً.

الأداة الشائعة الاستخدام في العمل الفعليّ هي Disk2vhd من Sysinternals. يمكنها تحويل النظام العامل، وهو لا يزال متّصلاً (online)، إلى ملفّ VHD/VHDX متّسق باستخدام لقطة وحدة التخزين (VSS)، ويصبح ذلك أساساً لبيئة تحقّق تُشغَّل كجهاز افتراضيّ على Hyper-V.¹ وميزة ذلك هي إمكانيّة التقدّم في معالجة تقادم الخادم الفعليّ وتأمين بيئة التحقّق دفعة واحدة (مع ملاحظة أنّ ترخيص Windows من نوع OEM قد لا يسمح بالانتقال إلى بيئة افتراضيّة، فيلزم التحقّق من نوع الترخيص¹).

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

3.3 الجرد ── وضع قائمة بما يعمل

بعد ذلك، تُستخرَج عناصر النظام بشكل آليّ. هذا عمل شموليّة لا حِسّ.

عندما لا تُعرَف «أين» تقع ملفّات الإعداد أو وجهة الإخراج، فمراقبة وصول العمليّة إلى الملفّات والسجلّ (registry) عبر Process Monitor هي الطريق الأسرع. تظهر المسارات التي تقرأها التطبيقات وتكتب فيها فعليّاً في قائمة كما هي.²

4. حتّى بلا مواصفات مكتوبة، يمكن استعادة المواصفات

بعد أن يتّضح «ما هو موجود» عبر الجرد، تأتي الخطوة التالية وهي استعادة «ما الذي يجري». المواد متوفّرة.

• مقابلة مستخدمي النظام في العمل ── أكبر مواصفات هي ما في ذهن من يستخدم النظام يوميّاً. اسأل، وفق تسلسل العمل اليوميّ والشهريّ والسنويّ، عن أيّ شاشة يُدخَل فيها ماذا، وماذا يخرج منها. وبوجه خاصّ، قد ينسى المسؤول نفسه المعالجة السنويّة (الإقفال المحاسبيّ، والجرد، وتحديث السنة الماليّة)، وهي نقطة تكثر فيها الحوادث عند أوّل مرّة بعد التسلّم.
• الشاشات والتقارير ── حوِّل كلّ الشاشات وكلّ التقارير إلى سجلّ (لقطة شاشة ونسخة فعليّة). مجرّد التطابق بين عناصر الإدخال وعناصر الإخراج يكشف الكثير من هيكل المعالجة.
• مخطّط قاعدة البيانات والبيانات ── تعريف الجداول، والقيود، والبيانات الفعليّة لقيم الرموز، كلّها أحافير لقواعد العمل. ملاحظة من قبيل «قيمة هذا العلَم (flag) لا تُستخدَم إلّا بثلاث حالات» تكشف مواصفات لا تظهر من الشاشة.
• السجلّات وسجلّ الأحداث ── إن وُجد سجلّ خاصّ بالتطبيق، يُقرَأ منه تسلسل المعالجة، ومن سجلّ أحداث Windows تُقرَأ نزعة الأخطاء السابقة.
• مراقبة السلوك الفعليّ ── إن سُجِّل وصول العمليّة إلى الملفّات والسجلّ (registry) والشبكة عبر Process Monitor، يمكن إثبات التطابق بين المدخلات والمخرجات من قبيل «هذه المعالجة في نهاية الشهر تقرأ ملفّ CSV من هذا المجلّد المشترَك، وتتواصل مع خادم قاعدة البيانات هذا»، دون شيفرة مصدريّة.² لكنّ ما يكشفه Process Monitor يقتصر على الطرف المقابل للاتّصال، ولا يظهر منه أيّ جدول تحديث وكيف تحديداً. من هنا فصاعداً، يُحدَّد ذلك عبر وظائف التتبّع والتدقيق الخاصّة بنظام إدارة قواعد البيانات (كالأحداث الموسَّعة في SQL Server) أو بمقارنة محتوى قاعدة البيانات قبل المعالجة وبعدها.

المهمّ هنا هو عدم محاولة توثيق كلّ الوظائف بالتساوي. فالهدف ليس موسوعة بل استمراريّة التشغيل، لذا يُعطَى الأولويّة لـ«المعالجة التي يتوقّف بها سير العمل إذا توقّفت»، و«المعالجة التي تظهر بها أخطاء»، و«المواضع القريبة من الحاجة للتغيير»، وتُراكَم دفعة الفهم في سجلّ.

5. ما الذي يمكن فعله تقنيّاً عند انعدام الشيفرة المصدريّة

مدى ما يُرتجى من «قراءة المحتوى» يتحدّد تقريباً بما بُني به النظام. قدِّر مجموعة التقنيّات من خصائص الملفّ التنفيذيّ وبنية DLL، ثمّ اضبط التوقّعات وفقاً لذلك.

في حالة تطبيق .NET المنشور بصيغة IL العاديّة، يكون الوضع جيّداً إلى حدّ بعيد، وشيفرة C# التي تُستخرَج بالتفكيك عمليّة بشكل كافٍ لفهم المعالجة. لكن كما توضّح الوثائق الرسميّة نفسها، تُفقَد المعلومات غير اللازمة وقت الترجمة (compile) مثل التعليقات وأسماء المتغيّرات المحليّة والمسافات البيضاء، وينبغي اعتبارها لا بديلاً عن الشيفرة المصدريّة الأصليّة بل «مادّة لفهم السلوك».³ كذلك توجد استثناءات. فإن كان مُطبَّقاً عليه تعتيم (obfuscation)، ترتفع صعوبة فكّ الشيفرة كثيراً، وبما أنّ الملفّ الثنائيّ المنشور عبر Native AOT لا يتضمّن اللغة الوسيطة، لا يصحّ توقّع «إمكانيّة القراءة لأنّه من صنع .NET». عند تقدير مجموعة التقنيّات، تحقّق حتّى من صيغة النشر لا لغة التطوير وحدها.

إن بقي PDB (ملفّ الرموز) إلى جانب الملفّ التنفيذيّ، فقد يمكن استعادة أسماء الدوال، بل والشيفرة المصدريّة نفسها (إن وُجد مصدر مضمَّن). وقد نظّمنا ما يُحتوى وما يمكن توقّعه في «PDB (قاعدة بيانات البرنامج) ما هي؟».

النقاط القانونيّة الواجب مراعاتها ── فكّ التجميع «بعد التحقّق»

ما يمكن فعله تقنيّاً وما يجوز فعله أمران مختلفان. للهندسة العكسيّة، بما فيها فكّ التجميع (decompile)، نقاط عالقة بموجب قانون حقوق التأليف والنشر، وبموجب المادّة 30-4 من قانون حقوق التأليف والنشر المُستحدَثة في تعديل عام هيسي 30 (2018) (الاستخدام الذي لا يهدف إلى التمتّع بالفكر أو الشعور المُعبَّر عنه في المصنَّف)، يُنظَّم النسخ والتحويل الهادف إلى تحليل البرنامج وفحصه على أنّه مسموح به من حيث المبدأ في حدود الضرورة المُقرَّة. لكنّ النصّ يتضمّن استثناءً بعبارة «ما لم يُلحِق ذلك ضرراً غير عادل بمصالح صاحب حقّ التأليف»، وقد يحمل تقييماً مختلفاً في حالات مثل استخدام نتيجة التحليل لصنع منتَج منافس مثلاً.⁵

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

6. الإطالة، أم التغليف، أم إعادة البناء

بعد أن يتوفّر مستوى الفهم المُكتسَب من التحقيق وظروف جانب العمل معاً، يُحسَم التوجّه. هنا أيضاً، لا «إعادة بناء كاملة حتماً» ولا «إبقاء كما هو حتماً»، بل يُنظَّم الأمر بجدول قرار.

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

أمّا قرارات الإطالة أو الانتقال الخاصّة بتقنيّات محدّدة مثل VB6 وAccess فتُعالَج بالتفصيل في «إطالة عمر تطبيقات VB6 / Access في العمل ونقلها»، وبخصوص اعتماد أنظمة الويب الداخليّة على وضع IE، في «دليل التخلّص من الاعتماد على وضع IE».

7. نظام التشغيل والصيانة بعد التسلّم

إذا كان التوجّه هو «الاستمرار في التشغيل في الوقت الراهن» (وهذا واقع معظم الحالات فعليّاً)، فإنّ الالتزام بالنمط التالي يقلّل من الحوادث.

• امتلاك بيئة تحقّق ── لكن مع عزل التشغيل الأوّل عن الشبكة دائماً ── تشغيل صورة القرص التي أُنشئت في 3.2 كجهاز افتراضيّ يجعلها بيئة تحقّق بنفس بنية الإنتاج. لكن هذه الصورة تحتفظ كما هي بسلاسل اتّصال الإنتاج، وبيانات الاعتماد، والمهامّ المُجدوَلة، وخدمات التشغيل التلقائيّ. فإن شُغِّلت وهي متّصلة بالشبكة، قد تعمل الدُفعة الليليّة مرّتين وتُحدِّث قاعدة بيانات الإنتاج، أو يُعاد إرسال بريد، أو يُستدعى API خارجيّ. اجعل التشغيل الأوّل دائماً بفصل واجهة الشبكة الافتراضيّة (vNIC) أو ضمن شبكة معزولة، وأوقِف المهامّ المُجدوَلة وخدمات التشغيل التلقائيّ، وأعِد كتابة وجهة الاتّصال لتصبح للتحقّق، ثمّ اسمح بالاتّصال ضمن النطاق اللازم فقط.
• التغيير واحداً تلو الآخر وبشكل قابل للتراجع ── سواء تغيير الإعدادات أو تطبيق تحديث Windows، غيّر واحداً في كلّ مرّة. احتفظ بالصورة قبل التغيير، وارجع إليها إن ظهرت مشكلة. اجعل تسجيل ما تغيّر (سجلّ التغييرات) جزءاً ملازماً.
• تُنمَّى الوثائق كـ«ناتج ثانويّ لما اكتُشف» ── لا تُنشئ مشروعاً لكتابة مواصفات كاملة، بل أضِف إلى السجلّ ما تتعلّمه في كلّ مرّة تتعامل فيها مع عطل أو تعديل. بعد سنة من التشغيل، تكتمل الوثائق تدريجيّاً بدءاً من المواضع الأهمّ للعمل.
• جهّز المراقبة ── مراقبة الحياة (حيّ/ميت)، والمساحة المتبقّية على القرص، وسجلّ الأخطاء، وكشف «الملفّ الذي كان من المفترض أن يخرج دائماً ولم يخرج». حتّى مع عدم رؤية داخل الصندوق الأسود، يمكن مراقبة المدخل والمخرج.
• افصل العقد بين التحقيق والتعديل ── عند تكليف طرف خارجيّ بالصيانة، ولأنّه لا يمكن الوعد بمسؤوليّة إتمام النتيجة لتحقيق نظام مجهول المحتوى، من الصحّي فصل العقد على مراحل: التحقيق والصيانة شبه وكالة، والتعديل الفرديّ بعد استقرار المواصفات مقاولة (أو شبه وكالة قائمة على إتمام النتيجة).

8. الخلاصة

• عند تسلّم نظام بلا شيفرة مصدريّة ولا مواصفات، صون الوضع الحاليّ يسبق التعديل. احصل على نسخة احتياطيّة لصورة القرص (عبر Disk2vhd وغيره) ولقاعدة البيانات، وتحقّق حتّى من إمكانيّة الاستعادة.
• اجرِ جرداً للملفّات التنفيذيّة، وما يعمل تلقائيّاً، والمهامّ المُجدوَلة، والإعدادات، والجهات المتّصلة، والحسابات، وضع الصورة الكاملة للنظام في قائمة.
• يمكن استعادة المواصفات من مقابلة المستخدمين، والشاشات، والتقارير، ومخطّط قاعدة البيانات، والسجلّات، ومراقبة السلوك الفعليّ عبر Process Monitor. أعطِ الأولويّة للمواضع ذات الأثر الكبير على العمل، لا لكلّ الوظائف.
• تعتمد إمكانيّة استعادة المحتوى على مجموعة التقنيّات. يمكن قراءة .NET إلى حدّ بعيد عبر فكّ التجميع، لكنّها ليست بديلاً عن المصدر الأصليّ. تحقّق قبل التنفيذ من روح المادّة 30-4 من قانون حقوق التأليف والنشر ومن بنود الترخيص والعقد.
• يُحسَم التوجّه بين «الإطالة، التغليف، إعادة البناء الجزئيّة، إعادة البناء الكاملة» وفقاً لسنوات الاستخدام المتبقّية، وتكرار التغيير، والأثر على العمل، ومستوى الفهم. المواصفات المُستعادة بالتحقيق تصبح أصلاً أيّاً كان الطريق المُختار.
• في مرحلة التشغيل، النمط الأساسيّ هو بيئة التحقّق، والتغيير واحداً تلو الآخر، وسجلّ التغييرات، ومراقبة المدخل والمخرج، والتعاقد بشبه الوكالة.

مقالات ذات صلة

• PDB (قاعدة بيانات البرنامج) ما هي؟ ── فهم معلومات التصحيح والرموز (symbols) وSource Link
• دليل Process Monitor العمليّ
• إطالة عمر تطبيقات VB6 / Access في العمل ونقلها ── جدول قرار الإبقاء والتغليف والاستبدال
• دليل التخلّص من الاعتماد على وضع IE
• كيف ينبغي عقد اتّفاقيّات التطوير المُوكَل والتشغيل والصيانة ── التمييز بين شبه الوكالة والمقاولة استناداً إلى «نموذج المعاملات والعقود» الصادر عن IPA
• ما ينبغي تنظيمه قبل تكليف جهة خارجيّة بتطوير تطبيق Windows

مجالات الاستشارة ذات الصلة

تتعامل شركة Komura Soft LLC مع تحقيق الوضع الحاليّ لأنظمة الأعمال التي لا تتوفّر لها شيفرة مصدريّة ولا مواصفات (تحليل الملفّات التنفيذيّة وقاعدة البيانات والسلوك الفعليّ)، واستعادة المواصفات من السلوك، وتنظيم سياسة الإطالة أو الانتقال، وصولاً إلى التشغيل والصيانة اللاحقَين. نرحّب أيضاً بالاستشارة من مرحلة «لا أعرف من أين أبدأ».

• الاستفادة من الأصول القائمة ودعم الانتقال
• تعديل وصيانة برمجيّات Windows القائمة
• تحقيق الأخطاء وتحليل الأسباب
• الاستشارة التقنيّة ومراجعة التصميم
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل يمكن طلب الصيانة أو التعديل لنظام لا توجد له شيفرة مصدريّة؟

نعم يمكن ذلك. لكنّ طريقة العمل تختلف عن الصيانة الاعتياديّة. الواقعيّ هو البدء بصون البيئة العاملة والنسخ الاحتياطيّ، ثمّ تخصيص مرحلة تحقيق تُستعاد فيها المواصفات من تحليل الشاشات والتقارير وقاعدة البيانات والسجلّات والملفّات التنفيذيّة، ثمّ التقدّم نحو التعديل وتطوير الوظائف المحيطة في حدود الفهم المُكتسَب من تلك المرحلة. ولأنّ التحقيق عمل لا يمكن ضمان نتيجته مسبقاً، فمن الشائع تنفيذه بعقد شبه وكالة لا يحمّل مسؤوليّة إتمام النتيجة، بدل عقد المقاولة.

أليس فكّ التجميع (decompile) للملفّ التنفيذيّ - أي الهندسة العكسيّة - أمراً غير قانونيّ؟

ليس غير قانونيّ على إطلاقه. فبموجب المادّة 30-4 المُستحدَثة في تعديل قانون حقوق التأليف والنشر الياباني لعام هيسي 30 (2018)، يُنظَّم «الاستخدام الذي لا يهدف إلى التمتّع بالفكر أو الشعور المُعبَّر عنه في المصنَّف»، مثل تحليل البرنامج وفحصه، على أنّه مسموح به من حيث المبدأ في حدود الضرورة المُقرَّة. لكن يُستثنى من ذلك «ما يُلحِق ضرراً غير عادل بمصالح صاحب حقّ التأليف»، ويبقى موضوع كيفيّة التعامل مع حظر التحليل في عقد ترخيص الاستخدام مسألة عالقة أيضاً. تحقّق قبل التنفيذ من بنود الترخيص وعقد التطوير المُوكَل، وإن ترددت في الحكم فاستشر محامياً أو خبيراً مختصّاً.

أفلست شركة التطوير ولا يمكن الحصول على الشيفرة المصدريّة. ماذا أفعل؟

تحقّق أوّلاً من العقود والمُسلَّمات (deliverables) السابقة. فإن نصّ عقد التطوير المُوكَل على انتماء حقوق التأليف والشيفرة المصدريّة وتسليمها، فهذا يشكِّل أساساً للحصول عليها أو استخدامها. وإن وُجد أطراف يمكن التواصل معهم، يستحقّ الأمر استكشاف إمكانيّة التفاوض على الحصول عليها. لكنّ المهمّ عمليّاً هو عدم التوقّف عند «لم نحصل عليها في النهاية»، ويُنصَح بالبدء - على افتراض عدم الحصول عليها - بصون البيئة العاملة والنسخ الاحتياطيّ بالتوازي مع استعادة المواصفات من السلوك الفعليّ وقاعدة البيانات.

نظام بلا مواصفات، من أين أبدأ؟

قبل التعديل، ابدأ أوّلاً بصون الوضع الحاليّ. احصل على صورة قرص (disk image) لبيئة الإنتاج العاملة ونسخة احتياطيّة من قاعدة البيانات، وتحقّق من إمكانيّة الاستعادة منهما. ثمّ اجرِ جرداً للملفّات التنفيذيّة، وما يعمل تلقائيّاً، والمهامّ المُجدوَلة (scheduled tasks)، والإعدادات، والجهات المتّصلة، والحسابات، وضعها في جدول يعكس الصورة الكاملة للنظام. بعد ذلك، والقاعدة المُتَّبَعة هي توثيق المواصفات - مع التركيز على المواضع المهمّة للعمل - انطلاقاً من مقابلة مستخدمي النظام في العمل، وملاحظة الشاشات والتقارير ومخطّط قاعدة البيانات.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.