logo

logo

logo

logo

logo

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

برمجيات (هندسه)

-

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

خليل عجمي

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

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

آفاق مستقبلية

 

تُعرَّف هندسة البرمجيات software engineering بأنها فرعٌ من فروع الهندسة يقوم على أسسٍ وقواعد تهدف إلى تصميم الأنظمة البرمجية التي تلبي احتياجات المستخدمين وتطويرها بجودةٍ ونوعيةٍ عاليةٍ، وذلك من خلال تحويل عملية التطوير إلى عمليةٍ إنتاجيةٍ تتألف من عدة مراحل أساسيةٍ وضروريةٍ تسمى دورة حياة المنتج البرمجي software lifecycle، تهدف إلى الحصول على المُنتج -وهو البرنامج- بأقل كلفةٍ ممكنةٍ وأفضل أداءٍ مُحتملٍ. وقد ظهر مصطلح هندسة البرمجيات لأول مرة عام 1968 في مؤتمر منظمة حلف شمال الأطلسي (الناتو) NATO الأول لهندسة البرمجيات، والذي كان يهدف إلى التفكير في حل الإشكالات التي تواجه عملية تصنيع البرامج وتطويرها في ذلك الوقت، والتي كانت تتمحور حول كتابة برامج مفيدة وفعالة تلبي احتياجات المستخدمين.

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

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

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

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

- التحليل analysis: يتمحور التحليل حول دراسة متطلبات النظام system requirements على نحوٍ تفصيلي بهدف تعريفها وتحديد حدود النظام ومدخلاته ومخرجاته، وذلك من خلال تعريف بنية النظام الداخلية ومتطلباته الوظيفية functional requirements وكل مجتزأ (نسيقة) module من مجتزآته ومحتواه ووظائفه، ونماذج المعطيات التي يتعامل معها، إضافة إلى تعريف متطلبات النظام غير الوظيفية non functional requirements بصفتها عوامل الأمان ولغة الواجهات وغيرها، والقيود الأخرى التي يخضع لها النظام.

- التصميم design: تهتم هذه المرحلة -على وجه الخصوص- بوضع تصميم لقاعدة المعطيات database ومخطط الكيانات entity diagram إضافة إلى برنامج الزبون الذي يربط واجهة الاستخدام بقاعدة المعطيات، كما يجري في هذه المرحلة أيضاً دراسة العديد من العوامل وتوثيقها، وهي تؤثر في إمكان فهم النظام وصيانته وتوسيعه.

- التحقيق implementation: تنطوي مرحلة التحقيق على ترميز برامج الزبون التطبيقية وقواعد معطيات المخدم. وتظهر فيها أهمية الآليات التكرارية والتزايدية التي يجري استخدامها خلال عملية التطوير؛ إذ يجري في أثناء التطوير –وعلى نحو تكراري وتزايدي- مراجعة مجتزآت تطبيقات الزبون التي يجري تطويرها، ومراجعة قواعد المعطيات التي يجري إنجازها، وذلك بمقارنتها مع نماذج التصميم، وهو ما يسهم إسهاماً جوهرياً في نجاح تسليم المنتج.

