نتاج التعلم ب: تصميم حل برمجي لتلبية متطلبات العميل

اختم تحليلك: أثر التفكير الحسابي

الحل الجيد هو الذي يلبي طلب العميل

النقطة الأساسية لأي حل برمجي هي أنه يلبي متطلبات العميل.

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

دورة حياة البرمجيات: مراحل تدور

• عملية دورية: تصميم حل برمجي عملية دورية ذات مراحل محددة بوضوح.
• الأسماء: رغم تعدد إصدارات دورة الحياة وتغير الأسماء، فمعظم المراحل شائعة وتتبع الترتيب المنطقي نفسه.

ماذا يتضمن جدول التتبع لكل حالة استخدام؟

افهم المتطلبات ثم اكتب المواصفات

• المرحلة 1: تقييم المتطلبات: يجب أن تفهم تمامًا متطلبات العميل، وإلا صعب أو استحال إنشاء حل عملي.
• المصدر: تُستخلص المتطلبات عادةً من موجز العميل، وعند نقص التفاصيل يجب عليك التحقيق.

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

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

ما عناصر مواصفات التصميم الكاملة؟

• المدخلات: القيم التي تُدخل في البرنامج وكيف تُدخل (يدويًا أو تلقائيًا من قاعدة بيانات).
• المخرجات: المعلومات التي ينشئها البرنامج، مع تفاصيل تنسيقها وتخطيطها.
• واجهة المستخدم: الطريقة التي يتفاعل بها المستخدم مع البرنامج، مثل أنظمة القوائم ولوحة المفاتيح والفأرة والتحكم الصوتي وأنظمة الألوان والتخطيط.
• العمليات والخوارزميات: العمليات الحسابية لتوليد المخرجات من البيانات المدخلة، والتحقق من صحة البيانات.
• الجدول الزمني: الوقت الذي ستستغرقه العملية والأهداف خلال مدة المشروع، مع "المعالم" المتفق عليها، وهي نقاط محددة مسبقًا يثبت بها المطور مدى التقدم.

الكود والتنفيذ والاختبار

• المرحلة 3: تطوير الكود: يُكتب كود البرنامج بلغتك المختارة، وقد يحتاج العميل أحيانًا إلى لغة معينة، ويعتمد الاختيار على مواصفات التصميم والمتطلبات.
• ما يحتاجه المطور: المدخلات والمخرجات والخوارزميات وواجهة المستخدم الموثقة، ثم استخدام اللغة المختارة بأكبر قدر ممكن من الكفاءة.
• نقاط القصة: في البيئة التجارية تُقسم أجزاء البرنامج إلى ساعات عمل، وتعادل ساعة واحدة عادةً نقطة قصة واحدة، فالميزات الأكثر تعقيدًا تعادل مزيدًا منها.
• نسبة 40/60: يقضي المطورون 60 في المائة من وقتهم في كتابة الكود و40 في المائة في التخطيط وتصحيح الأخطاء والاختبار.

• المرحلة 4: التنفيذ: اختيار لغة البرمجة الأكثر ملاءمة إذا لم يكن العميل قد اختارها.
• بيئة التطوير: أداة (أدوات) البرنامج المستخدمة لبناء البرنامج ونظام التشغيل وأحيانًا نوع الأجهزة.
• الكتابة والتصحيح: كتابة أكواد الحل من مواصفات التصميم، وتصحيحها لإزالة الأخطاء البسيطة قبل بدء الاختبار الرسمي.

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

من يجري اختبار الصندوق الأبيض ومن يجري الأسود؟

الصيانة لا تنتهي

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

وثيقة التصميم: قبل أن تكتب سطرًا

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

جملة تعريف المشكلة: خمسة أسئلة

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

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

ما الأسئلة الخمسة لجملة تعريف المشكلة؟

ميزات الحل: مهام وبيانات ومدخلات ومخرجات

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

• النتيجة: حدد المطور جميع المدخلات والمخرجات وصيغها، خاصة عدد الأماكن العشرية، وضمّن تفاصيل أي تحقق مطلوب.

