شرح مصطلحات عن مراحل تطوير البرامج وهندسة البرمجيات

• program specifications: توصيف البرنامج هو مانتوقع من البرنامج أن يقوم به، أي نرسل له بعض البيانات و تكون النتيجة صحيحة ومتوقعة، 
• problem solving: حل المشكلة البرمجية يكون باتباع خطوات، مثل تحديد المشكلة (بيانات غير مرتبة) ثم التفكير بحل (خوارزمية ترتيب) ثم محاولة تطبيق هذا الحل (تجريب عدة خوارزميات واختيار الأنسب) ويكمن في جميع خطوات حل المشاكل 
• implementation: هي مرحلة كتابة الشيفرة البرمجية التي تترجم الحل المنطقي أو خطوات الخوارزمية التي تحل المشكلة
• testing: مرحلة اختبار التطبيق، أي التأكد هل البرنامج النهائي يقوم بعمله بشكل صحيح؟ أي هل يلبي البرنامج توصيف البرنامج نفسه؟ هل البرنامج يرتب البيانات بطريقة صحيح؟
• debugging: عند إيجاد خلل في البرنامج، نعود للشيفرة البرمجية ونحاول معرفة أين الخطأ وهمل تعديلات ثم التجريب وهكذا.

هل هناك مراجع او فديوهات اقدر استزيد عنها بالعربي

بتاريخ 6 دقائق مضت قال hanan fahad11:

هل هناك مراجع او فديوهات اقدر استزيد عنها بالعربي

حاولي البحث عن هذه المواضيع:

في عملية التطوير بعدة مراحل تختلف من حيث التقنيات المستخدمة في كل مرحلة .وهذه المراحل هي:

• مرحلة جمع المتطلبات للبرنامج.
• مرحلة التصميم.
• مرحلة كتابة البرنامج.
• مرحلة الاختبار.

هذه الأفكار لها علاقة بهندسة البرمجيات.

بتاريخ 11 ساعات قال hanan fahad11:

هل هناك مراجع او فديوهات اقدر استزيد عنها بالعربي

شرح إضافي: Software Requirements Specification (SRS):

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

بتاريخ 12 ساعات قال Wael Aljamal:

implementation

مثل مرحلة تحويل تصميم قاعدة البيانات لشيفرة برمجية، أو تعريف الأصناف CLASS التي تمثل عناصر النظام (مدير - تلميذ)

بالنسبة للاختبار، هنالك نوعين مشهورين

• unit test: اختبار على مستوى الوحدة مثل اختبار دالة أو صنف أي مجال محدود من المشروع
• integration test: اختبار على مستوى النظام ككل. يشمل عدة مراحل من عمل النظام (أكثر من وحدة unit بنفس الوقت)

