هل يصحّ أن تبقى وثيقة المواصفات في التطوير التعاقديّ على شكل Excel؟ ── اختيار الصيغة المناسبة كمُسلَّم

«استلمت النسخة المعدَّلة من وثيقة المواصفات، لكنّني ختمت الاستلام دون أن أعرف أين تغيّرت»

«أردت طلب تعديل فإذا وثيقة المواصفات بـ Excel التي سُلِّمت تختلف تماماً عن الشاشة الحالية»

«وصلت من شركة التطوير وثيقة مواصفات Excel على شكل ورق مربَّع، فهل هذا هو المعتاد؟»

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

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

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

نلخّص النقاط أوّلاً.

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

جدول قرار الصيغة الموصى بها حسب طبيعة الوثيقة كالتالي.

فيما يلي نشرح بالترتيب لماذا يكون الأمر كذلك.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 18، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. وثيقة مواصفات Excel المربَّع كمُسلَّم: ما المشكلة؟

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

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

2.1 يتعذّر استكمال المراجعة في الفحص والاستلام

ليس لورق Excel المربَّع آليّة عمليّة لعرض الفرق تعادل سجلّ تغييرات Word. بدقّة، في بيئة التحرير المشترك في Microsoft 365 يوجد سجلّ تغيير الخلايا («عرض التغييرات» وسجلّ الإصدارات)، وتوجد أيضاً أدوات مثل Spreadsheet Compare لمقارنة المصنّفات. لكن ما يُتتبَّع محورُه قيم الخلايا والصيغ، والنصّ داخل الأشكال ومربّعات النصّ التي تكثر في وثيقة الورق المربَّع خارج النطاق، وفي ميدان التسليم الذي يذهب فيه الملفّ ويعود كمرفق بريد لا تعمل سجلّات التحرير المشترك أصلاً.

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

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

2.2 لا يبقى سجلّ اتّفاق تغيير المواصفات

أثناء التطوير تتغيّر المواصفات حتماً. عندما تكون الوثيقة ورق Excel مربَّعاً، يميل تبادل التغيير إلى «جبل من نسخ الملفّات». كثيرون يعرفون أسماء مثل 仕様書_v2_最終_修正(2).xlsx.

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

2.3 تتباعد عن التنفيذ في مرحلة الصيانة

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

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

2.4 يتعذّر الانتفاع بها في يد العميل

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

3. منظور العقد ── وثيقة المواصفات «مُخرَج»

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

أي أنّ حديث Excel أم Word لا معنى له إلّا بعد ثبات الأساس التالي.

• أيّ وثائق مُخرَج: ليست «مجموعة وثائق» بل قائمة على مستوى اسم الوثيقة
• بأيّ صيغة تُستلم: هل تشمل أصلاً قابلاً للتعديل (ملفّ Word أو Excel). PDF فقط يُربك في الصيانة
• طريقة الفحص والاستلام: ما الذي يُؤكَّد ثمّ يُقبَل. كيف يُعرض فرق النسخة المعدَّلة
• حقوق المؤلّف والانتفاع الثانويّ: هل يستطيع العميل النسخ والتعديل داخليّاً. هل يمكن تسليم الوثيقة عند إسناد الصيانة لاحقاً لشركة أخرى

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

4. خيارات صيغة التسليم ── المقارنة بـ «هل تقوم كمُسلَّم»

بعد ثبات الأساس تُختار الصيغة. محاور التقييم كما في المقدّمة أربعة: سهولة قراءة العميل / سهولة المراجعة والفحص والاستلام / إدارة فرق تغيير المواصفات / الاستدامة في مرحلة الصيانة.

معنى رموز التقييم كالتالي. الحكم على «هل الآليّة مضمَّنة في الصيغة كأداة»، ولا يشمل إمكان التغطية بابتكار تشغيليّ.

مواضع △ الثلاثة نكتب أسبابها أوّلاً.

• إدارة فرق Excel △: لأنّه لا توجد آليّة تُظهر الفرق بالأحمر تعادل سجلّ تغييرات Word. يوجد سجلّ إصدارات قيم الخلايا وSpreadsheet Compare، لكنّهما يفترضان بيئة تحرير مشترك أو يستثنيان النصّ داخل الأشكال ومربّعات النصّ (الفقرة 2.1). في النهاية تُكمَّل بقاعدة تشغيل «إرفاق قائمة مواضع التغيير على حدة».
• استدامة PDF في الصيانة △: للقراءة لا مشكلة، لكن يتعذّر الاستمرار في التحديث مع الحفاظ على البنية، فيلزم أصل قابل للتعديل منفصل (الفقرة 4.3).
• استدامة Wiki في الصيانة △: سهولة التحديث في أعلى مستوياتها بالعكس، لكن بقاء الوثيقة بعد انتهاء العقد يعتمد على عقد الأداة وإعداداتها. إن لم يُحسَم إمكان التصدير وملكيّة المساحة وتعامل الحسابات أوّلاً، يُفقد الوصول إلى الوثيقة لحظة انتهاء العقد (الفقرة 4.5).