ثلاثة مخططات تصف تجربة المستخدم

• الرسوم التخطيطية: سيحتوي التصميم على عدد من المخططات، وهناك ثلاثة أنواع شائعة تركز على جوانب من تجربة المستخدم ⁦(UX)⁩.
• تخطيطات الشاشة: توضح كيفية تنظيم العناصر على "الصفحة" الافتراضية.
• واجهات المستخدم: توضح كيفية تفاعل المستخدم مع التطبيق.
• عناصر التنقل: توضح كيف سينتقل المستخدم بين "الصفحات" الافتراضية المختلفة.
• الإنشاء: يمكن رسمها على الورق أو إنشاؤها إلكترونيًا باستخدام أدوات تصميم متخصصة متاحة عبر الإنترنت.

الخوارزمية: كيف تشرحها للآخرين؟

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

ما أدوات تمثيل الخوارزمية الأكثر شيوعًا؟

• الكود الزائف: مخطط غير رسمي للخوارزمية، يُعبر عنه بلغة طبيعية، ويمكن تحويله إلى لغة البرمجة المستهدفة.
• شرطه: يجب ألا يحتوي على أي أوامر أو بناء جملة للغات البرمجة.
• مثال: عملية تحقق بسيطة من عمر مستخدم يتراوح بين 18 و60.

• المخطط الانسيابي: تمثيل بياني للخوارزمية، يوضح إجراءاتها ومنطقها من خلال مجموعة من الرموز الموحدة.

• مخططات الأحداث: تسجل الأحداث في جدول بسيط، ولكل حدث تتضمن اسم الحاوية (مثل ⁦Form1⁩) واسم الكائن المستجيب (مثل ⁦Button1⁩).
• وتتضمن أيضًا: الحدث الذي يتم الرد عليه (مثل النقر) ومعالج الحدث الذي يتم تشغيله (مثل ⁦button1Action()⁩).
• فائدتها: تعمل كقائمة تحقق مفيدة عند بناء مكونات واجهة المستخدم الرسومية للتطبيق.

هياكل البيانات وتخزينها

• هياكل البيانات: يجب أن يوضح أي حل برمجي الهياكل التي تُستخدم كجزء من الخوارزمية، وهي تختلف عن تخزين البيانات في الذاكرة في أثناء التنفيذ.
• الشائعة: المصفوفات (أحادية البعد، ثنائية البعد، ثلاثية البعد)، والطوابير، والمكدسات، والسجلات.
• الذاكرة المتطايرة: تخزين البيانات في ذاكرة الوصول العشوائي ⁦(RAM)⁩ "متقلب" أو غير مستقر لأنه يُفقد عند فصل الطاقة.
• غير المتطاير: تحتاج إلى تخزين أكثر ديمومة لتبقى البيانات بين استخدامات البرنامج، كالتخزين المغناطيسي مثل القرص الصلب أو محرك فلاش ⁦USB⁩.
• ملف البيانات: أكثر أشكال التخزين غير المتطاير شيوعًا، وتدعمه معظم اللغات، لكنه لا يخزن البرنامج نفسه.

• الصيغ الشائعة لملفات البيانات: الرمز القياسي الأمريكي لتبادل المعلومات ⁦(ASCII)⁩ أو النص.
• ثنائي: تُخزن الأرقام كقيمة ثنائية نقية وليس بوصفها أكواد رموز ⁦ASCII⁩ فردية.
• csv: قيمة مفصولة بفاصلة.
• XML: لغة الترميز القابلة للتوسع.

• ملاحظات ⁦XML⁩: تبدأ وثيقة ⁦XML⁩ بعلامة ⁦XML⁩ توضح إصدارها.
• كل عميل: يتم 'حظره' أو فصله عن الآخرين باستخدام زوج من علامات البدء والنهاية للعميل.
• كل جزء من البيانات: يوضع في زوج من العلامات الافتتاحية والختامية التي تصف السمة، على سبيل المثال ⁦CustomerAcc⁩.