إن ماتتحدثين عنه هو ال activities (أنشطة) الأساسية الموجودة في أي نظام برمجي. وهذه ال activities تختلف تسميتها عادةً من مرجع إلى آخر:
{ 1.التوصيف البرمجي. 2.تطوير البرمجيات. 3.الاختبار أو التقييم. 4.التطور } أو {1.التحليل. 2.التصميم. 3.التنجيز. 4. الاختبار}. وفي بعض الأحيان تسمى المرحلة الأولى بمرحلة (التواصل). و ذلك لأننا نتواصل مع ال stakeholders لتحديد الخدمات التي يقدمها النظام أو تسمى بمرحلة (التعرف على المشكلة) و هي مرحلة تمهيدية و نتيجة لتلك المرحلة يظهر بما يعرف بوثيقة تعريف المشكلة و بعد ذلك نحدد النظام المراد لحل هذه المشكلة، فهي بالنهاية مرحلة جمع المتطلبات. وبعد القيام بعملية جمع المتطلبات تقوم بتجميع المتطلبات و نحذف أي طلبات مكررة كما أننا نعتمد على متطلب واحد إذا وجد متطلبان متعاكسان (متناقضان) و كمثال على ذلك:وجد لدينا متطلبان هما security عالي مع أداء سريع و هما متطلبان متناقضان و لا يمكن تحقيقهما في نفس الوقت. و لذلك نعود إلى ال stakeholders و ذلك لنرى ما هو المتطلب من بينهما الأكثر أولوية و عندها نختاره على حساب المتطلب الآخر.
الآن مارأيك قبل أن نكمل أن نقوم بالرجوع قليلاً للتعرف على الإجرائية البرمجية، فما هي ؟؟
هي مجموعة الأنشطة المترابطة مع بعضها البعض التي تؤدي إلى إيجاد نظام جديد أو تطوير نظام قديم. فنحن بين حلنا لهذه المشكلة و إيجاد النظام البرمجي لدينا مجموعة من الخطوات وهذه الخطوات يتم تمثيلها الإجرائيات البرمجية . ويمكن النظر إلى software engineering على أن الهدف منه تطوير النظم البرمجية و ذلك وفق ثلاث قيود: 1. الجود العالية (high quality). 2. الكلفة المنخفضة (low cost). 3. رضى الزبون (Max satisfaction).
ورضى الزبون يعتبر المعيار الأساسي.
و نحن دائماً بحاجة إلى خطوات لاتباعها من بداية ظهور المشكلة لتطوير النظام البرمجي تبعا لإجرائية برمجية، و هي ليست لديها نهاية لأنها تبقى طالما النظام يعمل حتى ننتهي من عمليات التطوير ، و هذه الخطوات تسمى بالإجرائيات البرمجية. و كذلك نحن بحاجة إلى methods معينة مثل (برمجة غرضية التوجه OPP ..) كما أننا في هذه الخطوات بحاجة لوضع خطط معينة لحساب التكلفة مثل أو تقسيم العمل أو حساب أعداد المهندسين و قدراتهم أو حساب الجدول الزمني و كل ما سبق يسمى بالمرحلة التمهيدية، و بعد المرحلة التمهيدية يتبين لنا النظام إذا كان visible نباشر في تطويره و إذا لم يكن visible ننسف النظام كله. إذن استناد ا إلى الشرح السابق تكون الإجرائية البرمجية: مجموعة الأنشطة و الطرق و الأدوات و المخططات المترابطة بعضها البعض التي تؤدي لفهم المشكلة و إيجاد نظام جديد مجدي لحل تلك المشكلة و الذي يحقق الكلفة المنخفضة و
الجودة العالية و رضا الزبون.
و تلك النشاطات نقسمها إلى أربعة أقسام عامة (كما قلت لك تختلف تسميتها لكن هي نفس المراحل):
1. التوصيف البرمجي أو program specifications (التحليل):
تحديد ماهو مطلوب من النظام أو ما يقدمه النظام من خدمات. و هذا ما نعرفه من ال stake holders، حيث هم أشخاص أو مؤسسسات تمثل بأشخاص يؤثرون أو يتأثرون بطريقة مباشرة أو غير مباشرة في هذا النظام. فبعد عملية تحديد المشكلة نقوم بتحديد ال stake holders ثم نقوم بعملية جمع المتطلبات، و بعد عملية جمع المتطلبات، نقوم بتحليل المتطلبات و تصنيفها و ذلك بالاتفاق مع ال stake holders و هذا ما نسميه بالتوصيف. وتنتهي مرحلة التوصيف بوثيقة تسمى دفتر الشروط أو وثيقة المتطلبات، فبعد تحديد المشكلة يتم تحديد ال stakeholders و نرى المتطلبات و الأولويات لهذه المتطلبات و ذلك بالعودة إلى ال stakeholders و بعد ذلك نعالج هذه المتطلبات و نزيل التكرار ونرى المتطلبات المتناقضة و نختار أحدها بالاتفاق مع ال stakeholders ، و بعد ذلك تكتب هذه المتطلبات في وثيقة هي وثيقة نهاية مرحلة التوصيف و تسمى بوثيقة المتطلبات أو دفتر الشروط.
2. التصميم و التنجيز design and implementation:
و لهذه المرحلة ننتقل من مرحلة ما هو مطلوب من النظام إلى مرحلة تحقيق ما هو مطلوب من هذا النظام .
و المسؤول عن هذه المرحلة هو المصمم و للمصمم وظائف عديدة هي: 1. عليه أن يعرف بمعمارية النظام، ونقصد بمعمارية النظام أي تقسيم النظام إلى أجزاء بحيث يؤدي كل جزء من الأجزاء خدمة معينة دون أن تتكرر هذه الأجزاء أو تتناقض، بل يجب أن تتكامل. كما يجب وضع الخوارزميات الملائمة لكل جزء من الأجزاء حيث أنه يعتمد على عمل المحلل و يقوم بتوزيع الخدمات التي يقدمها المحلل إلى تلك الأجزاء المتكاملة التي تكوّن النظام.
2. يجب أن يقوم بتصميم قاعدة المعطيات و مخططات ال أن يقوم بتصميم قاعدة المعطيات و مخططات ال ERD الخاصة بهذا النظام و المناسبة له.
3. يقوم بتصميم الواجهات الخاصة بالنظام البرمجي و يعتبر تصميم الواجهات المعيار الأساسي لنيل رضا الزبون و لقبول النظام.
ثم يأتينا ال code generation أو التنجيز وهذه المرحلة هي مرحلة بسيطة و تافهة بالنسبة للمرحلتين السابقتين و يقوم بهذه المرحلة المبرمج
بكتابة الخوارزميات التي صممها المصمم و تحويلها إلى code.
3.testing (الاختبار):
وهي مرحلة تجريب النظام و هي لا تعني أن نجربه كي لا نكتشف أخطاء بل تهدف إلى تجريب النظام بهدف العثور على أخطاء و تصحيحها و يكون النظام ناجحاً أكثر كلما كانت الأخطاء به أكثر. وعمليات ال testing عموماً لا تتم فقط في هذه المرحلة بل تكون مقسمة إلى أجزاء بحيث أن كل مرحلة من المراحل السابقة يكون لدينا testing معين في نهايتها و هذا ما نسميه بنظام المظلة أو umbrella Activity  وبهذه الطريقة يكون لدينا عمليات testing و اختبارات على مدى تطور النظام حيث أن الإجرائية البرمجية تبدأ من لحظة الفكرة و تستمر إلى اللانهاية و في كل جزء من أجزاءها يكون لدينا عمليات testing تظلل النظام و من هنا جاءت كلمة مظلة لأنه نشاط يبدأ معها و يستمر معها إلى اللنهاية.
4.التطوير (الصيانة): هي عملية تعديل منتج البرنامج بعد تسليمه للعميل. والغرض الرئيسي من صيانة البرامج هو تعديل تطبيقات البرامج وتحديثها بعد التسليم لتصحيح الأخطاء وتحسين الأداء وإضافة خصائص جديدة إلى البرنامج..إلخ.