التعهيد الخارجي والتطوير التعاقدي لتطبيقات Windows: ما ينبغي تنظيمه قبل الطلب

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

في الواقع العمليّ، نتلقّى كثيراً استشارات من هذا القبيل:

• نريد تعديل برمجيّة Windows قديمة
• لا نستطيع استلام تطبيق داخليّ صنعه من سبقنا
• الاتّصال بجهاز أو أداة قياس يتوقّف أحياناً
• الأمر يشمل 32bit / 64bit، وCOM / ActiveX، وتكامل VBA
• توقّف التطبيق عن العمل بعد الانتقال إلى Windows 11 أو جهاز جديد
• نريد تنظيم كلّ شيء، بما في ذلك التوزيع، وتوقيع الشيفرة، والتحديث التلقائيّ، وتحذيرات SmartScreen
• نريد التحقيق في الانهيارات أو تزايد استهلاك الذاكرة بعد تشغيل طويل

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

يلخّص هذا المقال، من منظور الجهة الطالبة، النقاط التي ينبغي تنظيمها قبل تكليف جهة خارجيّة بالتعهيد أو التطوير التعاقديّ لتطبيق Windows.

المجالات الأكثر شيوعاً في استشارات التطوير التعاقديّ لتطبيقات Windows

1. تطوير تطبيق أعمال جديد

هذه هي الحالات التي تُبنى فيها شاشات الإدخال، وشاشات البحث، وإخراج التقارير، وتكامل CSV، وتكامل الملفّات، والتكامل مع أنظمة خارجيّة تدعم العمليّات الداخليّة، في صورة تطبيق Windows.

أسباب اختيار تطبيق Windows بدلاً من تطبيق ويب تتلخّص عادةً في هذا:

• الحاجة إلى معالجة دقيقة للملفّات والمجلّدات على الكمبيوتر المحليّ
• الرغبة في التكامل مع أجهزة USB، وأدوات القياس، وPLC، والكاميرات
• الحاجة إلى الاستخدام في بيئات دون اتّصال أو شبكات مغلقة
• الرغبة في الاستفادة من أصول Excel وVBA وCOM وDLL القائمة
• الحاجة إلى استخدام لوحة مفاتيح، أو قارئ باركود، أو لوحة لمس على أجهزة الميدان
• الحاجة إلى مراقبة مقيمة أو معالجة في الخلفيّة

حتّى في التطوير الجديد، فإنّ تحديد ما إذا كان ينبغي أن يكون تطبيق Windows، أو ما إذا كان تطبيق ويب كافياً، أو ما إذا كان ينبغي إبقاء جزء فقط على جانب Windows، منذ البداية، يقلّل من التراجعات لاحقاً.

2. تعديل وصيانة برمجيّات Windows القائمة

في استشارات التعهيد الخارجيّ والتطوير التعاقديّ، يكون تعديل البرمجيّات القائمة وصيانتها أكثر شيوعاً من التطوير الجديد الكامل.

على سبيل المثال، حالات مثل هذه:

• الشيفرة المصدريّة موجودة، لكن لا أحد يعرف كيفيّة بنائها (build)
• لا تُفتَح إلّا بنسخة قديمة من Visual Studio
• توقّفت عند VB6 أو MFC أو WinForms أو .NET Framework
• استقال الموظّف المسؤول، ولا يوجد من يعرف المواصفات
• أصبح التشغيل غير مستقرّ بعد تحديث Windows أو استبدال الجهاز
• يطلب الشركاء أو العاملون في الميدان إضافة ميزات جديدة

في هذه الحالة، بدلاً من إعادة البناء فوراً، نبدأ أوّلاً بجرد الوضع الحاليّ:

• ما العمل الذي يدعمه التطبيق؟
• ما الميزات الأساسيّة التي لا غنى عنها؟
• في أيّ بيئة يعمل؟
• على أيّ أجهزة خارجيّة وDLL وقواعد بيانات ومجلّدات مشتركة يعتمد؟
• هل توجد سجلّات ومعلومات عن الأخطاء؟
• هل ما تزال الشيفرة المصدريّة، وتعليمات البناء، وبرنامج التثبيت، وملفّات الإعداد موجودة؟

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

إذا كان الأمر يتعلّق بـ COM / ActiveX / OCX، فابدأ بضبط المصطلحات في شرح شامل للفروق بين COM وActiveX وOCX، وفكّر في استراتيجيّة الانتقال باستخدام منظورات مثل جدول قرار الحفاظ / التغليف / الاستبدال لـ ActiveX/OCX لتسهيل المضيّ قُدماً.