• الاختيار: غالبًا ما يتأثر اختيار الصيغة باستخدامها؛ فإذا استورد ملف إلى جدول بيانات مثل ⁦Microsoft Excel⁩، فإن ⁦CSV⁩ خيار شائع.
• الأغراض: تخزين سجلات المستخدمين، أو معلومات تكوين البرنامج، أو تفاصيل ترخيصه.
• الحلول المعقدة: قد تتطلب ملفات بيانات عديدة، وقد يكون الأنسب استخدام قاعدة بيانات علاقاتية بدلاً من الملفات عند الحاجة إلى علاقات بيانات معقدة.

• أسئلة التصميم: ما متطلبات تخزين البيانات؟ ماذا تسمى الملفات؟ كيف سيتم الوصول إلى البيانات (القراءة أو الكتابة أو الإلحاق)؟
• ثم: كيف تُحدّث البيانات أو تُحذف؟ ما تنسيق الملف (⁦ASCII⁩ أو ⁦CSV⁩ أو ⁦XML⁩)؟ أين يجب تخزين الملف (اسم الوسائط والمجلد)؟

هياكل التحكم في الحل

• هياكل التحكم: تشمل التسلسلات والاختيارات والتكرارات.
• في المثال: تحتوي خوارزمية التحقق الموضحة في الشكلين 4.29 و4.30 على جميع هياكل التحكم الثلاثة.
• المطلوب: أن يظهر الحل بوضوح نطاق هياكل التحكم المختارة وكيفية استخدامها لحل المشكلات المعقدة، والمخططات الانسيابية والكود الزائف تقنيتان جيدتان لذلك.

التحقق: جودة المخرجات من جودة المدخلات

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

• الهدف: بناء قواعد التحقق للتحقق مما إذا كانت المدخلات منطقية، وتمنع النتائج غير الدقيقة، أي أخطاء وقت التشغيل أو تعطل التطبيق القاتل.
• الأنواع: هناك عدة أنواع مختلفة من التحقق.

فحص النطاق وفحص الطول

• فحص النطاق: يُقيم ما إذا كانت البيانات المدخلة ضمن نطاق الحد الأدنى إلى الحد الأقصى الصالح.
• مثال: إذا قُيّد العميل بشراء ما يصل إلى عشرة من عنصر، فالنطاق الصالح من 0 إلى 10، وخارجه غير صالح.
• الصفر: إدخال 0 يعني أن العميل لا يشتري أي عدد، لكنه ما زال إدخالًا صالحًا منطقيًا وسيمر عبر التحقق.
• ليست أرقامًا فقط: يمكن أن تمثل الرموز '⁦A'⁩ إلى '⁦F'⁩ نطاقًا صالحًا أيضًا.

• فحص الطول: يُقيم عدد الرموز التي تم إدخالها، وبعض المدخلات لها أطوال محدودة.
• أمثلة: يتم تقييد رسائل خدمة الرسائل القصيرة ⁦(SMS)⁩ إلى 160 رمز، وتم تحديد التغريدات في الأصل بعدد 140 رمز.

الوجود والنوع والتنسيق

• فحص الوجود: يُقيم ما إذا كانت البيانات موجودة.
• مثال: يجب على المستخدم إدخال 'ذكر' أو 'أنثى' في نموذج تسجيل، ويضمن التحقق ألا يترك الإدخال فارغًا أو غير محدد.
• فحص النوع: يُقيم ما إذا كانت البيانات المدخلة من النوع الصحيح؛ فعمر المستخدم يجب أن يكون عددًا صحيحًا (رقمًا كاملاً).
• الخطر: إذا لم يمنع المبرمج إدخال أنواع غير صحيحة، فقد يتسبب ذلك في حدوث خطأ قاتل في أثناء وقت التشغيل.

