التفريغ النصي لمحاضرة: بانوراما هندسة البرمجيات

المقدمة


بسم الله الرحمن الرحيم، الحمد لله رب العالمين والصلاة والسلام على الرحمة المهداة للعالمين، سيدنا محمد وعلى آله وصحبه أجمعين، وعلى التابعين، ومن تبعهم بإحسان إلى يوم الدين، ثم أما بعد:
أيها الاخوة الأفاضل، أيتها الأخوات الكريمات:
السلام عليكم ورحمة الله تعالى وبركاته.
بداية، اسمحوا لي أن أتوجه بالشكر الجزيل والثناء الوفير لأخي الحبيب يونس معدان الذي بذل جهدا كبيرا في سبيل أن يتحقق هذا الجمع المبارك، وإلى سائر أفراد إدارة المدرسة العليا للأساتذة، ثم إلى سائر السادة الحضور من أساتذة أجلاء وطلبة فضلاء.
في الحقيقة، كنت أنتوي الحديث عن موضوع من موضوعات الدوت نيت بحكم طبيعة تخصصي، كأن نتحدث عن الفروق بين لغة الفيجوال بزيك دوت نيت وبين لغة سي شارب، أو أن نتحدث عن التقنيات الحديثة التي رافقت إصدارات الدوت نيت الأخيرة بدء من النسخة 3.5 مثل تقنية Entity Framework، WPF، WCF، LINQ وغيرهم، لكن بلغني أن أخي الفاضل أنس صحري سيتناول في محاضرته نطاق الدوت نيت عبر عرض أوجه الاختلاف والائتلاف بينه وبين نطاق جافا.
ففكرت في الأمر مليا، فخرجت بنتيجة مفادها أن الحديث عن نفس الموضوع ولو من زوايا مختلفة قد يسبب نوعا من الرتابة والملل لدى المتابعين الكرام، فارتأيت أن أغير الوجهة صوب موضوع شامل يخص كل لغات البرمجة، ويكون له تأثير جوهري على عملية صناعة البرمجات فوجدت أن أفضل موضوع في هذا الشأن هو هندسة البرمجيات Software Engineering / Génie Logiciel.
طبعا المحاضرة ستكون عبارة عن رحلة استطلاعية لهذا التخصص الرائع، سنلقي عليه نظرة من فوق: بانوراما، من خلالها نفهم ماهية هذا التخصص وأهميته البالغة في عملية صناعة البرمجيات.
قبل ذلك اسمحوا لي أن أستعرض أمامكم مجموعة من المعلومات التقنية كتمهيد لهندسة البرمجيات.
نشرت مجلة سيو ماڭازين CEO Magazine في شهر ديسمبر من عام 1998 خبرا مفاده أن مؤسسة ستانديش ڭروب، وهي مجموعة مهتمة بدراسة طرق إدارة المشاريع البرمجية Software Project Management ways كما تعرف نفسها على موقعها الرسمي.

هذه المجموعة (ستانديش غروب) أشارت في بحث لها أن 46% من المشاريع البرمجية تجاوزت المدة المتفق عليها، بل وتجاوزت حتى الميزانية المخصصة لها، بل ولم تلبي حاجيات العملاء..
يعني أن 46% من المؤسسات البرمجية، لم تفلح أن توفق بين الميزانية والوقت المخطط لهما وبين الميزانية والوقت الفعلي الذي استغرقته عملية صناعة البرمجيات.
وذكرت نفس المجلة (سيو ماڭازين) أن مجموعة ستانديش غروب قد أحصت كذلك نسبة 28% من المشاريع التي فشلت تماما، ولم يقدر لها لا النجاح ولا حتى أن يتم إنتاجها بصرف النظر عن الميزانية والوقت الذي تم التخطيط له، يعني خلاص فشلت بشكل كامل.
وذكرت المجموعة أن 24% فقط من المشاريع البرمجية هي التي كتب لها النجاح.
دقق معي جيدا، نحن الآن لا نتحدث عن مبرمجين هواة أو عن مؤسسات برمجية صغيرة، بل نتحدث عن مؤسسات كبيرة وتضم مهندسين وأطر عليا ومع ذلك قدر لمشاريعها أن تموت في المهد، أو تكتمل بشكل شائه دون احترام للميزانية المخصصة لها أو الوقت المزمع أن تستغرقه.
فيما يلي رسم بياني يعرض نفس البحث الذي تقوم به مجموعة Standish Group لكن لعام 2012:



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