نضيف لكلٍّ.

4.1 Word ── المرشّح الأوّل لوثيقة مواصفات محورها النصّ

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

• أنماط العناوين وفهرس تلقائيّ: تتّضح بنية الوثيقة، ويمكن الانتقال من الفهرس إلى الموضع المقصود
• سجلّ التغييرات (وظيفة المراجعة): أين تغيّر في النسخة المعدَّلة يظهر بالأحمر. فاعليّة المراجعة والفحص والاستلام تختلف اختلافاً كبيراً
• وظيفة التعليقات: ملاحظات العميل والردّ عليها تبقى على الوثيقة
• مقارنة الوثائق: يمكن عرض فرق نسختين لاحقاً أيضاً

ميزة عمليّة كبيرة أيضاً أنّ جهة العميل لا تحتاج أداة خاصّة ولا تعلّماً، وأنّ الصيغة تمرّ كما هي كصيغة تسليم.

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

4.2 أعد Excel إلى «جدول حقيقيّ»

وثائق مثل تعريف عناصر الشاشة وقائمة الرموز ومصفوفة الصلاحيّات جداول في جوهرها. كتابتها في Word غير مريحة بالعكس، وExcel هو الجواب الصحيح. لكن ليس ورقاً مربَّعاً، بل جدولاً صريحاً يمكن التعامل معه كبيانات.

• صفّ واحد لسجلّ واحد، وعمود واحد لصفة واحدة. في الورقة جدول واحد فقط
• لا تُصنع تخطيطات بدمج الخلايا. العنوان صفّ واحد في الصفّ الأوّل
• لا تُكسَر بنية البيانات لأجل مظهر الطباعة (هيئة الطباعة بوسيلة أخرى)

إن صُنع هكذا، يمكن التعامل مع الوثيقة آليّاً وقت الصيانة. تصير إعادة الاستخدام نافذة: مضاهاة تعريف العناصر بتعريف قاعدة البيانات الفعليّ، واتّخاذ القائمة أساساً لبنود الاختبار كما هي، فيسهل «التأكيد على أنّ الوثيقة لم تتباعد عن التنفيذ» نفسه.

4.3 PDF ── صيغة تجميد «النسخة المتَّفق عليها»

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

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

مبدأ آخر بسيط. PDF دائماً مع أصل قابل للتعديل. تسليم PDF فقط يضيّق خيارات العميل المستقبليّة (الانتفاع داخل الشركة، إسناد الصيانة لشركة أخرى).

4.4 أصل Markdown + Git، وتوليد Word / PDF للتسليم

كإدارة في جهة شركة التطوير، انتشر في السنوات الأخيرة كتابة وثيقة المواصفات بـ Markdown وإدارة الإصدارات في مستودع Git نفسه مع الشيفرة المصدر. يُؤخذ الفرق على مستوى السطر، ويمكن مراجعة الوثيقة بالآليّة نفسها لمراجعة الشيفرة، وتبقى مسار التغيير كسجلّ (يكفي كسجلّ ممارسة تطوير، لكن إن طُلب دليل تدقيق أو نزاع يلزم تشغيل منفصل مثل منع إعادة كتابة السجلّ).

عندها لا يلزم طلب Git من العميل. إن صار التكوين إدارة الأصل بـ Markdown، وتوليد المُسلَّم كـ Word أو PDF بأداة تحويل مثل Pandoc، يستلم العميل Word/PDF كالمعتاد فقط. يمكن الجمع بين كفاءة إدارة جهة التطوير وسهولة قراءة جهة العميل.

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

التدفّق بالرسم كالتالي.

[جهة شركة التطوير]
  كتابة وثيقة المواصفات بـ Markdown
        ↓
  الإدارة في مستودع Git نفسه مع الشيفرة المصدر
    · الفرق يظهر على مستوى السطر
    · يمكن مراجعة الوثيقة بالآليّة نفسها لمراجعة الشيفرة
    · متى ومن ولماذا غيّر يبقى في السجلّ
        ↓
  التحويل بـ Pandoc (تحديد ملفّ Word نموذج الشركة كهيئة)
        ↓
  يُولَّد Word / PDF
        ↓
─────────── التسليم ───────────
        ↓
