السـلآمُ عليكُم ورحمةُ الله وبركاتـُه






البرمجيات

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

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

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

تهتم
هندسة البرمجيات عموماً بتحليل البرمجيات وتصميمها وبناءها وتَحققها
وإدارتها. وللقيام بهندسة البرمجيات على وجه صحيح، يجب تعريف الإجرائية
البرمجية software process، أي المنهج المتّبع لهندسة البرمجيات.

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

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

أ ـ النموذج التتابعي الخطي

ويسمى «دورة الحياة التقليدية».
وهو منهج تتابعي منتظم لتطوير البرمجيات، يبدأ على مستوى النظام ويتقدم
تباعاً إلى التحليل فالتصميم فالترميز فالاختبار فالصيانة (الشكل ـ1).

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

ب ـ النمذجة الأولية

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

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

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

النماذج التطورية evolutionary models تكرارية، وتوصَّف بطريقة تمكِّن مهندس البرمجيات من تطوير نسخ أكثر تعقيداً من البرمجيات، وسنذكر فيما يلي اثنين من هذه النماذج:

(1) النموذج التزايدي incremental model (الشكل ـ1). يَجمع عناصرَ من النموذج التتابعي الخطي مطبقة بصورة متكررة، وعليه يقوم النموذج التزايدي بتطبيق تتابعات خطية بصيغة متعاقبة الترتيب مع تقدم زمن الإنتاج، ويُنتِج كلُّ تتابع خطي تزايداً increment من [ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط] قابلاً للتسليم.

(2) النموذج الحلزوني spiral model (الشكل ـ2). يقُسّم إلى عدد من الفعاليات (ما بين 3 إلى 6 فعاليات)، هي:

[ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذه الصورة]

الاتصال بالزبون (التواصل الفعال بين الزبون والمطور)،

التخطيط (تعريف الموارد والمسارات الزمنية للمشروع)،

تحليل المخاطرة risk analysis (تقييم المخاطرة التقنية والإدارية)،

الهندسة (بناء تمثيل أو أكثر للتطبيق)،

البناء والإصدار construction & release (مهمات البناء والاختبار)،

تقويم الزبون customer evaluation (الحصول على تقييم الزبون للعمل).

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

د ـ نموذج تقانات الجيل الرابع (4GT) Fourth Generation Technologies

وهي
تشمل قائمةً واسعة من أدوات برمجية تشترك معاً في أن كلاً منها يسمح
لمهندس البرمجيات بتوصيفٍ عالي المستوى لخواص البرمجيات [ر]. تولّد الأداةُ
آلياً بعدئذٍ الرمازَ المصدري source code بالاعتماد على توصيف المطوِّر.

3 ـ إدارة المشاريع البرمجية

هي
فعالية تواكب هندسة البرمجيات؛ تبدأ قبل الشروع بأيَّة فعالية تقنية،
وتستمرُّ طَوال تعريف البرمجية وتطويرها وصيانتها. هناك ثلاث كلمات تبدأ
(بالإنجليزية) بالحرف P لها تأثير كبير في إدارة المشاريع البرمجية، هي: الأشخاص people والمشكلة problem والإجرائية process.
يجب تنظيم الأشخاص في فرق فعَّالة، وتحفيزهم للقيام بعمل برمجيات عالية
الجودة، وتنسيقهم لتحقيق اتصالات فعَّالة. ويجب أن تُنقلَ المشكلة من
الزبون إلى المطوِّر، وأن تُجزَّأ (تفكَّك) إلى الأجزاء المكونة لها، وأن
توضع موضع عمل الفريق البرمجي. ويجب أن تكيَّف الإجرائية للأشخاص وللمشكلة.

4 ـ تخطيط المشاريع البرمجية

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

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

5 ـ ضمان جودة البرمجيات

تعني جودة البرمجيات «التوافق مع المتطلبات الوظيفية والأداء المعرفين بوضوح، ومع مَقايس (جمع مِقْيَس standard) التطوير الموثقة بوضوح أيضاً، ومع الميزات الضمنية المتوقعة في جميع البرمجيات الاحترافية».
لذا تُعتبر المتطلبات البرمجيةُ الأساسَ الذي تقاس عليه الجودة. ويكون
القصور في التوافق مع المتطلبات مرادفاً للقصور في الجودة. وتعني ضمان جودة
البرمجيات (SQA) Software Quality Assurance توفير المعطيات الكافية بشأن جودة البرمجيات.

في الأيام الأولى لعصر الحوسبة (ما بين 1950 و1960)، كانت مسؤولية الجودة مناطة بالمبرمجين فقط. أما مقايس ضمان جودة البرمجيات SQA فقد جرى إدخالها خلال السبعينيات. ويقتضي ضمان جودة البرمجيات في الوقت الحالي وجود أقسام في المؤسسات البرمجية تُناط بها مسؤولية ضمان جودة البرمجيات، إذ يجتمع في مجموعة ضمان جودة برمجيات مهندسو البرمجيات، ومديرو المشاريع، وممثلو الزبائن، ومسؤولو البيع، والأفراد الذين يخدمون ضمن مجموعة ضمان جودة البرمجيات.

ISO 9001 هو مِقيَس ضمان الجودة المطبق في هندسة البرمجيات. يتضمن هذا المِقيَس 20 متطلباً يجب توفرها لكي يتحقق نظام ضمان الجودة فعلياً.

6 ـ إدارة تشكيلة البرمجيات