وذكرت المؤسسة العسكرية الأمريكية US Army  أنها أنفقت على مشروع برمجي ما قيمته 1 بليون دولار (مليار دولار) زيادة على الميزانية المخصصه له، ومع ذلك مايزال هذا المشروع غير شغال.

قبل أحداث الحادي عشر من سبتمبر من عام 2001 بالولايات المتحدة الأمريكية وتحديدا عام 2000، قام المكتب الاتحادي للتحقيقات The US Federal Bureau of Investigation (FBI) بتكليف المؤسسة الدولية للتطبيقات العلمية Science Applications International Corp (SAIC)  بتطوير برنامج اسمه Virtual Case File software (VCF).
دور هذا البرنامج هو إدارة ملفات القضايا الكترونيا، بمعنى أن أي مستخدم له صلاحيات في هذا النظام يمكن له أن يطلع على معلومات القضايا.
تم تحديد ثلاث سنوات غطاء زمنيا لإنجاز هذا المشروع، أي في عام 2003 يتعين أن يكون النظام كاملا بكل ما تم الاتفاق عليه من مهام وعمليات.
انتهت المدة المحددة، وتم تسليم نسخة من هذا النظام للمكتب الاتحادي للتحقيقات The US Federal Bureau of Investigation في شهر دجنبر من عام 2004، وكانت هذه النسخة علاوة على التأخير الزمني مليئة بالعيوب والنقائص. من بين العيوب التي تم رصدها في نسخة النظام المسلمة:
أن ما تم إنجازه لا يمثل سوى واحد من عشرة من البرنامج الذي تم الاتفاق عليه
النسخة المسلمة لايمكن العمل عليها، وإنما تصلح فقط أن تكون نموذجا أوليا Prototype للنظام.
ما يقارب 170 مليون دولار ضاعت هباء منثورا.

في شهر أبريل من عام 2005 توقفت عملية تطوير المشروع وتم التصريح بفشله.

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

أسباب فشل المشاريع البرمجية


يمكننا أن نجمل أسباب فشل المشاريع البرمجية في النقاط التالية:

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

2. سوء تقدير الموارد اللازمة من ميزانية ووقت (الوقت وما أدراك ما الوقت، لا يمكنك السيطرة عليه، لكن يمكنك إدارته، ولكي لا يواجه مشروعك البرمجي الفشل، قم بإعطاء مرحلة التخطيط Planning وقتا كافيا، لا تبدأ مباشرة في كتابة الكود حتى وإن كنت متيقنا من أن مايدور برأسك هو نفسه ما يريده العميل، خذ كل وقتك في مرحلة التخطيط لتفهم النظام ومتطلباته بشكل دقيق، هذا الأمر سيسهل عليك كل العمليات التي تأتي بعده من كتابة كود واختبار وتحزيم وغيرهم، أما بخصوص الميزانية، فلا تعتقد أنك إن خفضت تكلفة النظام ستربح العميل، لأن مايهمه في الأخير هو نظام برمجي ينقص عليه المصاريف أو يزيد له المداخيل.
البعض منا لديه أفكار خاطئة حول تقييم تكلفة المشروع، ويظن أنه لو ذكر ثمنا مناسبا سيرفض العميل بحجة أن الثمن مرتفع، فيقوم بتخفيض المبلغ مخافة أن يفر العميل من بين يديه، وهذا خطأ فادح، قم بدراسة مشروعك وصمم له الحل بهدوء وخذ وقتك الكافي في ذلك، ثم قم بتحديد الميزانية اللازمة لإنجاز المشروع في المدة الزمنية التي حسبتها ولا تفكر في أي شيء آخر وإلا فإن مشروعك سيفشل وستدفع من جيبك لتعويض نقص الميزانية، ركز دائما على مرحلة التخطيط لأنها أول مرحلة فإن وضعتها بشكل سليم سلم مشروعك من الفشل، وهنا أستحضر مقولة بنيامين فرانكلين وهو فيلسوف أمريكي: إذا فشلت في التخطيط فقد خططت للفشل If you fail to plan, you are planning to fail)