3. تطبيقات تكامل الأجهزة والمعدّات الخارجيّة

في التصنيع، والفحص، والقياس، والمجالات المتّصلة بالطبّ، والاستخدامات البحثيّة، غالباً ما تكون تطبيقات Windows متّصلة بمعدّات خارجيّة.

من الأهداف النموذجيّة للتكامل:

• أجهزة الاتّصال التسلسليّ (serial)
• أجهزة USB
• الكاميرات الصناعيّة
• PLC
• أدوات القياس
• قارئات الباركود
• المجلّدات المشتركة وNAS
• مكتبات DLL أصليّة قائمة
• SDK المقدَّمة من الموردين

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

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

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

4. التحقيق في الأعطال وتحليل الأسباب

في التطوير التعاقديّ لتطبيقات Windows، يكون التحقيق في الأعطال أحياناً مطلوباً قبل إضافة الميزات.

من الاستشارات الشائعة:

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

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

في التحقيق في الانهيارات، يكمن المفتاح في كيفيّة الحفاظ على الأدلّة في لحظة الانهيار نفسها، كما هو موضّح في كيفيّة تسجيل السجلّات عند انهيار تطبيق Windows ومقدّمة في جمع ملفّات dump عند الانهيار (WER/ProcDump/WinDbg).

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

5. التوزيع والتوقيع والتحديث التلقائيّ

كثيراً ما يتعثّر تطبيق Windows، بعد اكتماله، عند سؤال «كيف يُوزَّع».

• هل سيُصنَع برنامج تثبيت؟
• أم يكفي وضع الملفّات ليعمل التطبيق مباشرةً؟
• هل يستطيع المستخدم القياسيّ تثبيته؟
• هل صلاحيّات المسؤول مطلوبة؟
• هل سيُوزَّع عبر مشاركة ملفّات داخليّة؟
• هل سيُحمَّل من الويب؟
• هل سيُحدَّث تلقائيّاً؟
• كيف تُدار شهادة توقيع الشيفرة؟
• كيف تُشرَح تحذيرات SmartScreen ويُتعامل معها؟

تشمل طرق التوزيع MSI وMSIX وClickOnce وxcopy، وأدوات تحديث (updater) مخصّصة. ينبغي ألّا يُبنى الاختيار على «أيّها أبسط»، بل على ما يُسجَّل لدى نظام التشغيل، ومن يتحمّل مسؤوليّة التحديث. لمزيد من التفاصيل، راجع دليل اختيار طريقة توزيع تطبيقات Windows.

بالنسبة لتطبيق Windows داخليّ مبنيّ بـ .NET، يُراد توزيعه على مستخدمين قياسيّين مع تحديث تلقائيّ خفيف، راجع مقدّمة إلى ClickOnce: التوزيع والتحديث ومعايير الاختيار.

من ناحية أخرى، يثير التوزيع عبر الويب أو خارج الشركة قضايا تحذيرات SmartScreen وتوقيع الشيفرة. سبب ظهور رسالة «قامت Windows بحماية الكمبيوتر الخاصّ بك» موضَّح في لماذا تُظهر Windows رسالة «قامت Windows بحماية الكمبيوتر الخاصّ بك».

خمسة أمور ينبغي تنظيمها قبل تكليف جهة خارجيّة بالتعهيد أو التطوير التعاقديّ لتطبيق Windows

1. ما الذي لا ينبغي أن يتوقّف

أوّل ما ينبغي تنظيمه ليس قائمة الميزات، بل «الأعمال التي يسبّب توقّفها مشكلة».

• توقّف معالجة الطلبات
• توقّف خطّ الفحص
• تعذّر إصدار التقارير
• انقطاع الاتّصال بالجهاز
• عودة العاملين في الميدان إلى العمل اليدويّ
• عدم بقاء سجلّات التدقيق والأدلّة

في التطوير التعاقديّ، لا يقتصر التصميم على بناء الشاشات والميزات، بل يمتدّ إلى ضمان عدم توقّف العمل. عند وضوح هذه الأولويّات، يصبح من الأسهل تحديد الميزات التي ينبغي بناؤها، والميزات التي يمكن تأجيلها، والأعطال التي ينبغي التحقيق فيها أوّلاً.

2. التطبيق الحاليّ والبيئة المحيطة به

عند تعديل تطبيق قائم وصيانته، لا يُفحَص التطبيق وحده، بل تُفحَص البيئة المحيطة به أيضاً.

من المعلومات التي يستحقّ توضيحها:

• اسم التطبيق، والغرض منه، والأقسام التي تستخدمه
• عدد المستخدمين وعدد الأجهزة
• إصدارات Windows
• 32bit / 64bit
• إصدارات .NET Framework / .NET
• إصدار Visual Studio
• قواعد البيانات، والمجلّدات المشتركة، وواجهات API الخارجيّة
• الأجهزة، وDLL، وSDK المتكاملة معه
• إجراء التثبيت
• موقع ملفّات الإعداد
• موقع السجلّات
• وجود الشيفرة المصدريّة أو عدمه
• وجود تعليمات البناء أو عدمها
• وجود مستندات تركها من سبق أو عدمها

كلّما توفّرت هذه المعلومات بشكل أكبر، زادت دقّة العروض السعريّة والتحقيقات. وعلى العكس، عندما تكون المعلومات ناقصة، فمن الأسلم فصل المرحلة الأولى وجعلها «تحقيقاً في الوضع الحاليّ».

3. أيّها تختار: تطوير جديد، أم تعديل، أم استبدال؟

في استشارات تطبيقات Windows، من الأفضل أحياناً عدم الحسم منذ البداية بـ«إعادة البناء».

يعتمد قرار الاستمرار في استخدام تطبيق .NET Framework أو الانتقال إلى .NET على نوع التطبيق، والمكتبات المعتمَد عليها، وتكامل COM، وطريقة التوزيع. إجراء جرد مسبق لنقاط التحقّق، كما في قائمة تحقّق ما قبل الانتقال من .NET Framework إلى .NET، يسهّل القرار كثيراً.

4. التوزيع والتحديث والصلاحيّات

في تطبيقات Windows، يكون العائق أحياناً في التوزيع لا في التطوير.

النقاط التي يستحقّ التحقّق منها بشكل خاصّ:

• هل سيُستخدَم بصلاحيّات مستخدم قياسيّ؟
• هل توجد عمليّات تتطلّب صلاحيّات مسؤول؟
• هل التثبيت لجميع المستخدمين، أم يكفي على مستوى كلّ مستخدم؟
• هل الاستخدام داخليّ فقط، أم سيُوزَّع خارج الشركة أيضاً؟
• هل التحديث التلقائيّ مطلوب؟
• هل توجد أجهزة تعمل دون اتّصال؟
• هل توقيع الشيفرة مطلوب؟
• هل يلزم التعامل مع Microsoft Defender SmartScreen؟
• هل توجد سياسات إدارة مثل Intune أو GPO أو App Control؟

الفصل بين العمليّات التي تتطلّب صلاحيّات مسؤول وتلك التي لا تتطلّبها يرفع مستوى الأمان وسهولة التشغيل في الاستخدام اليوميّ. يمكن التحقّق من حدود الصلاحيّات باستخدام منظورات مثل متى تكون صلاحيّات مسؤول Windows مطلوبة ومتى لا تكون.

5. سهولة الصيانة

ما يهمّ في التطوير التعاقديّ ليس فقط أن يعمل التطبيق عند التسليم. بل يُراد أن يُترَك في حالة تتيح، حتّى بعد سنوات، لموظّف مسؤول آخر أن يحقّق فيه، ويعدّله، ويعيد توزيعه.

تطبيقات Windows السهلة الصيانة لها هذه الخصائص:

• تعليمات البناء محفوظة
• المكتبات المعتمَد عليها وإصداراتها معروفة
• موقع ملفّات الإعداد ومعناها معروفان
• تُصدَر السجلّات بمستوى تفصيل مفيد للتحقيق
• تبقى أدلّة عند الانهيار
• توجد إجراءات للتوزيع والتراجع
• المسؤوليّات داخل الشيفرة المصدريّة مفصولة بوضوح
• العمليّات التي تتطلّب صلاحيّات مسؤول محدودة النطاق
• المعلومات السرّيّة لا تُخزَّن بنصّ صريح

بالنسبة للتحقّق الأمنيّ الأدنى قبل الإصدار، تُفحَص الصلاحيّات، والتوقيع، والمعلومات السرّيّة، والاتّصال، والمُدخَلات، وDLL، والسجلّات، كما في قائمة تحقّق الأمان لتطبيقات Windows.

عند تخزين كلمات المرور أو الرموز (tokens) في ملفّات الإعداد، يجب تجنّب التخزين بنصّ صريح، وتصميم حماية باستخدام آليّات Windows. لمزيد من التفاصيل، راجع كيفيّة تخزين المعلومات السرّيّة في ملفّات الإعداد بأمان.

قرارات شائعة في اختيار تقنيّة تطبيقات Windows

الاختيار بين WinForms وWPF وWinUI

