هندسة البرمجيات والمنصّات في القطاع العام

هذا لماذا يهم في القيمة العامة

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

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

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

المفاهيم الأساسية

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

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

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

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

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

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

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

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

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

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

أفضل الممارسات

1. انحز افتراضيًا للشراء للحاجات غير المتمايزة، واحتفظ بالبناء لما هو متمايز فعلًا. نادرًا ما تختلف حاجات كشوف الرواتب والبريد الإلكتروني وإدارة الحالات العامة بما يكفي عن أي منظمة أخرى لتبرير برمجيات مُفصَّلة.
2. اجعل الدين التقني مرئيًا قبل تقرير كم منه تحمل. احتفظ بسجلّ اختصارات معروفة، وإصلاحات مؤجَّلة، وتبعيات غير مدعومة لكل نظام في الخدمة، يُراجَع بدورة ثابتة.
3. لا تخطّط أبدًا لتحوّل واحد ولا رجعة فيه المسار الوحيد للخروج من نظام موروث حرج. فضِّل مناهج تدريجية كنمط التين الخانق تتيح اختبار كل قطعة، وعكسها، وطرحها تدريجيًا؛ استبدال دفعة واحدة لنظام يعتمد عليه ملايين يركّز سنوات من المخاطرة في نهاية أسبوع واحدة بلا طريق عودة إن فشل شيء.
4. عامِل الكود المصدري الذي تدفع منظمتك لكتابته أصلًا تملكه، لا خدمة تستأجرها. تفاوض على إيداع الكود المصدري أو الملكية الكاملة عند التعاقد، لا بعد بدء نزاع.
5. انشر الكود المصدري مفتوحًا افتراضيًا، واطلب تبريرًا محدَّدًا لحجبه. سياسة "مفتوح المصدر افتراضيًا"، مُطبَّقة باتساق، تحوِّل برمجيات كل وزارة المُخصَّصة إلى أصل مشترك عابر للحكومة بدلًا من تكلفة لمرة واحدة.
6. اكتب عقود برمجيات تجعل التسليم التكراري قانونيًا، لا ممكنًا تقنيًا فقط. عقد يدفع فقط مقابل مواصفة ثابتة مُتَّفَق عليها عند التوقيع يُجبِر فريقًا على الاختيار بين ممارسة رشيقة صادقة والامتثال التعاقدي؛ استخدم بوابات تمويل مرحلية مرتبطة ببرمجيات عاملة مُثبَتة بدلًا من معلم واحد في النهاية.
7. موِّل التحديث برنامجًا مستمرًّا، لا مشروعًا رأسماليًا لمرة واحدة. نظام موروث حُدِّث مرة ثم تُرِك لعشرين عامًا أخرى يتراكم المخاطرة نفسها التي بدأ بها.
8. اختر معايير مفتوحة وصيغ بيانات قابلة للنقل حتى عند شراء برمجيات تجارية. مطالبة نظام مورِّد بتخزين البيانات وتصديرها بصيغ مفتوحة وموثَّقة يُبقي تكاليف التحوّل منخفضة حتى حيث تكون البرمجيات نفسها مسجَّلة الملكية.
9. ابنِ منتجًا قابلًا للتطبيق أدنى وأظهره لمستخدمين حقيقيين قبل الالتزام بالنطاق الكامل. إصدار نسخة دنيا فعلًا، ثم التكرار على ما تعلّمته، يكتشف افتراضات خاطئة بينما لا تزال رخيصة الإصلاح.
10. أبقِ قدرة هندسية داخلية كافية لتكون مشترٍ ذكيًا، حتى حيث يُتعاقَد على التسليم خارجيًا. هيئة عامة جوّفت خبرتها التقنية لا تستطيع تقييم مقترح مورِّد، أو رصد علامات إنذار مبكرة لمشروع مُضطَرِب، أو التفاوض للخروج من احتجاز.
11. تقاعد عن ملف مخاطرة نظام موروث قبل واجهة مستخدمه. أعطِ أولوية لاستبدال لغات غير مدعومة، وبنية تحتية غير مُرقَّعة، وتكاملات غير موثَّقة — الإخفاقات التي تسبّب انقطاعات واختراقات — قبل تحديث بصري يحمل مخاطرة تشغيلية أقل بكثير.
12. قِس صحة التسليم بمؤشرات هندسية، لا فقط تفاوت الميزانية والجدول. تخبر وتيرة النشر، ومعدّلات العيوب، وعمر أقدم بند دين تقني غير معالَج مجلس حوكمة عن نجاح برنامج أكثر مما تخبره ميزانيته الحالية.

أسئلة للنقاش مع فريقك

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

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

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

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

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

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

في الممارسة: مثال على القيمة العامة

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

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

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

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

أربعة منظورات قطاعية

الحكومة المحلية

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

الحكومة الوطنية

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

القطاع الاجتماعي وغير الربحي

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

المتعدد الأطراف والدولي

تروِّج الهيئات المتعددة الأطراف ووكالات التنمية بازدياد لبرمجيات بُنيت لإدارة عامة لبلد واحد سلعة عامة رقمية قابلة لإعادة الاستخدام يمكن لبلدان أخرى تكييفها، بدلًا من أن تُكلِّف كل حكومة بنظام معادِل من مورِّد خاص بالتكلفة الكاملة. المخاطرة المميِّزة هنا أن سلعة عامة رقمية بُنيت لسياق قانوني وإداري لبلد واحد يمكن تبنّيها في مكان آخر بتكييف قليل جدًا، مُستورِدة افتراضات — حول الهوية، أو الأهلية، أو العملية — لا تنتقل فعلًا.

أنماط الفشل الشائعة

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

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

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

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

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

نموذج النضج

قائمة التحقق

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

المصادر الرئيسية

• معيار خدمة GOV.UK، خدمة الحكومة الرقمية البريطانية — معيار خدمة رقمية وطني يتطلب تسليمًا تكراريًا ومُتمحوِرًا حول المستخدم ومعايير مفتوحة.
• مكتب الإدارة والميزانية، سياسة الكود المصدري الفيدرالي (M-16-21)، الولايات المتحدة — السياسة الفيدرالية التي تتطلب من الوكالات دراسة إعادة الاستخدام والإصدار مفتوح المصدر.
• مؤسسة البرمجيات الحرة أوروبا، حملة مال عام، كود عام — المنطق لنشر كود برمجيات مُموَّلة عامة تحت تراخيص حرة ومفتوحة المصدر.
• وارد كننغهام، "نظام إدارة محفظة WyCash" (تقرير خبرة OOPSLA 1992) — البيان الأصلي لاستعارة الدين التقني.
• تحالف السلع العامة الرقمية — مبادرة متعدِّدة أصحاب المصلحة تحفظ معايير وسجلًّا للبرمجيات والبيانات والمحتوى المفتوح المُصمَّم لخدمة أهداف تنمية عامة.

المراجع

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. 'The WyCash Portfolio Management System' (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/