3. متطلبات النظام تم تحديدها بشكل سيء (تأكد جيدا أنك لو أرسلت نفس العميل إلى مجموعة من المؤسسات البرمجية، فكل واحدة ستقوم بكتابة المتطلبات بشكل مختلف عن نظيراتها، إذن فالعملية تستلزم الدقة والتركيز في كل كلام العميل وصياغته بشكل يتلاءم مع طبيعة المشاريع البرمجية، كما يجب عليك أن تقدم اقتراحات للعميل لتحسين النظام، وإعطاء بديل لأهدافه الخيالية التي لا يمكن إنجازها برمجيا، بمعنى لو قال لك: أريد من البرنامج أن يقرأ الوثائق الورقية بواسطة الطابعة، تقول له: الطابعة دورها هو إخراج الوثائق فقط، لكن يمكننا قراءة الوثائق الورقية عبر جهاز الماسح الضوئي Scanner)
في هذه المرحلة ستحتاج إلى تصميم بعض النماذج من نوع Use case إن كنت تستخدم لغة UML، من أجل تحديد المهام  Actions التي يتيحها النظام ومن هم الفاعلون Actors الذين يقومون بها.)

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

5. عدم الأخذ بعين الاعتبار تعقيدات النظام System Complexity (عليك تحديد صعوبة النظام الذي تود إنجازه، ماهي الأجزاء الصعبة في هذا النظام؟ كيف سأقوم بإنجازها؟ وكيف يمكنني إصلاحها إن أخطأت في إنجازها؟ مع العلم أن تصحيح الكود أصعب من كتابته، ومن العبارات الشهيرة في مجال دراسة تعقيدات الأنظمة "قراءة الكود أصعب من كتابته  It’s harder to read code than write it.
تعقيدات النظام أو صعوبة النظام من المواد الأساسية في هندسة البرمجية والتي تعنى بحساب ودراسة درجة صعوبة النظام، لكي نعرف النظام بشكل عميق، وتشمل تعقيدات النظام الجانب المادي للبرنامج بمعنى كم هي حاجة البرنامج إلى الموارد المادية مثلا: ماهو حجم الذاكرة الذي يتطلبه البرنامج ليشتغل؟ وتشمل تعقيدات النظام كذلك الجانب البشري بمعنى كم هي الموارد البشرية التي سيحتاجها البانرمج، مثلا: عدد المبرمجين، عدد الأفراد الذين سيجرون الاختبار على البرنامج.
لذلك يهتم المهندسون البرمجيون بحساب وقياس تعقيدات النظام، لأنه بحساب كل عملية ننفي احتماليات الخطأ والشك، التعقيدات تحسب، الجودة تحسب، إعادة الاستخدام تحسب، كل عملية من عمليات هندسة البرمجيات تحسب.
وأذكر هنا مقولة الفيزيائي البريطاني ذي الأصول الايرلندية ويليام تومسون الشهير باللورد كيلڤان إذ يقول:
حينما تستطيع حساب ماتتكلم عنه والتعبير عنه بالأرقام، يمكنك معرفة بعض الأشياء حوله، لكن إن لم تستطع حساب ماتتكلم عنه والتعبير عنه بالأرقام، فمعرفتك به فقيرة جدا وغير كافية
Quand  vous  pouvez  mesurer  ce  dont  vous  parlez  et  l’exprimez  en  nombres,  vous pouvez  savoir  quelque  chose  à  ce  sujet;  mais  quand  vous  ne  pouvez  pas  le  mesurer  et l'exprimer  en  nombres,  votre  connaissance  est  en  quelque  sorte  pauvre  et insuffisante.  « William Thomson connu sous le nom Lord Kelvin »   
6. ضعف التواصل بين العملاء والمطورين والمستخدمين النهائيين (على المبرمجين الذين يشتغلون على نفس المشروع أن يكونوا على تواصل فيما بينهم، ليوضحوا المهام لبعضهم البعض، حتى لا يكرر أحدهم عمل الآخر، أو يظن أحدهم أن جزئية ما تدخل في تكليفات مبرمج آخر.
أيضا ينبغي أن يكون هنالك تواصل مع العميل ومع مستخدمي النظام خاصة في مرحلة جمع المتطلبات من أجل بناء نظام يناسبهم ويلبي رغباتهم.)

7. استخدام تكنولوجيا لا تفي بالغرض (لغة برمجية لا تلبي الغرض، أجهزة موصولة بالنظام لا تشتغل بكفاءة جيدة...)

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

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

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

11. اختبارات النظام غير جيدة

12. نقص الجودة

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


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

1. ينبغي أن يشمل المشروع جميع الوظائف والمهام التي اقترحها العميل
2. ينبغي الأخذ بعين الاعتبار جودة المشروع
3. ينبغي احترام التكلفة المالية التي تم تحديدها قبل خوض غمار المشروع
4. ينبغي احترام المدة الزمنية التي تم الاتفاق عليها

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


ظهرت هندسة البرمجيات في سبعينيات القرن المنصرم 1970 من أجل حل أزمة البرمجيات Software Crisis / La Crise du Logiciel، حيث عرفت عملية تطوير البرمجيات مشاكل جوهرية متمثلة في عدم احترام مواعيد التسليم، وعدم احترام الميزانية المخصصة للمشاريع، وأن هاته المشاريع لا تفي بالغرض ولا تلبي احتياجات العميل، إضافة إلى أنها تكون صعبة الاستخدام وصعبة الصيانة والتصحيح، فضلا عن إمكانية إعادة تطويرها وتحسينها.
دائما في إطار مشاكل البرمجيات لنتمعن في هذا الرسم البياني الذي يعرض نسبة نجاح المشاريع في وزارة الدفاع الأمريكية:


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


  •  تلبية حاجيات العميل meeting user’s needs،
  •  تكلفة إنتاج منخفضة low cost of production،
  •  كفاءة عالية high performance،
  •  قابلية النقل والاشتغال من جهاز إلى جهاز آخر portability،
  •  تكلفة إصلاح منخفضة low cost of maintenance،
  •  جودة عالية مما يضمن الاتكالية والاعتماد على النظام reliability،
  •  احترام موعد التسليم delivery on time.
يمكننا اعتبار كل هدف من الأهداف السابقة إكراها وتحديا في عملية صناعة البرمجيات، وغياب عنصر من تلكم العناصر قد يفضي إلى إفشال المشروع، مثلا عدم تلبية حاجيات ومتطلبات العميل=برنامج فاشل، عدم احترام الوقت أو الميزانية=برنامج فاشل، غياب الجودة أو احتواء البرنامج على أخطاء=برنامج فاشل...إلخ.

دورة حياة تطوير النظم SDLC


حينما نتحدث عن دورة حياة البرامج System Development Life Cycle، قد يتبادر إلى أذهاننا
أول وهلة أن الأمر يتعلق بإنشاء أول ملف من ملفات البرنامج وتنتهي هذه الدورة عند حذف
آخر ملف من ملفات البرنامج، وهذا ليس صحيحا لأن المقصود بدورة حياة البرامج أو دورة حياة
النظم هو بداية طلب النظام من طرف المستخدم وانتهاء بتسليمه إياه.
حينما نقول العميل Customer / Client أو المستخدم User / Utilisateur فنحن نتحدث عن نفس الفاعل الذي سيستفيد من خدمات النظام، حتى وإن كان العميل Customer غالبا ما يشير إلى الشخص الذي سيدفع تكلفة النظام / ممول النظام، ومصطلح المستخدم يشير إلى الشخص الذي سيستعمل النظام / مستخدم النظام، إلا أنه في هندسة البرمجيات يتم اعتبارهما واحدا في الغالب الأعم لذلك ستجد في المواد الإنجليزية يتم التعبير عنهما بنفس المسمى StackeHolder.
تمر عملية صناعة البرمجيات من مجموعة من المراحل التي تعرف بدورة حياة النظم البرمجية Sytem Development Life Cycle، والمتمثلة فيما يلي:

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

2. التحليل Analysis / Analyse: خلال هذه المرحلة ينبغي أن نعرف من الذي سيستخدم هذا النظام، ومتى يمكن لكل مستخدم أن يستخدم النظام، وأين يستطيع كل مستخدم أن يتعامل مع النظام حسب طبيعته، في هذه المرحلة علينا جمع المعلومات بدقة وتحديد المهام والمتطلبات بناء على دراسة الجدوى التي حصلنا عليها في مرحلة التخطيط.

3. التصميم Design / Conception: خلال هذه المرحلة يتم تصميم النظام بمختلف مكوناته، من واجهات وملفات وقواعد بيانات، والتصميم ليس مقتصرا على الشاشات والواجهات الرسومية GUI،  وإنما يعني كذلك التصميم العملي والوظيفي Functional Design، بمعنى تصميم طرق التعامل مع البرنامج واختيار أفضل السبل لإنجازه بالشكل المطلوب وبجودة عالية، إذن فالتصميم يجمع بين الشكل والوظيفة Appearance and functionality.
يلعب التصميم في عملية صناعة البرمجيات نفس الدور الذي يلعبه في مجالات أخرى، فكما أن الميكانيكي لا يستطيع تجميع قطع غيار سيارة لم يسبق له أن تعامل معها إلا من خلال دليل تجميع، وكما أن صاحب محل صيانة الحواسيب لا يستطيع تركيب جهاز جديد عليه دون دليل تجميع، فكذلك شأن إنشاء برنامج دون العبور من مرحلة التصميم، فالتصميم هو ذلك التصور الذي سيقودك إلى بناء برنامج يلبي حاجيات العميل، فإن أتيت وبدأت بكتابة الكود مباشرة فذلك أشبه بشكل كبير بتجميع قطع لعبة Puzzle لم تشاهد صورتها الأصلية فنسبة الفشل إذن كبيرة جدا.
أيضا خلال هذه المرحلة، يفضل تقسيم النظام إلى أنظمة جزئية Sub-Systems لكي يتم تقسيم المشاكل الرئيسية إلى مشاكل فرعية sub-problems ليسهل حلها، لأن التعامل مع مشاكل صغيرة أهون من التعامل مع المشاكل الكبيرة، فلكي نتمكن من تجاوز المشاكل المعقدة نقوم بتفكيكها وتفتيتها.


4. الترميز Coding / Codage: يتوجب علينا في هذه المرحلة صياغة الحلول والنماذج والمخططات التي حصلنا عليها في مرحلة التصميم Design بشكل برمجي، عبر الاعتماد على إحدى لغات البرمجة المرنة التي بإمكانها أن تسع كل ما تم تسجيله من متطلبات وأغراض.
في غضون مرحلة الترميز
Coding يتم القيام بمجموعة من الاختبارات الوحدوية التي تعنى بكل وحدة على حدة بحيث يتم اختبار كل وظيفة Function وكل فئة Class وكل مكون Component ليتم التحقق من صحة الشفرات المكتوبة، ويسمى هذا النوع من الاختبارات ب: الاختيارات الوحدوية Les tests unitaires / unit testing


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

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

الخاتمة

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





هناك 4 تعليقات:

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

    ردحذف
  2. شكرا لك اخي خالد وبارك الله فيك ونتمنى ان تزيدنا علما منك في عالم البرمجيات وخاصة ببناء مشاريع كاملة مثل ecommerce باي لغة برمجية وشكرا

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

    ردحذف
  4. شكرا جزيلا لك يا استاذ خالد
    وجزاك الله الف خير

    ردحذف