في تطوير تطبيق Windows جديد، يظلّ اختيار ما بين WinForms وWPF وWinUI نقطة نقاش متكرّرة.

بالمقارنة الإجماليّة، يكون الأمر كالآتي:

لكن التقنيّة الأحدث ليست دائماً الإجابة الصحيحة. يجب أن يشمل الاختيار خبرة الفريق القائم، وفترة الصيانة، وطريقة التوزيع، ومتطلّبات الشاشة، والمكتبات المحيطة.

لمزيد من التفاصيل، راجع جدول القرار في دليل اختيار WinForms/WPF/WinUI.

هل يكفي C# / .NET، أم أنّ الأمر يتطلّب C++ أو مكتبات DLL أصليّة؟

يمكن بناء معظم تطبيقات الأعمال بشكل كافٍ باستخدام C# / .NET. لكن في حالات مثل التالية، يُنظَر أحياناً في استخدام C++، ومكتبات DLL أصليّة، وP/Invoke، وC++/CLI، وCOM:

• SDK المورّد موجَّهة لـ C/C++
• الحاجة إلى استدعاء مكتبات DLL قائمة
• وجود معالجة صور عالية السرعة أو تحكّم في أجهزة
• الحاجة إلى استخدام أصول COM قائمة
• الحاجة إلى تجاوز حدّ 32bit / 64bit

في مثل هذه المشاريع، يجب تنظيم ليس فقط سهولة بناء الواجهة، بل أيضاً حدود العمليّات (process boundaries)، وملكيّة الذاكرة، والاستثناءات، والخيوط (threads)، وبِتّيّة النظام (bitness).

تطبيق Windows أم تطبيق ويب؟

نتلقّى أيضاً استشارات من نوع «نريد تحويل تطبيق Windows قديم إلى تطبيق ويب». أحياناً يكون التحويل إلى الويب مناسباً، لكن ليس كلّ شيء يجب أن يصبح تطبيق ويب.

يناسب تطبيق Windows، على سبيل المثال، الحالات التالية:

• الاتّصال المباشر بأجهزة أو معدّات محليّة
• الاستخدام دون اتّصال
• التعامل مع ملفّات محليّة كبيرة
• استخدام أصول COM / DLL / VBA قائمة
• الحاجة إلى تشغيل سريع على أجهزة الميدان
• الحاجة إلى مراقبة مقيمة أو معالجة في الخلفيّة

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

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

كيف يسير التطوير التعاقديّ

يمكن تنفيذ التعهيد الخارجيّ والتطوير التعاقديّ لتطبيق Windows بأمان على النحو التالي.

1. فهم الوضع الحاليّ

أوّلاً، يُنظَّم العمل المستهدَف، وبيئة الاستخدام، والتطبيق القائم، والمعدّات الخارجيّة، وطريقة التوزيع، والأعراض المسبّبة للمشكلة.

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

2. تصميم نقاط المراقبة

عند وجود أعطال أو عدم استقرار، يُجعَل السبب قابلاً للتتبّع أوّلاً، قبل الشروع في التعديل مباشرةً:

• إضافة سجلّات
• الحصول على ملفّات dump عند الانهيار
• الاحتفاظ بسجلّات الاتّصال
• تسجيل الذاكرة وعدد الـ handles
• الاحتفاظ بسجلّ العمليّات
• حفظ لقطات الشاشة والحالة عند حدوث الشذوذ

كلّما كانت المشكلة أصعب في إعادة الإنتاج، زادت فائدة تصميم نقاط المراقبة.

3. تحديد التوجّه

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

في هذه المرحلة، يُحدَّد أيضاً اختيار التقنيّة، وطريقة التوزيع، وطريقة التحديث، ونطاق الصيانة.

4. التنفيذ والاختبار

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

في الاختبار، يُتحقَّق ليس فقط من الحالات الطبيعيّة، بل من الحالات غير الطبيعيّة أيضاً:

• الجهاز غير متّصل
• انقطاع الاتّصال في منتصف العمليّة
• ملفّ مقفل
• نقص في الصلاحيّات
• عدم استقرار الشبكة
• تلف الإعدادات
• فشل التحديث
• إنهاء التطبيق بشكل غير طبيعيّ

5. التوزيع والانتقال

بعد الاكتمال، تُعَدّ إجراءات التوزيع، والتحديث، والتراجع، والإعداد الأوّليّ، والشرح الموجَّه للمستخدمين.

عند الانتقال من تطبيق قائم، تُدرَج في الخطّة عمليّة التشغيل الموازي للقديم والجديد، والتراجع، ونقل البيانات، وتدريب المستخدمين.

6. الصيانة والتحسين