[جهة الطلب]
  استلام Word / PDF كالمعتاد والقراءة والمراجعة
        ↓
  طلب التعديل يُردّ «بتعليق» (لا تُعاد كتابة المولَّد مباشرة)
        ↓
  جهة التطوير تعكسه في Markdown الأصل وتعيد التوليد وتعيد التسليم

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

4.5 Wiki وأدوات عبر الإنترنت ── «وثيقة حيّة» عند وجود صيانة مستمرّة

في منظومة يتواصل فيها عقد الصيانة وتتكرّر التعديلات، شكل التحديث المستمرّ لوثيقة المواصفات بأداة عبر الإنترنت مثل Notion أو Confluence أيضاً قويّ. البحث قويّ، وسجلّ التغيير يبقى تلقائيّاً، ويسهل الحفاظ على «وثيقة حيّة» لا «تسليم ثمّ انتهى».

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

5. كيف يُدار تبادل تغيير المواصفات؟

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

1. جهّز سجلّ إدارة تغيير واحداً: قائمة تسجّل في صفّ واحد رقم التغيير والتاريخ والمحتوى والأثر (تكلفة/أجل) ومن وافق. هذا نفسه يكفي كجدول Excel صريح. يُقابل إجراءات إدارة التغيير في عقد IPA النموذجيّ (راجع المقال المذكور)
2. تعديل الوثيقة يذهب ويعود بشكل يظهر فيه الفرق: في Word تُرسل النسخة المعدَّلة مع تشغيل سجلّ التغييرات، ويؤكّد العميل محوره الأحمر. إن خيف إغفال إلحاق سجلّ التغيير، يستطيع المستلم أيضاً كشف الإغفال بمضاهاة النسخة المتَّفق عليها السابقة بوظيفة «مقارنة» في Word. بعد الاتّفاق تُعكس السجلّات وتُثبَّت النسخة
3. احسم قاعدة رقم النسخة: نسخة الفحص والاستلام v1.0، وعند كلّ اتّفاق تغيير تُرفع إلى v1.1 وv1.2. لا تُستخدم «نهائيّ» و«تعديل» و«(2)» في اسم الملفّ
4. النسخة المتَّفق عليها تُجمَّد بـ PDF ويحفظها الطرفان: حتّى يستطيع أيّ شخص لاحقاً تحديد بأيّ نسخة اتُّفق

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

6. ما ينبغي أن تؤكّده جهة الطلب قبل التعاقد

لجهة الطلب نلخّص ما ينبغي التحقّق منه في مرحلة التقدير والتعاقد كقائمة فحص.

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

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

الخلاصة

نلخّص نقاط هذا المقال عن وثيقة المواصفات المسلَّمة في التطوير التعاقديّ.

• صيغة وثيقة المواصفات المسلَّمة تُختار من منظور الفحص والاستلام وتغيير المواصفات والصيانة. لا تُختار بـ «هل يسهل الكتابة أثناء التطوير» وحده
• المشكلة الجوهريّة لورق Excel المربَّع هي تفريغ الفحص والاستلام من مضمونه لأنّ الفرق لا يُرى، وفقدان سجلّ الاتّفاق، والتباعد عن التنفيذ بسبب ارتفاع تكلفة التحديث
• الخلاصة ليست «إلغاء Excel كلّه» بل العودة إلى الأداة المناسبة لكلّ غرض. النصّ Word (أنماط + سجلّ تغييرات)، والجدول جدول Excel صريح، وسجلّ الاتّفاق تجميد PDF
• تكوين إدارة أصل جهة التطوير بـ Markdown+Git وتوليد Word/PDF كمُسلَّم يستطيع الجمع بين مزيّتَي الطرفين
• قبل الصيغة يُحسَم في العقد قائمة المُخرَجات وتسليم أصل قابل للتعديل وتعامل حقوق المؤلّف. اتّفاق قاعدة التشغيل هو الجوهر أكثر من الأداة

وحديث قراءة Excel وكتابته من البرنامج (إخراج التقارير) في «كيف تبني إخراج تقارير Excel - COM وOpen XML والقوالب»، وتركيب العقد في مقال شرح عقد المعاملات النموذجيّ لـ IPA. يُرجى الاطّلاع مع هذا المقال.

روابط مرجعية

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

لمن ينظر في إسناد التطوير التعاقديّ أو الصيانة

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

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

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

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

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

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

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

حدّدت الجهة الطالبة قالب ورق Excel المربَّع. هل يجب الالتزام به؟

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

سُلِّمت وثيقة المواصفات بصيغة PDF فقط. هل هذا مقبول؟

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

إلى أيّ درجة من التفصيل ينبغي أن تُكتَب وثيقة المواصفات؟

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

من المسؤول عن تحديث وثيقة المواصفات بعد التسليم؟

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

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

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

غو كومورا

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

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