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

أهداف الدرس:سوف نحاول خلال هذا الدرس الإجابة على هذه الأسئلة:

ما هي هندسة البرمجيات؟
من يشارك بها؟
ما هي مكونات النظم البرمجية؟
وكيف يتم بنائها؟


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

المرجع :
1- Shari Pfleeger, "Software Engineering - Theory and Practice", 2nd Edition



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

وبنفس الفكرة يمكن النظر إلى علم الحوسبة computer science حيث يكون تركيزنا على الحواسيب ولغات البرمجة لدرستها وتطويرها في حد ذاتها.
أو يمكن النظر إليها والتعامل بها على أنها أدوات نستخدمها عند تصميم وتطوير حل لمشكلة ما تواجهنا أو الآخرين.

مهندس البرمجيات Software Engineer يعتبر أن الكمبيوتر هو أداة لحل المشاكل problem-solving tool.
وعليه أن يستخدم معلوماته حول الحاسوب وعلم الحوسبة للمساعدة في حل المشكلة التي يطلب منه إيجاد حل لها.






ولكن ومن المهم أن نتذكر أن عملية كتابة البرامج تعد فن Art بقدر ما هي علم، لماذا؟

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

أي أن، هندسة البرمجيات تعنى بتصميم وتطوير برامج ذات جودة عالية.

من يشارك في هذه العملية؟
المشاركون في عملية صناعة البرنامج، عادة ما يندرجون تحت ثلاث مجموعات:

الزبون Customer: وهو الشركة (أو الشخص) الممولة لمشر وع تطوير البرنامج المطلوب

المستخدم User: الشخص (أو مجموعة الاشخاص ) الذي سوف يقوم فعلا باستعمال البرنامج، والتعامل معه مباشرة.

المطور Developer: وهو الشركة (أو الشخص) الذي سوف يقوم بتطوير البرنامج لصالح الزبون.

                                                  ***************************

                                                         دورة حياة تطوير المشروع


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

مقدمة:
عملية بناء أي منتج تمر بعدة مراحل يطلق عليها عادة "دورة الحياة" Life Cycle، ومما تعلمنا في الدرس السابق فإن دروة حياة تطوير أي نظام برمجي Software development life cycle تتضمن المراحل التالية:
1. تحديد وتعريف المتطلبات Requirements analysis and definition
2. تصميم النظام System design
3. تصميم البرنامج Program design
4. كتابة البرنامج (تطويره) Program implementation
5. أختبار وحدات البرنامج Unit testing
6. أختبار النظام system testing
7. تسليم النظام system delivery
8. الصيانة maintenance

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


أنماط دورة الحياة Lifecycle Models:


النموذج الانحداري Waterfall Model
في هذا النموذج تسير دورة الحياة بشكل تدريجي بدأ من الخطوة (1) وحتى الخطوة (8)، وكما يظهر بالشكل (1) فإن كل مرحلة تبدأ بعد الأنتهاء من المرحلة التي تسبقها مباشرة.



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

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


التطوير على مراحل Phased Development
حسب النموذج الانحداري فإنه يجب على المطورين إنهاء مرحلة تحليل المشروع بشكل تام قبل البدأ في التصميم، وكما وضحنا فإن هذه المرحلة قد تتطلب وقت طويل في بعض المشاريع وقد تمر عدة سنوات قبل أن يرى البرنامج النهائي النور، ولكن هل يمكن لسوق العمل الانتظار كل هذا الوقت؟!

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

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




· النموذج التكراري Iterative model
هذه المرة يتم تسليم برنامج بكامل الوظائف من أول مرة، ولكن يتم تعديل وتغيير بعض تلك الوظائف مع كل إصدار من البرنامج.




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


