كيف نعمل
كيف نخطّط للبرمجيات ونطوّرهاونثبت أنها تعمل قبل إطلاقها.
يبدأ كل مشروع بخطة مكتوبة تعتمدونها، وينتهي باختبارات توقّعون على اعتمادها.
قبل كتابة أي سطر برمجي، نتّفق على ما يجب أن تفعله البرمجيات وكيف سنعرف أنها اكتملت. وهذه الخطة لكم لتعتمدوها وتحتفظوا بها.
ومن ثمّ ترون نسخة عاملة في كل مرحلة، وتعتمدون النتيجة وفق المعايير التي اتّفقنا عليها، فلا ينحرف شيء ولا تُفاجَؤون بشيء عند الإطلاق.
ما نحسمه قبل كتابة أي شيفرة
نبدأ من الطريقة التي تعمل بها مؤسّستكم فعلاً، لا من أداة. وقبل أن نقدّر التكلفة أو نبدأ التطوير، نحدّد بوضوح ما يلي:
(النطاق ومعايير النجاح)
ما يجب أن تفعله البرمجيات، وكيف سنعرف معاً أنها اكتملت.
(صلاحيات القرار)
من يعتمد ماذا، حتى لا يتوقّف المشروع في منتصفه بانتظار الموافقات.
(واقع سير العمل)
كيف يسير العمل اليوم فعلاً، بما في ذلك الخطوات التي تُنجز خارج الأنظمة.
(التكامل والبيانات)
الأنظمة التي يجب أن يتكامل معها النظام، والبيانات التي يجب أن يثق بها.
(القيود والمخاطر)
الميزانية والمواعيد النهائية والامتثال، وأين يكون ثمن الافتراض الخاطئ أفدح.
كيف نخطّط للتطوير
تقديراتنا ليست تخمينات. نتحقّق من كل خطة بالأدلة ونختبر متانتها قبل كتابة أي سطر برمجي، فيصمد ما نتّفق عليه أثناء التنفيذ.
هندسة المتطلبات
نكتب ما يجب أن تفعله البرمجيات بالضبط في وثيقتي BRD و SDD تعتمدونهما، مع وثيقة SRS مستندة إلى معيار ISO/IEC/IEEE 29148.
التصميم قبل الشيفرة
نتّفق على طريقة عمل النظام وشكله عبر نماذج أوّلية، قبل تخصيص أي وقت هندسي لتطويره.
مراجعة البنية والتكامل
نرسم خريطة الأنظمة والبيانات والحالات الاستثنائية التي يقوم عليها المشروع، فلا يفاجئنا شيء في مرحلة متأخّرة.
اختبار متانة التقديرات
نختبر النطاق والتكلفة والجدول الزمني في ضوء القيود الفعلية، لا في ضوء أفضل الاحتمالات.
لماذا يسبق التخطيط الشيفرة
يضاعف التنفيذ أثر كل ما يقوم عليه، فالنطاق الغامض يعجّل بالارتباك، والافتراض الخاطئ يعجّل بإعادة العمل. والتخطيط أولاً هو ما يجعل نتائج التنفيذ متوقّعة.
نطاق يبقى ثابتاً
تكلفة تبقى متوقّعة
برمجيات يمكنكم امتلاكها
الأسئلة الشائعة
ما المقصود بوثيقتي BRD و SDD؟
هل نرى العمل قبل اكتماله؟
ما اختبار قبول المستخدم (UAT)؟
ما المعايير التي تتبعونها؟
(الخطوة التالية)