• العمر أ: (نوع البيانات هو رمز، هذا غير صالح)
• العمر 16: (نوع البيانات هو عدد صحيح، هذا صالح)
• العمر 16/09/01: (نوع البيانات هو تاريخ، هذا غير صالح)

• فحص التنسيق: يُقيم ما إذا كانت البيانات المدخلة في التنسيق الصحيح، مثل رمز المنطقة البريدية في المملكة المتحدة '⁦PO1 3AX'⁩.
• PO: هو المنطقة، مثل ⁦GL (⁩غلوستر)، ويجب أن تكون هذه الرموز أحرفًا إنجليزية كبيرة، أحرفًا أبجدية، رمزًا أو رمزين.
• 1: الحي، عادة بين 1 و20 لكل منطقة؛ يصل إلى رقمين.
• 3: القطاع، ويغطي عادة ما يصل إلى 3000 عنوان؛ رقم واحد.
• AX: الوحدة، وتغطي عادة ما يصل إلى 15 عنوانًا؛ حرفان إنجليزيان كبيران.

• الرمز البريدي؟ ⁦GL2 4TH⁩: (الرمز البريدي صالح)
• الرمز البريدي؟ ⁦W1A 1AA⁩: (الرمز البريدي صالح)
• الرمز البريدي؟ ⁦GL2 4TH⁩: (الرمز البريدي غير صالح؛ يمكن أن يكون القطاع رقمًا واحدًا فقط)

خطأ مطبعي في الكتاب: يطبع الكتاب الرمز نفسه في صف صالحًا وفي صف آخر غير صالح، وقد أُبقي كما طُبع.

• الأردن: الرموز البريدية من 5 أرقام، ووسط عمان 11110؛ فالتحقق يتأكد أن الرمز خمسة أرقام ويبدأ بالرقم 1.
• باكستان: خمسة أرقام والأول بين 1 و9؛ وأي رمز يبدأ بالرقم 0 غير صحيح حتى لو كان من 5 أرقام.

رقم التحقق: اكتشاف الخطأ في الرمز

• رقم التحقق: رمز واحد (عادةً رقم) مشتق من خوارزمية تُنفذ على جزء من البيانات.
• كيف يعمل: تنشئ الخوارزمية الرقم فقط إذا كانت الرموز بالضبط وبهذا الترتيب؛ فأي رمز غير صحيح أو تبديل مواضع ينتج قيمة مختلفة ويفشل الاختبار.
• الاستخدام: لاكتشاف الأخطاء في القيم المدخلة مثل الباركود وأرقام الحسابات المصرفية وأكواد تسجيل البرامج.
• ISBN: رقم الكتاب الدولي المعياري ذو العشرة أرقام ⁦(ISBN-10)⁩ يستخدم رقم تحقق، وهو الرقم الأخير.
• بعد 2007: انتقلت الكتب إلى رقم ⁦ISBN⁩ من 13 رقمًا، وآخر رقم فيه هو أيضًا رقم التحقق.

ما الذي يكتشفه رقم التحقق؟

• فحص الإملاء: يقيّم ما إذا كانت الكلمات المدخلة يمكن العثور عليها في قاموس إلكتروني، أي أنها كلمات صالحة.

معالجة الأخطاء: لا تدع البرنامج ينهار

• الميزات: كثير من اللغات الحديثة فيها ميزات بناء جملة للتعامل مع أخطاء وقت التشغيل، وبدونها يتعطل التطبيق أو يتجمد دون استجابة.
• الأسلوب الشائع: تعبير "⁦try... throw... catch⁩" في لغات مثل ⁦C++⁩ و⁦C⁩# و⁦Java⁩ و⁦Oracle⁩ و⁦PHP⁩.
• كيف يعمل: بمحاولة تنفيذ عملية، والتقاط أي أخطاء محتملة، و(اختياريًا) إلقاء استثناء مناسب، فلا تفشل العملية بطريقة غير محكومة.
• المثال: وضع القسمة داخل كتلة المحاولة تحسبًا لإدخال المستخدم '0' كرقم ثانٍ، لأن القسمة على صفر قد تعطل وقت التشغيل.