النموذج اللولبي Spiral Model
وهو شبيه لدرجة كبيرة إلى النموذج التزايدي والتكراري، ولكن فيه يتم دمج فعاليات التطوير مع إدارة المخاطر risk من إجل التحكم بها وتقليلها.
يبدأ النموذج اللولبي بمتطلبات العميل مع خطة العمل المبدئية (الميزانية، قيود النظام، والبدائل المتاحة). ثم يتقدم خطوة إلى الامام بتقدير المخاطر وتمثيل البدائل المتاحة قبل تقديم ما يعرف بـ "وثيقة العمليات" Concept of Operations التي تصف وبشكل عام (بدون الدخول في التفاصيل) كيف يجب على النظام أن يعمل. بعدها يتم تحديد وتدقيق المتطلبات للتأكد من أنها تامة ودقيقة إلى أقصى حد ممكن.
بذلك تكون وثيقة العمليات هي المنتج من الطور الأول، و المتطلبات هي المنتج الاساسي من الطور الثاني. وفي الطور الثالث تتم عملية التصميم، أما الاختبار فيتم خلال الطور الرابع.
في كل طور أو مرحلة يساعد تحليل المخاطر على تقدير البدائل المختلفة في ضوء متطلبات وقيود النظام، وتساعد النمذجة على التحقق من ملائمة أي بديل قبل أعتماده. 

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

في هذا الدرس سوف نبدأ في دراسة أول (ولعلها أهم) خطوة في تطوير البرامج وهي تحديد متطلبات النظام Capturing the requirements.


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


المتطلبات: هي تعريف لشكل النظام أو وصف لما يستطيع هذا النظام أن يقوم به لأداء وظيفته التي سيصمم من أجلها.

خطوات تحديد المتطلبات:


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

طرح الأسئلة على العميل، ومن المفيد أحيانا أن نطرح نفس السؤال ولكن بأسلوب مختلف أكثر من مرة فهذا يساعدنا على التأكد من أننا نفهم ما يقصده العميل بالتحديد.

عرض نظم مشابه للنظام المطلوب سبق تصميمها من قبل.

تصميم وعرض نماذج لأجزاء من النظام المطلوب أو للنظام بالكامل.

تقسم المتطلبات إلى عدة عناصر تشمل:

البيئة المحيطة بالنظام Physical Environment

وجهات الاستخدام Interfaces

المستخدمين وإمكاناتهم Users and human factors

وظائف النظام Functionality

التوثيق Documentation

البيانات Data

المصادر Resources

الأمن Security

ضمان الجودة Quality Assurance

ويجب التأكد من أن نناقش جميع هذه العناصر

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

أولا تمكن المطورين من شرح فهمهم للطريقة التي يود المستخدمين أن يعمل بها النظام.

ثانيا توضح للمصممين ماهية الوظائف والخصائص التي سيمتاز بها النظام,

وثالثا: توضح المتطلبات لفريق الاختبار ما الذي يجب إثباته لإقناع الزبون أن النظام الذي تم تطويره هو ما سبق أن طلبه بالضبط.


لذلك ولضمان أن كلا من المطورين والزبون متفاهمون تماما على ما يجب القيام به، فإن المتطلبات المسجلة حتى هذه الخطوة يجب أن تكون لها الصفات التالية:
1. أن تكون صحيحة Correct وخالية من الأخطاء.
2. أن تكون ثابتة consistent بمعنى أن لا يكون هناك أي تعارض بين متطلب وآخر.
3. أن تكون تامة Complete يجب أن يتم ذكر جميع الحالات المحتملة للنظام، المدخلات، المخرجات المتوقعة منه، ...الخ.
4. أن تكون واقعية realistic بمعنى أن تكون قابلة للتطبيق في الواقع.
5. أن تكون متعلقة بأمور ضرورة للعميل، ويتطلبها النظام.
6. أن يكون من الممكن التحقق منها verifiable
7. أن تكون قابلة للتتبع traceable
يطلق على هذه الوثائق "وثائق تعريف المتطلبات" Requirement Definition Document


