حسنا انتهينا في المرة الماضية الي الأسباب التي أدت إلى ظهور هندسة البرمجيات، وقد دردشنا حول أشهر نموذج يتم استخدامه في العمل ألا وهو نموذج الشلال
سنتكلم اليوم عن شيء يسمى Software methodology
وهي بالمختصر المفيد أساليب وإجراءات متبعة في انشاء البرمجيات، هذه الأساليب تختلف في مجموعة نقاط أثناء العمل، فقام المهندسون بإنشاء أنواع متعددة ولها قواعد محدد.
ويدخل في الأساليب مجموعة مواضيع يتم تحديدها مثل طريقة التخطيط وطريقة كتابة المتطلبات وكذلك طريقة إدارة المشروع تقسيمه ونشره وصيانته…. الخ
الهدف النهائي هو أن المشروع يدخل كفكرة …… ويخرج من الجهة الاخرى كمنتج جاهز للاستخدام.
ما حصل فعليا في النقاط بين البداية والنهاية هي الطريقة المتبعة لاخراج المشروع وهي من مهمة software methodology، وسنحاول أن نستعرض بعض هذه المنهجيات.
اثناء سير البرنامج من بدايته الى نهايته يمر في عدة مراحل كما اتفقنا، هذه العملية تسمى دورة حياة المشروع software life cycle
في دورة حياة المشروع هنالك مجموعة عمليات وأنشطة وفعاليات ومهام تقسم وتوزع، طريقة سير هذه المهام تسمى نموذج model
حتى لا يختلط عليك الموضوع، نبسط الفكرة، لنضرب مثال، أتى مدير مستشفى الشفاء إلى شركتك الموقرة وطلب منك إنشاء نظام متكامل لمستشفاهم، وفي موقع آخر كلمك أخاك الصغير وقال لك أريد أن تعمل لي برنامج صغير يفحص هل الرقم المدخل فيه رقم أولى أو لا.
الآن حينما تبدأ بالعمل على كلا المشروعين ، لن تقوم بعمل نظام المستشفى بنفس آلية تطبيق أخاك الصغير.
نظام المستشفى كبير، يجب دراسته وكتابة متطلباته ، وفحص المتطلبات، وآخذ أراء من يعمل بالمستشفى من أطباء وممرضين لكي يناسبهم النظام، كذلك قد تضطر لإنشاء كل جزء في المستشفى على حدة، مثلا فصل قسم المستودع بشكل كامل وتسليمه ومن ثم الانتقال إلى جزء آخر، طريقة إدارة الفريق، وطريقة إدارة المشروع، ستختلف بالتأكيد عن موضوع إنشاء برنامج صغير لأخيك، الطرق المختلفة في اختيار الفريق وفي كتابة متطلبات النظام، وفي إدارة المشروع وفي اختيار مهارات الفريق، وفي فحص كل جزئية من النظام، هذه تسمى منهجية إنشاء البرنامج، وهنالك عدة منهجيات كتبها مهندسوا البرمجيات ، سنستعرضها لكم.
منطقيا أول نموذج استخدمه البشر او المبرمجون هو نموذج اللا نموذج، أي العمل بدون وجود نموذج، وهو ما يمكن أن نطلق عليه نموذج ابني وصلح او كوّد وصلح build and fix , code and fix
وحين الحديث عن هذا النموذج حيث لا طريقة علمية مستخدمة فمن البديهي ان تكون مزاياه أنه يمكنك العمل مباشرة، ولا تحتاج الى تخطيط، لا يحتاج إلى تدريب أو دورات خاصة، كذلك لا تحتاج إلى قواعد للسير عليها، أنت المدير وأنت المحلل، وأنت المبرمج، وأنت مختبر النظام، ولكن حين الحديث عن عيوب هذا المنهج، فحدث ولا حرج، سأقول بعضها، وأترك لكم الباقي، صعوبة صيانة النظام، وصعوبة تطويره مستقبلا، صعوبة فهم النظام من قبل مبرمج آخر إذا أردت أن تسلمه المشروع…. إلخ.
ثم هنالك النموذج الثاني والأشهر من نار على علم، وهو نموذج الشلال waterfall، وقد تكلمنا عنه مسبقا.
نموذج الشلال مفيد في حالة كان لديك مخطط تفصيلي لكل أجزءا النظام ومدروسة بعناية، يمكنك بعدها البدء في تحليل النظام وبعدها تصميم النظام، ثم برمجته، وأخيرا صيانته، هذا النظام في العمل له مزايا كثيرة منها سهولة فهمه ، سهولة إدارته، سهولة تتبع خطواته، ولا يحتاج إلى تدريب.
ولكن له عيوب كثيرة ، منها أنه يجب عليك أن تكون تعلم كل أجزاء النظام كاملة ( وهذا لا يحدث غالبا ) ، يجب الإنتهاء من كل مرحلة على حدة، فلو كان لديك 4 مبرمجين، عليهم الانتظار لحين الإنتهاء من الدراسة والتحليل والتصميم، وهكذا، ولو مرت فترة 4 شهور، وطلب العميل منك ان تريه العمل، فإنه ستريه شيء مثل مستند التصميم الذي ستعمل عليه، وهذا بالتأكيد لن يرضي الزبون ، الزبون يريد رؤية شيء حقيقي، ولا يفقه في مصطلحاتك وتفسيراتك، وأهم نقطة هو استحالة عمل فحص للنظام إلا بعد انتهائه.
لعل الصورة ما زالت مشوشة لديك ولكن في المرات التالية ستتضح الصورة أكثر إن شاء الله