• الاستثناء: باستخدام كتلة "⁦try... catch⁩"، يمكنك تجنب ذلك من خلال عرض الاستثناء الذي تم اكتشافه، والذي يعد في هذه الحالة خطأ "⁦DividebyZero⁩".
• الإبلاغ عن الأخطاء: قد يوجه إلى المستخدم ليعرف أنه أخطأ، أو إلى المطور ليفهم أين واجه البرنامج خطأً وطبيعته.
• التقنيات: عرض رسالة خطأ على الشاشة و/أو رمز خطأ، وإلحاق تفاصيل الخطأ بملف سجل إلكتروني، وإرسال بريد إلكتروني إلى المطور بتفاصيله.

لغة البرمجة: أي لغة تناسب المشروع؟

• العوامل: هناك عدد من العوامل المختلفة التي تؤثر في اختيار لغة البرمجة لمشروع تطوير البرمجيات.
• تفضيل العميل: قد يعبر عميلك عن تفضيله للغة برمجة معينة.
• الملاءمة: قد تكون لغات مختلفة أكثر ملاءمة بحسب الطبيعة التقنية للمهمة.

• التجارة الإلكترونية: عادةً ⁦PHP⁩ أو تقنيات ⁦ASP.NET⁩ من ⁦Microsoft⁩، لأنها لغات برمجة نصية من جانب الخادم تمكّن من التطوير السريع لهذا النوع.
• ألعاب الفيديو: ⁦C⁩# من ⁦Microsoft⁩ لإطار عمل .⁦NET⁩ الواسع و⁦XNA⁩ الذي يمكّن من تطوير ألعاب لنظام ⁦Windows⁩ و⁦Xbox⁩ وهواتف ⁦Windows⁩ المحمولة.
• الأجهزة الإلكترونية: لغة ⁦C⁩، لأنها تصل إلى الأجهزة على مستوى 'الهيكل المادي' ⁦(bare metal)⁩ وتراقب الإشارات الإلكترونية بسهولة في الوقت الفعلي.
• مثال: ⁦C⁩ خيار شائع للتحكم في تفاعل ⁦Raspberry Pi⁩ أو ⁦Arduino⁩ مع الأجهزة الخارجية.

لغة تنتقل وتُصان وتتوسع

• قابلية النقل: بعض اللغات أكثر قابلية للنقل، أي يمكن ترجمة الكود المكتوب ليُستخدم على وحدات معالجة مركزية مختلفة.
• لغة ⁦C⁩: ناضجة ولها برامج تحويل لا تحصى، فيمكن لبرنامج تحويل ⁦C⁩ على ⁦Microsoft Windows (⁩معالج ⁦X86_64⁩) إنشاء كود آلة لجهاز ⁦Android (⁩وحدة المعالجة المركزية ⁦ARM⁩).
• Java: يُترجم كودها إلى كود بايت "مستقل بنائيًا" عن المعالج، فيعمل في الآلات الافتراضية للغة جافا ⁦(JVM)⁩ الموجودة على أجهزة من الهواتف المحمولة إلى أجهزة التلفاز.

• قابلية الصيانة: الصيانة من المراحل المتأخرة لكنها تؤثر في اختيار اللغة؛ فمن غير المحتمل ألا تحتاج الحلول إلى صيانة، وأسبابها الشائعة الأخطاء وتغير احتياجات العميل أو المستخدم.
• الممارسات: تشجع اللغة المستهدفة على ممارسات جيدة مثل القابلية للقراءة والتوسع، فيسهل الكود الصيانة، خاصة إن كان من يصونه غير المطور الأصلي.
• التوسع: قدرة الحل على النمو (أو التوسيع) مع تغير احتياجات العميل أو المستخدمين بمرور الوقت.
• كائنية التوجه: البرمجة كائنية التوجه ⁦(OOP)⁩ قابلة للتوسع بشكل خاص لأن طبيعتها القائمة على الفئات تعكس المواقف والعمليات والبيانات في العالم الحقيقي، ولذلك تحظى لغات مثل ⁦C++⁩ و⁦C⁩# بشعبية.

