CGI POC
1.0.0
Github: https://github.com/cgi- zahid/cgi-poc
التطبيق: [https://mycalerts.com]
احصل على بيانات اعتماد المستخدم النهائية وعينة
توظف مقاربة CGI في مجموعة البائعين المؤهلين مسبقًا للخدمات الرقمية-تطوير Agile (PQVP DS-AD) تقنيات التصميم المتمحورة حول المستخدمين ، وتنفيذ سير عمل تنمية قائم على العدو وتقنيات Mycalerts الحديثة والمصادر المفتوحة للتصميم ، والاشتراك في Mycalerts ، وتنفيذنا للنمط الأولي العام. تتبع إخطاراتهم السابقة. يمكن للمستخدمين تلقي الإخطارات عبر خدمة الرسائل القصيرة (SMS) والبريد الإلكتروني بناءً على موقع الشارع ومعلومات الاتصال المقدمة في ملف تعريف المستخدم الخاص بهم. تتيح MyCalerts للمستخدمين الإداريين المعتمدين تتبع الأحداث وتصورها وإرسال إشعارات عن أحداث الطوارئ وغير الطوارئ المخصصة.
بدأنا بمراجعة مسودة RFI. أنشأ CGI فريقنا وبدأت Sprint 0 التخطيط. لقد حددنا الهندسة المعمارية والبيئات التقنية التي نستخدمها. لقد نشرنا أدوات المطورين القياسية وموارد التعاون الرشيقة ، لإنشاء تطبيق "Hello World" (صفحة تسجيل دخول بسيطة) لاختبار إطار عملنا التقني والتكامل/النشر المستمر (CI/CD).
عند استلام RFI النهائي ، قاد مدير منتجاتنا (PM) جلسة تحليل النموذج الأولي. اجتمع الفريق وعقد جلسة تخطيط وتغيير حجمها لتقييم التعقيد واهتمام الفريق ومخاطر كل نموذج أولي. بحماس كبير اختار فريقنا النموذج الأولي العام
استنادًا إلى مقابلات المستخدم الأولية ، حدد PM مجموعات البيانات الثلاث التي تعتبر أكثر صلة بمستخدمي CA. انتخب للاستطلاع للاستطلاع لإخطارات الطوارئ الآلية التالية: حرائق الغابات (خدمة حدود الحريق النشطة من USGS Geomac - كل 15 دقيقة) ، والفيضانات (مقياس النهر - الخدمة الحالية والتنبؤ من NOAA - كل 6 ساعات) ومواجهة الطقس القاسية (خدمة مخاطر الطقس من NOAA - كل 15 دقيقة).
في البداية ، قدم رئيس الوزراء لدينا رؤيته للنموذج الأولي وخريطة طريق عالية المستوى لاستكمال العمل. أنشأ الفريق الأدوار والمسؤوليات وكذلك اتفاقية الفريق التعاوني. عززنا وأنشأنا علاقات عمل فريقنا. باستخدام متطلبات خريطة الطريق والنموذج الأولي ، طور الفريق سلسلة أولية من قصص المستخدم. أعطى رئيس الوزراء أولويات هذه القصص إلى جانب UX/UI وقصص إعداد البنية التحتية التقنية لإنشاء تراكم منتجاتنا.
لقد سهل مصمم UX/UI الخاص بنا نهج تصميم مستخدم محرك المستخدم من خلال إشراك المستخدمين في وقت مبكر من خلال استخدام مقابلات الشخصية والمسوحات. لقد استفدنا من AngularJs جنبا إلى جنب مع المعايير والمكونات مجموعة من دليل نمط تصميم الويب الأمريكي (USWDS) لتنفيذ تطبيق ويب يمكن الوصول إليه الحديث. لقد اختبرنا أيضًا امتثال ADA 508 و WCAG 2.0. لقد استغلنا مستخدمين من مختلف الأعمار والأدوار والخبرات والخلفيات. خلال Sprint 1 ، قابلنا المستخدمين وسرعان ما تحولت نتائجنا إلى تدفقات سلكية تستفيد من تصميم مستجيب يستوعب كل من منصات سطح المكتب والهاتف. تم تنقيح هذه السلك بشكل مستمر بناءً على مدخلات المستخدم. وفرت إزاحة الأسلاك لدينا صورة مرئية لتوصيل مظهر ومظهر النموذج الأولي للمطورين. إلى جانب التصميم الأولي ، تم إشراك المستخدمين من خلال اختبار قابلية الاستخدام وتم تقييم مدخلاتهم وتحديد الأولويات من خلال قصص التحسين التي تمت إضافتها بعد ذلك في تراكم المنتج لإدراجها في العدوات اللاحقة.
تابعنا عملية رشيقة (الشكل 1) من دورات العدو الأسبوعية ، مع بدء كل دورة يوم الأربعاء وينتهي يوم الثلاثاء التالي.
الشكل 1 - عملية رشيقة لدينا 
كل أسبوع تضمنت طقوس Sprint: Stand-Up-من الاثنين إلى الجمعة @ 8:45-9:00 صباحًا التي يسهلها المدرب Agile. أبلغ أعضاء فريق التطوير عن الانتهاء من العمل منذ الجلسة الأخيرة ؛ العمل المخطط له قبل الجلسة التالية وأي حاصرات. تم مسح حاصرات تم تحديدها من قبل مدرب Agile ومدير التوصيل. قدم Stand-Up منتدى رائع للتنسيق في جميع أنحاء الفريق.
تراكم التربية - الاثنين ، راجع رئيس الوزراء لدينا وأعدت عناصر تراكم. دعم مدرب Agile ومدير التوصيل المراجعة وأكد قصص المستخدمين المتفق عليها مع "تعريف الفريق جاهز".
Sprint Review - صباح الثلاثاء ، قدم الفريق قصص المستخدم المكتملة في العدو إلى رئيس الوزراء للمراجعة والموافقة. تتماشى قصص المستخدم المعتمدة مع "تعريف الفريق الذي تم".
Sprint Retrospective - صباح الثلاثاء ، انعكس الفريق على كيفية أداء أدواتهم وعملياتهم وأقرانهم على Sprint الذي تم الانتهاء منه مؤخرًا. طُلب من كل عضو في الفريق تحديد سمة تحسين واحدة أرادوا رؤية الفريق يبدأ في القيام به ؛ أحدهم أرادوا أن يتوقف الفريق عن القيام به وأراد أن يستمر الفريق. تم تسهيلها من قبل المدرب Agile ، تم توحيد السمات المحددة/الإيقاف/المتابعة والخطوات التالية المحددة من قبل الفريق.
Print Planning - بعد ظهر يوم الثلاثاء ، جلسة ساعة واحدة لرئيس الوزراء والفريق ناقش بشكل تفاعلي ووافق على الحمولة العريضة المقبلة. تم تنسيق تغيير حجم العناصر في العدو من قبل مدرب Agile ومدير التوصيل. تم استخدام planitpoker.com لتقدير القصة.
شاهد ألبوم صور فريقنا للحصول على أمثلة مرئية للفريق وعملية رشيقة في العمل.
مع كل تكرار ، أصبح النموذج الأولي محاذاة بشكل متزايد مع رؤية رئيس الوزراء ، وكذلك احتياجات مستخدمينا. تضمنت خريطة طريق عالية المستوى العديد من قصص المستخدمين التي لم يتم تضمينها في نهاية المطاف في النموذج الأولي للعمل. وشملت هذه أبحاث Spike لتطبيق العميل الأصلي iOS ووظيفة إشعار الدفع الأصلي. على الرغم من أن كلاهما لم يكن في المنتج الدنيا القابل للتطبيق (MVP) ، إلا أنه يتم تضمينه في تراكم المنتجات ، والتحف المعمارية ورمز المصدر github.
طوال العملية ، تمكن الفريق من تنسيق العمل ومراقبة التقدم باستخدام لوحة Scrum الخاصة بنا. استخدمنا JIRA لتتبع قصص المستخدم على لوحة إلكترونية (وكذلك الأخطاء) ، وحافظنا على لوحة مادية في غرفة الفريق. استخدمنا التقاء لمشاركة المستندات و Hipchat كأداة تعاون فريقنا. تم تتبع المقاييس ، لذا فهم الفريق كيف كانوا يفعلون ومجالات محتملة لتحسين العملية مع كل سباق. أظهرت المقاييس الفريق سرعة التطوير ، والتراكم الفني ، وما هي النسبة المئوية من نقاط القصة التي تم تنفيذها بالفعل مع كل سباق.
بالنسبة لكل قرار تقني ، نظرنا في خيارات مفتوحة ، مما يؤدي إلى حصة مفتوحة في الغالب. كان هدفنا التكنولوجي هو تطبيق الويب الحديث القائم على المتصفح ، لكننا حققنا أيضًا في إمكانية وجود تطبيق محمول أصلي على iOS.
الشكل 2 - مكدس التكنولوجيا لدينا 
من وجهة نظر ديفوبس:
لقد اختبرنا ونشر النموذج الأولي على البنية التحتية ل Azure Microsoft كخدمة (IAAS). استخدمنا حل مراقبة Azure لمراقبة البنية التحتية المستمرة بما في ذلك الشبكات ، وآثار جديدة لمراقبة أداء التطبيق المستمر. استخدمنا بيانات مؤشرات الأداء الرئيسية (KPI) لضبط حل البنية التحتية والتطبيق.
استخدم حلنا github لتوثيق رمز واختبار الوحدة يرتكب في مستودع GitHub العام الخاص بنا. بنية github لدينا لها فروع رئيسية وتكامل وكذلك فروع الميزات. تم تطوير القصص الفردية في فرع ميزة في بيئة محلية. قبل التحقق من الرمز ، أصدر المطورون طلب سحب لإطلاق مراجعة رمز. بمجرد الموافقة على مراجعة التعليمات البرمجية ، تم دمج الكود في فرع التكامل ، مما يؤدي إلى عملية التكامل المستمر.
يعرض الشكل 3 طريقة عرض الأدوات وترحيل رمز المستوى العالي من التطوير إلى الإنتاج باستخدام عملية CI/CD الخاصة بنا.
الشكل 3 - التكامل والنشر المستمر (الأدوات) 
استعاد Jenkins الكود من Github ، وقامت ببناء التطبيق ، واختبارات الوحدة المنفذة. إذا مرت جميع اختبارات الوحدة ، أنشأ Docker صورة توزيع. لقد استخدمنا نهجًا مُشرئًا للقرص المضغوط في بيئة الاختبار الليلية لتجنب التدخل مع الاختبارات الوظيفية المستمرة. تم استيعاب عمليات النشر المخصصة حسب الحاجة. بمجرد نشر البناء للاختبار ، تم تشغيل مجموعة الاختبار الوظيفية (باستخدام السيلينيوم) تلقائيًا.
الشكل 4 - التكامل المستمر والنشر (عرض العملية) 
فيما يلي نظرة عامة على الخطوات التي اتبعناها في نهجنا:
أ. يقوم المطور بتعيين بيئة التطوير المحلية الخاصة به باستخدام ملفات Docker لتقليد بيئة العمليات وإنشاء فروع ميزات من Github Master Branch (الخطوة 0).
ب. يقوم المطور بإنشاء اختبارات الوحدة (الخطوة 1) ويكتب رمز المصدر المناسب (الخطوة 2) لتنفيذ قصة/ميزة المستخدم.
ج. لدمج اختبار الوحدة ورمز المصدر ، يقدم المطور طلب سحب ؛ مراجعة رمز المشغلات من قبل مطور النظراء ؛ المراجع يوافق/ يرفض الاندماج في فرع التكامل ؛ أخيرًا ، يحل المطور ملاحظات مراجعة الكود. بمجرد الموافقة على مراجعة الكود ، يتم دمج فرع الميزات في فرع التكامل (الخطوة 4).
د. يقوم المختبرين بإنشاء البرامج النصية الوظيفية الآلية (الخطوة 3) ، والتي يتم دمجها في فرع التكامل (الخطوة 4).
ه. على جدول محدد مسبقًا ، يقوم Jenkins بتجميع الكود المصدري ويتم تنفيذ جميع اختبارات الوحدة تلقائيًا (الخطوة 5).
و. إذا فشلت اختبارات الوحدة ، يتم إرسال إشعار بشأن الفشل ويقوم المطور بإصلاحه في فرع ميزة المراسل (الخطوة 15). تتكرر الخطوتين 4 و 5 حتى تمر اختبارات الوحدة.
ز. بمجرد مرور اختبارات الوحدة ، يقوم Jenkins بتنفيذ ملفات Docker لإنشاء صور Docker لواجهة المستخدم والواجهة الخلفية (الخطوة 6).
ح. يدفع Docker الصور إلى سجل Azure (الخطوة 7) ، ثم ينشرها إلى بيئة الاختبار حيث يتم تنفيذ الاختبارات الوظيفية تلقائيًا (الخطوة 8).
أنا. إذا فشلت الاختبارات الوظيفية ، يتم إرسال إشعار (الخطوة 14) ، ويصلح المطورون المشكلات (الخطوة 15). تتكرر الخطوات 4 و 5 و 6 و 7 و 8 حتى تمر الاختبارات الوظيفية.
ي. بمجرد نجاح الاختبارات الوظيفية ، يتم إرسال إشعار بخصوص تنفيذ الاختبار الناجح (الخطوة 9).
ك. QA يؤدي الاختبارات المخصصة/اليدوية. إذا فشلت هذه ، يتم إخطار المطور بإصلاح المشكلة (الخطوة 15). تتكرر الخطوات 4 و 5 و 6 و 7 و 8 و 9 و 10 حتى تمر الاختبارات المخصصة.
ل. بمجرد إصلاح الخطأ ، يتم دمج فرع التكامل مع علامة الإنتاج في الفرع الرئيسي (الخطوة 11).
م. أخيرًا ، يتم نشر الصورة التي تم إنشاؤها للاختبار في بيئة الإنتاج (الخطوة 12).
تم تنظيم رمز المصدر الخاص بنا لمتابعة بنيةنا الموزعة والبرنامج المستخدم لتنفيذه. يتم تخزين الواجهة الأمامية في المجلد الزاوي ، والداخلية الخلفية في مجلد Dropwizard. لدينا أيضًا مجلدات للاختبارات الوظيفية الآلية في مجلد السيلينيوم.
تم بناء واجهة المستخدم باستخدام AngularJs. داخل المجلد الزاوي ، يتضمن مجلد التطبيق مجلدات فرعية للصور واللغة وورائح الأنماط المتتالية والبرامج النصية والآراء. يحتوي مجلد البرامج النصية على وحدات التحكم والمصنع والخدمات. يستضيف مجلد Controllers بدوره ملفات JavaScript ، بينما يحتوي مجلد العرض على ملفات HTML. يتم الاحتفاظ باختبارات الوحدة بشكل منفصل عن الكود في مجلد الاختبار.
يتواصل الواجهة الأمامية مع الواجهة الخلفية باستخدام واجهات برمجة التطبيقات المريحة. يوجد رمز الواجهة الأمامية التي تستدعي الخدمات في المجلد الفرعي للخدمات تحت مجلد البرامج النصية.
يقوم الواجهة الخلفية للتطبيق بتنفيذ منطق العمل ، ويتواصل مع الخدمات الخارجية ، ويرسل الإخطارات ، والتفاعل مع قاعدة البيانات. يتم تنفيذ الواجهة الخلفية باستخدام Dropwizard ، والذي يوفر إطار عمل Java مع دعم الراحة و Junit. تقع منطق الأعمال ونقاط النهاية في مجلد الموارد ، وتنفيذ الخدمات في مجلد الخدمة.
يقوم التطبيق أيضًا بتنفيذ أغلفة API الخارجية (المنفذة هنا) لاسترداد البيانات من مصادر البيانات الخارجية.
اختبارات الوحدة الموجودة في مجلد الاختبار.
يتواصل التطبيق مع قاعدة البيانات العلائقية (MySQL) باستخدام السبات. نحن نستخدم عمليات التحقق من صحة Bean القياسية للتحقق من صحة البيانات. توجد كائنات الوصول إلى البيانات وكائنات النموذج في مجلد DAO.
أ. تم تعيينه (1) زعيم وأعطى سلطة ومسؤولية ذلك الشخص ومسؤولية هذا الشخص عن جودة النموذج الأولي المقدم
أثناء تقييم RFI ، اختار CGI مدير منتج (PM) استنادًا إلى خبرته الفنية والإدارية. أعطى CGI هيئة اتخاذ القرار النهائية PM في تصميم وتطوير النموذج الأولي.
ب. تم تجميع فريق متعدد التخصصات وتعاوني يتضمن ، على الأقل ، خمسة (5) من فئات العمل كما هو محدد في المرفق B: PQVP DS-AD أوصاف العمل
تحت قيادة رئيس الوزراء ، قامت CGI بتجميع فريق متعدد التخصصات مع قدرات تقنية ورشيقة مختلفة.
فريقنا:
ج. فهم ما يحتاجه الناس ، من خلال تضمين الأشخاص في عملية تطوير النموذج الأولي وتصميمه ؛
اتبع CGI نهجًا يركز على المستخدم لتصميم وتطوير النموذج الأولي لدينا. شارك مصمم UX/UI الخاص بنا في وقت مبكر من خلال استخدام المقابلات والاستطلاعات الشخصية. تم تحويل نتائج المقابلة بسرعة إلى تدفقات سلكية. تم تنقيح تدفقات الأسلاك بناءً على استطلاعات المستخدم وكذلك اختبار قابلية الاستخدام مع مستخدمينا. وفرت السلكية طريقة سريعة ومرئية للتواصل للمطورين مظهر النموذج الأولي المطلوب والشعور حتى يمكن أن يبدأ التنمية بمجرد أن وافق رئيس الوزراء على القصص الأولية.
قمنا بتطبيق تقنيات وأدوات التصميم بما في ذلك مقابلات الشخصية ، وتطوير تدفق الأسلاك ، واختبار قابلية الاستخدام ، و UX Lean لتطوير واجهة المستخدم الخاصة بنا. لدعم واجهة مستجيبة قائمة على المتصفح ، قمنا بالاستفادة من الإرشادات من تصميم الويب الأمريكي (USWD) لمعايير الويب الحديثة و AngularJs. تطبيق هذه المعايير ، جنبا إلى جنب مع مدخلات من المستخدمين ، سمح لنا ببناء نموذج أولي كان بسيطا وبديهية للتنقل والاستخدام. لقد اختبرنا أيضًا امتثال ADA 508 و WCAG 2.0 ، باستخدام الأدوات الآلية لاختبار دعم القارئ التكيفي وخيارات الرؤية المنخفضة الأخرى.
د. تستخدم ما لا يقل عن ثلاثة (3) تقنيات و/أو أدوات "التصميم المتمحور حول المستخدم" ؛
استخدمنا مقابلات Personas ، واختبارات الأسلاك ، واختبارات قابلية الاستخدام كأدواتنا الرئيسية لتطوير تصميم لنموذجنا الأولي الذي يركز على احتياجات ومستخدمينا.
ه. يستخدم github إلى ارتباط رمز الوثيقة ؛
يمكن عرض الالتزامات في Github: https://github.com/cgi- zahid/cgi-poc
و. يستخدم Swagger لتوثيق واجهة برمجة تطبيقات Restful ، وقدم رابطًا إلى واجهة برمجة تطبيقات Swagger ؛
تم إجراء جميع التواصل مع الطبقة الوسطى باستخدام REST API. تعرض الطبقة الوسطى واجهة برمجة تطبيقات REST باستخدام Jax RX وتم توثيقها في Swagger.
ز. الامتثال للمادة 508 من قانون الأميركيين ذوي الإعاقة و WCAG 2.0 ؛
كجزء من اختبار قابلية الاستخدام ، قمنا باختبار امتثال 508 و WCAG 2.0. استخدمنا الاختبار الآلي لاختبار قابلية القراءة والرؤية المنخفضة. لقد تناولنا الأخطاء كجزء من عملية تراكمنا. تم تقييم نتائج الاختبارات الأخرى لتحديد أي لإضافة إلى تراكم وتلك التي لا تنطبق على النموذج الأولي لدينا.
استخدمنا Actf adesigner للاختبار لدينا 508.
ح. تم إنشاء أو استخدام دليل نمط التصميم و/أو مكتبة نمط ؛
أنشأت UX/UI دليل نمط باستخدام معايير تصميم الويب الأمريكية. تم اختيار نظام الألوان الخاص بنا بناءً على ألوان ولاية كاليفورنيا وتمت الموافقة عليها من خلال ملاحظات المستخدم. سمح لنا تطبيق معايير تصميم الويب الأمريكية جنبًا إلى جنب مع المدخلات من المستخدمين ببناء نموذج أولي كان بسيطًا وبديهية للتنقل والاستخدام.
أنا. أجرى اختبارات قابلية الاستخدام مع الناس ؛
كجزء من نهجنا المركزي للمستخدم ، قمنا بدمج اختبار قابلية الاستخدام في عمليتنا. تم إجراء اختبار قابلية الاستخدام من خلال استطلاعات المستخدم على إطاراتنا السلكية بالإضافة إلى ردود الفعل من المستخدمين الذين اختبروا النموذج الأولي لدينا طوال سباقنا. تم تقييم ردود الفعل من اختبارات قابلية الاستخدام بواسطة PM و UX Designer لتحديد ما يجب تضمينه في التراكم. استنادًا إلى PM Direction ، تم إنشاء قصص جديدة وتحديد الأولوية ووضعها في تراكمنا.
ي. استخدم نهجًا تكراريًا ، حيث أبلغت التغذية المرتدة العمل اللاحق أو إصدارات النموذج الأولي ؛
داخل كل سباق ، تم تقييم المدخلات المستلمة من مدير المنتج ، ومختبرات قابلية الاستخدام ، والعيوب المحددة أثناء الاختبار ، وتحديد الأولوية ، وإدماجها في التراكم كجزء من نهجنا التكراري. مع كل عرض تجريبي ، أصبح النموذج الأولي أكثر وأكثر توافقًا مع رؤية رئيس الوزراء وكذلك احتياجات مستخدمينا.
ك. إنشاء نموذج أولي يعمل على أجهزة متعددة ، ويعرض تصميمًا مستجيبًا ؛
تم اختبار الكود الخاص بنا باستخدام أجهزة متعددة ويعمل مع متصفحات ويب متعددة. بالإضافة إلى ذلك ، تم اختبار التعليمات البرمجية الخاصة بنا باستخدام أجهزة Apple و Android.
اختبرنا على:
ل. تستخدم ما لا يقل عن خمس (5) تقنيات حديثة ومفتوحة المصدر ، بغض النظر عن الطبقة المعمارية (الواجهة الأمامية ، الخلفية ، إلخ) ؛
استخدمنا التقنيات الستة (6) الحديثة والمفتوحة:
يتم توفير قائمة بجميع تقنياتنا: قائمة التكنولوجيا. الصفوف التي تم تسليط الضوء عليها باللون الأخضر على جدول البيانات هي تقنيات المصدر الحديثة.
م. نشر النموذج الأولي على البنية التحتية كخدمة (IAAS) أو منصة كخدمة (PAAS) ، وأشار إلى المزود الذي استخدموه ؛
استخدمنا Azure كمزود IAAS لدينا.
ن. تم تطوير اختبارات الوحدة الآلية للرمز ؛
قبل فحص التعليمات البرمجية في مفاتيح فروع الميزات ، يقوم مطورو السحب بإجراء مراجعة رمز. بمجرد الموافقة على مراجعة التعليمات البرمجية ، يتم دمج الرمز في فرع التكامل الذي يؤدي إلى عملية النشر المستمرة.
س. قم بإعداد أو استخدام نظام تكامل مستمر لأتمتة إجراء الاختبارات ونشر رمزها بشكل مستمر إلى مزود IAAS أو PAAS ؛
استخدمنا جنكينز للتكامل المستمر. يمسك رمز من github وتجميع وتنفيذ الاختبارات. إذا اجتاز الرمز الاختبارات ، فإن Docker ينشئ صورة. يتم نشر الصورة في بيئة اختبار النظام حيث يتم إجراء اختبار وظيفي نهاية إلى النهاية باستخدام السيلينيوم.
ص. إعداد أو إدارة التكوين المستخدمة ؛
تم استخدام سجلات حاوية Azure لتخزين وإدارة صور Docker الخاصة بنا مما يسمح لنا بإدارة التكوين
س. إعداد أو استخدام مراقبة مستمرة ؛
تم استخدام Azure و New Relic لمراقبة صحة البيئة والتطبيق باستمرار
ص. نشر برامجهم في حاوية مفتوحة المصدر ، مثل Docker (أي ، تستخدم المحاكاة الافتراضية على مستوى النظام) ؛
لقد نشرنا برنامجنا باستخدام Docker
ق. قدمت وثائق كافية لتثبيت وتشغيل النموذج الأولي على جهاز آخر ؛
فيما يلي رابط لتعليمات التثبيت الخاصة بنا.
تعليمات
ر. النموذج الأولي والمنصات الأساسية المستخدمة لإنشاء وتشغيل النموذج الأولي مرخصة بشكل علني ومجاني.
استخدمنا منصات مرخصة ومرخصة مجانًا
قائمة الأدوات
تبعت عملية تصميم وتطوير النموذج الأولي الخاص بنا والتقى بالعديد من المعايير الموضحة في كتاب Playbook للخدمات الرقمية الأمريكية. قدمنا وثيقة مفصلة عن Github والتي ترتبط بأدلةنا ، وكذلك ردنا على كل عنصر.
ردود كتاب خدمة الخدمة الرقمية لدينا في الولايات المتحدة