إدارة تشكيلة البرمجيات (SCM) software configuration management هي
فن تعيين هوية التعديلات المجراة على البرمجيات التي يبنيها فريق برمجة
وإدارتها والتحكم فيها. والغرض منها هو زيادة الإنتاجية إلى حدها الأعظم
وتقليل الأخطاء إلى حدها الأصغر. ذلك أن التغيير change محتوم
عند بناء برمجيات الحاسوب، ويرفع التغيير مستوى الارتباك بين مهندسي
البرمجيات الذين يعملون في مشروع ما. إذ ينشأ الارتباك عندما لا يجري تحليل
التغييرات قبل إجرائها، وتسجيلها قبل تنفيذها، وتبليغها لأولئك الذين يجب
أن يعلموا، والتحكم فيها بطريقة تؤدي إلى تحسين الجودة وتقليل الخطأ.

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

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

7 ـ هندسة النظام

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

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

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

8 ـ مفاهيم التحليل ومبادئه ونمذجته

إن
الفهم الكامل لمتطلبات البرمجيات أساسيٌّ لنجاح جهود تطويرها. فقد يسبِّب
برنامجٌ ذو تحليل وتوصيف ضعيفَيْن عدمَ رضا المستخدم، ويجلب الأسى للمطوّر
مهما كان تصميمه وترميزه جيدين.

تحليل المتطلبات هي مهمة من مهمات هندسة البرمجيات، تمكِّن مهندسَ النظم من: تحديد وظائف البرمجيات وأدائها، وذكر واجهة [ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط] مع المكونات الأخرى للنظام، ووضع قيود يجب أن تلتزمها البرمجيات.

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

اقتُرح على مدى سنوات العديد من طرائق نمذجة التحليل، وتسيطر حالياً طريقتان فقط على ساحة نمذجة التحليل: طريقة التحليل البنيوي structured analysis (طريقة تقليدية)، وطريقة التحليل الغرضي التوجه object-oriented analysis.

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

9 ـ مفاهيم التصميم

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

يشمل تصميم الواجهات: واجهات البرنامج الداخلية والخارجية وتصميم واجهة المستخدم.

يبدأ التصميم الإجرائي (وهو مرحلة الانتقال إلى الرماز) بعد إنهاء تصميم المعطيات والبنيان والواجهات. يَسمح تدوينُ التصميمِ design notation ومفاهيم
البرمجة البنيوية، للمُصممِ بتمثيل التفاصيل الإجرائية بطريقة تُسَهِّلُ
عملية الانتقال إلى الرماز. هناك عدة أنماط للتدوين: بياني (كالمخطط
التدفقي flowchart أو المخطط الصندوقي)، جدولي (كجدول القرارات)، نصي (بلغة طبيعية).

10 ـ اختبار البرمجيات

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

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

تطورت
على مر العقدين الفائتين تشكيلات غنية من طرائق تصميم حالات الاختبار
للبرمجيات. يوجد فئتان مختلفتان من تقنيات تصميم حالات الاختبار: اختبار
الصندوق الأبيض white-box testing واختبار الصندوق الأسود black-box testing.

تركِّز
اختباراتُ الصندوق الأبيض الاهتمامَ في بنية تحكّمِ البرنامج. وتُشتق
حالات اختبار لضمان تنفيذ كل عبارات البرنامج مرة على الأقل خلال الاختبار،
وتجريب كل الشروط المنطقية. يوصف اختبار الصندوق الأبيض بأنه «اختبار القطع الصغيرة». وهذا يعني تطبيق الاختبارات على مكونات صغيرة من البرنامج (أي مجتزآت –جمع مجتزأ (وحدة برمجية) module).

من جهة أخرى، توسع اختبارات الصندوق الأسود اهتمامنا، ويمكن أن تسمى «اختبار القطع الكبيرة». تصمَّم اختبارات الصندوق الأسود لكشف أخطاء المتطلبات الوظيفية، دون الالتفات إلى عمل البرنامج من الداخل.

11 ـ استراتيجيات اختبار البرمجيات

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

[ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذه الصورة]

يمكن النظر إلى استراتيجية اختبار البرمجيات من خلال سياق حلزوني (الشكل 3). يبدأ اختبار الوحدة unit testing من
مركز الحلزون، ويركِّز الاهتمامَ في التحقق الوظيفي لكل مجتزأ. تتقدم
الاختبارات بالتحرك على طول الحلزون خارجاً، نحو اختبار التكامل integration testing، حيث يُركَّز الاهتمام في دمج المجتزآت في بنيان البرنامج. وبالدوران دورة أخرى خارجاً في الحلزون، نصادف اختبار إقرار الصلاحية testing validation، حيث يجري إقرار صلاحية المتطلبات للبرمجية –التي نحصل عليها من تحليل متطلبات البرمجية. أخيراً نصل إلى اختبار النظام system testing، حيث تُختبر البرمجية لدى دمجها مع عناصر النظام الأخرى.

12- التفلية debugging
هي إجرائية إزالة الخطأ عندما يُكتشف، ويجب النظر إليها على أنها فنّ
(ليست إجرائيةٌ منظمةٌ). في حين، إن الاختبار فعالية نظامية ومخطط لها.
تقوم فعالية التفلية بتتبع سبب الخطأ، انطلاقاً من مؤشر عرَضي لمشكلة.

هناك عدة مناهج للتفلية. فمنهج القوة العمياء brute force يعتمد مبدأ «دع الحاسوب يكتشف الخطأ»،
وهو أشْيَع الطرائق وأقلّها فعّالية في عزل أسباب الخطأ البرمجي. نقوم
بتطبيق طرائق التفلية بالقوة العمياء عند إخفاق كل الطرائق الأخرى.

ويتمثل منهج إزالة السبب cause elimination بالاستدلال أو الاستنتاج، وهو يعتمد مفهوم التجزيء الاثناني binary partitioning لِعزل العثرات (الأخطاء) bugs.