خبرة الفريق والوقت والدعم والتكلفة

• الخبرة: ترتبط القدرة التقنية للمطور بمعرفته بلغة معينة، فاختيار اللغة يفيد من الخبرة المتاحة داخل الشركة.
• التطوير المهني: غالبًا يُرسل المطورون إلى برامج دراسية كجزء من تطويرهم المهني المستمر ⁦(CPD)⁩، وتدفع الشركات لمطوري العقود للحصول على خبرة التقنيات الجديدة.
• الوقت: يعتمد على تعقيد المشكلة واختيار اللغة والأدوات؛ ومعظم بيئات التطوير الحديثة مصممة لتحسين سرعة المبرمج لأن تحسين الإنتاجية مهم لخفض التكاليف.

• التطوير السريع للتطبيقات ⁦(RAD)⁩: نهج يمكّن المبرمجين من إنتاج الكود بسرعة بلغات تسمح بإنشاء نماذج أولية للتطبيق بسرعة.
• التعديل: تعدّل النماذج الأولية بعملية تكرارية لاختبار العميل والمراجعة، ويقلل ذلك وقت التخطيط.
• الأدوات: يعتمد ⁦RAD⁩ على مقتطفات الكود القابلة لإعادة الاستخدام وواجهة مستخدم بالسحب والإفلات، مثل ⁦Visual Basic .NET⁩ من ⁦Microsoft⁩.

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

ما عوامل التكلفة المرتبطة بلغة البرمجة؟

كود الطرف الثالث: وفّر الوقت بحذر

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

الأصول الرقمية: اسردها كلها

• الأصول الرقمية: قد تشمل الرسوم (⁦PNG⁩ أو ⁦BMP⁩ أو ⁦JPEG⁩) والرسوم المتحركة (⁦HTML5⁩ و⁦Adobe Flash SWF⁩ وملفات ⁦GIF⁩ المتحركة).
• الصوت والفيديو: الصوت (⁦MP3⁩ و⁦WAV⁩) والفيديو (⁦MP4⁩ و⁦AVI⁩).
• الخطوط: أنواع الخط والخطوط مثل ⁦Arial⁩ و⁦Times New Roman⁩ و⁦Verdana⁩.
• في التصميم: يجب تضمين الأصول المستخدمة من قبل المطور في تصميم حلول البرمجيات كمورد رئيس، ويتم تجميعها بحسب الفئة.
• التفاصيل: يتم سرد أسماء الملفات (والمسارات) وتنسيقات الملف وأحجام الملفات لكل أصل.
• التفاصيل الأخرى: الأبعاد/الدقة بالبكسل للرسوم، والمدة للصوت والفيديو، والإطارات والإطارات في الثانية للرسوم المتحركة والفيديو.
• وأيضًا: ملاحظات حول الغرض/الاستخدام في البرنامج، وأي معلومات ترخيص مطلوبة، مثل حقوق الطبع والنشر.

الملاحظات وخطة الاختبار جزء من التصميم

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

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

ما الحالات الثلاث لبيانات الاختبار؟

• القيود التقنية والتصميمية: قد تحدّ مهارتك في حل المشكلات، ويجب أن تنعكس في التصميم.
• الاتصال: ما الأجهزة أو اتصالات الشبكة المطلوبة لتطبيقك؟ مهم خاصة عند الحاجة إلى أجهزة خاصة أو اتصال شبكة نشط.
• تخزين الذاكرة: هل هناك متطلبات ذاكرة الوصول العشوائي ⁦(RAM)⁩ التي يجب ألا تتجاوزها البصمة الرقمية لبرنامجك؟
• لغات البرمجة: هل اختار العميل لغة البرمجة مسبقًا؟ قد يحدث هذا إذا كان لديه خبرة مع تطبيقات بلغات معينة.