بعد التسليم، يُحسَّن التطبيق بما يناسب التشغيل الفعليّ، بمراقبة السجلّات ومحتوى الاستفسارات.

تتأثّر تطبيقات Windows بتحديثات نظام التشغيل، واستبدال أجهزة الكمبيوتر، وتغيّر المعدّات المحيطة، وتغيّر سياسات الأمان. لذلك، فإنّ التصميم والتوثيق القائمَين على افتراض الصيانة أمران لا غنى عنهما.

معلومات يُستحسَن تجهيزها قبل تقديم عرض سعر

لا يلزم أن يكون كلّ شيء متوفّراً وقت الاستشارة. لكن توفّر المعلومات التالية يجعل الحديث يتقدّم بسرعة أكبر:

• الغرض من التطبيق
• ما يسبّب المشكلة حاليّاً
• عدد المستخدمين وعدد الأجهزة
• إصدارات Windows
• وجود تطبيق قائم أو عدمه
• وجود الشيفرة المصدريّة أو عدمه
• لغة التطوير والإطار المستخدَم
• الأجهزة وقواعد البيانات والملفّات وواجهات API المتكاملة
• شاشات الأخطاء والسجلّات
• خطوات إعادة الإنتاج
• الموعد المرغوب للتسليم
• الأعمال التي لا يجب أن تتوقّف مطلقاً
• التوزيع الداخليّ أم الخارجيّ
• الحاجة إلى الصيانة أيضاً

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

خلاصة

عند تكليف جهة خارجيّة بالتعهيد أو التطوير التعاقديّ لتطبيق Windows، فإنّ مجرّد قول «نريد منكم بناء تطبيق» يجعل النطاق المطلوب صعب الرؤية.

هذه هي النقاط السبع التي ينبغي ضبطها قبل الطلب:

• هل هو تطوير جديد، أم تعديل لما هو قائم، أم استبدال؟
• ما الأعمال التي لا ينبغي أن تتوقّف؟
• هل توجد أصول قائمة، ومعدّات خارجيّة، وDLL، وCOM، وActiveX؟
• اختيار التقنيّة: WinForms، وWPF، وWinUI، والانتقال إلى .NET، وما شابه
• كيفيّة التعامل مع التوزيع، والتوقيع، والتحديث التلقائيّ، وصلاحيّات المسؤول
• تصميم التحقيق في السجلّات، وملفّات dump عند الانهيار، والذاكرة، والاتّصالات
• كيفيّة ترك التطبيق في حالة قابلة للصيانة بعد التسليم

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

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

استشرنا بخصوص تطوير تطبيقات Windows

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

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

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

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

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

هل يمكن استشارتكم حتى بدون توفّر الشيفرة المصدريّة؟

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

هل يمكن استشارتكم حتى في تطبيق يحتوي على VB6 وVBA وCOM وActiveX قديمة؟

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

هل ينبغي استبدال تطبيق Windows الخاصّ بنا بتطبيق ويب؟

الأمر يعتمد على الهدف. تناسب تطبيقات الويب حالات تعدّد المواقع، وتبسيط إدارة الأجهزة، والاستخدام عبر المتصفّح. من ناحية أخرى، إذا كان هناك تكامل مع أجهزة، أو معالجة ملفّات محليّة، أو تشغيل دون اتّصال، أو استخدام لمكتبات DLL قائمة، فقد يكون الإبقاء على تطبيق Windows الخيار الأنسب. وبدلاً من تحويل كلّ شيء إلى الويب، فإنّ تقسيم المسؤوليّات بين جانب Windows وجانب الويب خيار آخر متاح.

هل يمكن تكليفكم بالتحقيق في الأعطال فقط؟

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

هل يمكنكم بناء تطبيقات تتطلّب صلاحيّات المسؤول؟

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

هل يمكنكم تطوير تطبيقات Windows الصغيرة للاستخدام الداخليّ تعاقديّاً؟

نعم. حتّى بالنسبة للتطبيقات الصغيرة، فإنّ التفكير مسبقاً في التوزيع، والتحديثات، وتسجيل السجلّات، والإعدادات، والنسخ الاحتياطيّ، وتسليم المسؤوليّة عند تغيير الموظّف المسؤول، يجعلها سهلة الاستخدام لفترة أطول. وبشكل خاصّ، فإنّ التحسينات الصغيرة في العمل مثل أتمتة أعمال Excel، وتحويل CSV، ومراقبة الملفّات، وإخراج التقارير، وجمع بيانات الأجهزة، غالباً ما يكون تطبيق Windows خياراً مناسباً لها.

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

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

غو كومورا

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

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