ثالثا: إعادة تسجيل المتطلبات بشكل رياضي mathematical ليقوم المصممون بتحويل تلك المتطلبات إلى تصميم جيد للنظام في مرحلة التصميم.لسنوات عديدة كان يتم الاكتفاء بوثيقة تعريف المتطلبات (التي تحدثنا عنها قبل قليل) والتي تكتب باستعمال اللغة الطبيعية (لغة البشر) لوصف وتسجيل متطلبات النظم بحيث يمكن للعميل أن يفهم كل كلمة موجودة بها، إلا أن ذلك يسبب العديد من المشاكل والتي يعود سببها في أغلب الأحيان إلى سوء تفسير بعض التعبيرات للمستخدمين من قبل المصمم أو العكس، فعلى سبيل المثال قد يطلق المستخدم على النظام التعبير (متوقف عن العمل) إذا كان النظام مشغول بعملية تسجيل احتياطي backup باعتبار أن لا يستجيب لأوامر المستخدم في هذه الحالة، بينما يعتبر المصمم أن النظام في هذه الحالة (مستمر في العمل) لأنه يقوم بمهمة أساسية!
لذا فأن الاعتماد على اللغة البشرية بشكل تام قد يؤدي إلى أخطاء كثيرة عند تصميم النظام، وينتج عنها نظام لا يقبله العميل لأنه لا يلبي متطلباته التي حددها من قبل، لذلك يتم كتابة نوع ثاني من الوثائق تسمى "وثائق مواصفات المتطلبات" Requirement specification Document وهي تكتب باستعمال وسائل وطرق خاصة ابتكرها مهندسو البرمجيات لكتابة المتطلبات باسلوب تقني بحت. منها على سبيل المثال: لغة النمذجة الموحدة UML Unified Modeling Language و هي لغة نمذجة رسومية تقدم لنا صيغة لوصف العناصر الرئيسية للنظم البرمجية.
رابعا: التثبت والتحقق من المتطلبات التي تم تسجليها في كلا من وثيقة تعريف المتطلبات (والتي تقدم للعميل) ووثيقة مواصفات المتطلبات (والتي تقدم للمصمم) للتأكد من صحتهما وشموليتهما وأن كلا منهما لا تعارض الثانية في أي نقطة، وإلا فإن النتيجة سوف تكون نظام لا يلبي طلبات العميل

نكمل مع خطوات بناء النظام، وهذه المرة سوف نتحدث عن خطوة "تصميم النظام"

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

عند الانتهاء من خطوة تحديد المتطلبات، فإننا ننتهي بوثيقتين (كما ذكرنا في الدرس السابق) الأولى هي (وثيقة تعريف المتطلبات) ويتم تقديمها للعميل والثانية (وثيقة مواصفات المتطلبات) ويتم تقديمها للمصمم.

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

أولا: يتم إنتاج التصميم التصوري conceptual design والذي يوضح للعميل ما الذي سيقوم به النظام بالتحديد.
وفي حال موافقة العميل على هذا النظام، يتم الانتقال للخطوة التالية.

ثانيا: تحويل التصميم التصوري إلى وثيقة بها تفاصيل أكثر عن التصميم يطلق عليها اسم التصميم التقني technical design والذي يجب أن يظهر للمطور ما هي المعدات والبرمجيات اللازمة لبناء النظام.

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

التصميم التصوري conceptual design:
يركز هذا التصميم على وظائف النظام functions ويكتب بلغة يمكن للعميل أن يفهمها (لغة البشر) ليجيب عن أسئلة العميل حول ماذا (WHAT) يعمل النظام. ويجب أن يكون خالي تماما من أي تفاصيل برمجية أو فنية. والاهم أن يحقق كل المتطلبات التي تم تحديدها سابقا.

التصميم التقني technical design
هذا التصميم سوف يتم تقديمه إلى مطوري النظام ليقوموا هم بتحويله إلى النظام المطلوب، لذا يجب أن يقدم هذا التصميم إجابة شافية لأسئلة المطور عن كيفية (HOW) تطوير النظام. ولمنع إلى تضارب في المفاهيم فإن هذا التصميم عادة ما يكتب باستعمال تعبيرات وأساليب تقنية.
 

·.·´¯`·.· (نهاية الدرس) ·.·´¯`·.·