ما هي هندسة البرمجيات

‘);
}

النموذج المتتالي الخطي

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

النموذج الأوّلي

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

النماذج المتطورة

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

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

1. الاتصال الفعال بين الزبون والمطور.
2. التخطيط وذلك بتعريف الموارد والمسالك الزمنية للمشروع.
3. تحليل الأخطار التقنية والإدارية المتوقعة.
4. البناء الهندسي التمثيلي.
5. البناء والاختبار.
6. تقييم الزبون للعمل.

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

نموذج الجيل الرابع التقني

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

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

(مكتمل الكتابة والتدقيق)