- التوثيق documentation: هو إحدى أهم مراحل بناء النظام البرمجي؛ إذ يتم توثيق البنية الداخلية للنظام، وبنية مجتزآته، ومكوناتها، ومحتوى الإجرائيات، ومدخلاتها ومخرجاتها؛ وذلك بغرض تقديم كل ما يلزم لتسهيل أي عملية صيانة وتطوير مستقبلية. يجري عادةً توثيق كل مرحلة من المراحل السابقة من خلال تكليف فريق خاص يتولى توثيق عملية بناء النظام إضافة إلى توثيق جميع المشاكل والحلول التي يمكن أن تظهر في أثناء بنائه. إن إهمال مرحلة التوثيق يجعل المسؤول عن صناعة النظام البرمجي عاجزاً عن متابعة صيانته وتطويره، وهو ما يرفع الكلفة المادية والزمنية الخاصة بالنظام البرمجي إلى حدودٍ غير متوقعةٍ، ويؤدي إلى استحالة بناء أنظمة برمجية ذات جودةٍ عاليةٍ ودورة حياةٍ طويلةٍ. عملياً هناك أكثر من مستوى للتوثيق: توثيق التحليل الذي يتمثل بكتابة مستندات شرح بنية النظام ومجتزآته ووظائفه إضافة إلى آليات عمله. وتوثيق التصميم الذي يتمثل بتوثيق بنية قاعدة المعطيات والواجهات البرمجية وآليات الارتباط بين تطبيق الزبون وبرامج المخدم. وتوثيق المبرمج ويتلخص في إضافة تعليقات داخل الرماز البرمجية. وتوثيق مُختَبِر النظام وفيها يتم تسجيل نقاط الخلل في البرنامج. وتوثيق الأدلة التي يجري فيها تجميع المعلومات التي تهم مدير النظام والمستخدم من خلال كتابة أدلة التنصيب والإدارة والاستخدام.

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

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

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

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

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

آفاق مستقبلية:

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

لقد مرت عملية تطوير البرمجيات في الماضي بمراحل كان لا بد فيها من ابتكار مفاهيم مثل التغليف encapsulation، تقسيم البرامج إلى مجتزآت؛ لتنظيم عملية كتابة رماز برمجي كبير ومتشعب. حالياً صار بإمكان فرق التطوير بناء أنظمة برمجية مؤلفة من مئات ملايين من الأسطر البرمجية، وذلك نتيجة تطوير المفاهيم الأولية السابقة إلى مفاهيم وإجراءات وأدوات أكثر تعقيداً كإدارة إعدادات البرمجيات software configuration management، وإدارة خطوط الإنتاج البرمجي software product lines، وعمليات الاختبار المؤتمتة software test automation، وبيئات تطوير البرمجيات المتكاملة software development environments. وجرى ربط هذه المفاهيم بأدوات معقدة وجرى إنتاج أدوات ونظم لدعمها، وقد مكّن هذا الأمر من تحويل صناعة البرمجيات العالمية إلى صناعة مُنتجة لنظمٍ برمجيةٍ ضخمةٍ ومعقدةٍ.

تزداد الضغوط قوة للاستمرار في تطوير هندسة البرمجيات والمفاهيم والأدوات المرتبطة بها، ويزداد حجم أنظمة البرمجيات المطلوبة نموّاً وتعقيداً نتيجة دخولها في مجالات الحياة كافة، وهو ما يضغط في اتجاه استمرار تطوير صناعة البرمجيات والمفاهيم المتعلقة بهندسة البرمجيات كلها، وهو ما يدفع الاختصاصيِّين إلى البحث في مجالاتٍ جديدةٍ، بحيث صارت البحوث في مجال هندسة البرمجيات -تدرس على نحو متزايد- توجُّهات وتحديات ومواضيع جديدة كالأمن والخصوصية في الأنظمة البرمجية المدمجة embedded systems security and privacy، وتعريف سلوكيات الأنظمة ذات المكونات الموزعة distributed components، وخصوصاً عندما يكون الرماز الخاص ببعض مكونات هذه الأنظمة مغلفاً وغير مفتوح.

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

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

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

مراجع للاستزادة:

-Bernd Bruegge & Allen Dutoit, Software Engineering: A Practitioner’s Approach, Prentice Hall, 2009. 

-S. Roger, Software Engineering: A Practitioner’s Approach, Boston, Mass: McGraw-Hill, 2009.

-Ian Sommerville, Software Engineering, Harlow, England: Pearson Education, 2010.


التصنيف : كهرباء وحاسوب
النوع : كهرباء وحاسوب
المجلد: المجلد الرابع
رقم الصفحة ضمن المجلد : 0
مشاركة :

اترك تعليقك



آخر أخبار الهيئة :

البحوث الأكثر قراءة

هل تعلم ؟؟

عدد الزوار حاليا : 1028
الكل : 43823313
اليوم : 106708