السلام عليكم ورحمة الله وبركاته
اخواني الاعزاء عساكم طيبين
هل عندكم خبرة في كيفية اختيار نموذج اجرائية البرمجية (software process model)
للعلم ان المشروع هو (موقع مزاد الكتروني)
اي ما هو النموذج الصحيح الذي نستخدمة في دورة حياة النظام هل نستخدم
نموذج الشلال
ام النموذج الحلزوني

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

وعليكم السلام ورحمة الله

يمكنك اختيار نموذج ال UML Unified Modeling Language


وتوجد مواضيع ومشاركات فى المنتدى عن استخدامات ال UML

------------
الفرق بين النموذجين

إن موضوع التحليل والتصميم بالكائنات من أهم المواضيع الني ينبغي لأي مبرمج أو مطور يستخدم لغه كائنيه أن يجيده ، حيث على (المحلل) المبرمج أن يقوم بتحليل النظام أولا ويعرف ما هي المشكله التي يريد أن يحللها Analysis ومن ثم يبدأ هذا (المحلل) المبرمج بطرح الحلول وكيف يمكن أن تتفاعل هذه الكائنات مع بعضها البعض design ، ومن ثم يقوم المبرمج بعمليه الCoding ويقوم بتطبيق التصميم الذي طرحه في المرحله السابقه ، وأخيرا يقوم باجراء الTesting للبرنامج والتأكد من مطابقته لمتطلبات الزبون Customer Requirement .

العمليات السابقه التي ذكرتها (Analysis,Design,Coding,Testing) تعرف بدوره حياه المشروع Software Development Life Cycle . وبالطبع أي مشروع يجب أن يمر على جميع هذه المراحل بترتيب معين حيث أن عمليه التطوير يجب تكون على منهجيه معينه وباتباع طريقه ما Methodology والا ستعم الفوضي ولن تستطيع حتى كتابه سطر واحد صحيح من البرنامج .

باتباع هذه المهجيات سوف تضمن أن عمليه تطويرك للبرنامج تسير في المنحنى الصحيح ، كما أنها توفر لك كل ما تحتاجه من وقت البدء في تحليل المشروع الى وقت التسليم والصيانه للمشروع ، اضافه الى توضيح نوعيه الوثائق والمخططات التي ستنتجها كل مرحله Activities & Artifacts وليس هذا فقط فهناك منهجيات توفر لك نصائح وارشادات في عمليه جدوله المشروع واداره الفريق وما الى ذلك من العمليات الإداريه Management Task .

قديما كانت تجري هذه العمليات SDLC بالترتيب وبشكل متنازل وهو ما يعرف بنموذج الشلال Waterfall Model .. حيث يقوم أولا المحلل بتحليل البرنامج بالكامل وكتابه جميع الوثائق المطلوبه ومن ثم يمرر هذه الوثائق للمصمم الذي يقوم بتصميم النظام ووضع حلوله أيضا ، ومن ثم تمر بالمبرمج الذي يقوم بكتابه الكود وعندما ينتهي تجرى الأختبارات على هذا البرنامج وأخيرا يسلم الى الزبون ..


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

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

ناهيك عن الوقت المستغرق في كل مرحله ، حيث لأنها يجب أن تكون كامله وشامله يبدأ الخوف لدي المحللين فيأخذوا وقت أكثر من المفترض أن يكون به ويبدأ في ذكر "يبدوا أن هناك شيء ناقص ، سنعيد تحليل هذه النقطه" ، "يجب أن نراجع التحليل مره أخرى ، حيث اذا حدثت مشكله الأن سوف تبقى على اكتافنا" وهكذا يصاب المحلل ب Analysis Paralysis ، بنفس الأمر عند المصمم والمبرمج والشخص الذي يقوم بالأختبار كل منهم يصاب بهذه العقده خاصه ان كان قد فشل في مشروع سابق .

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

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

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

منقول

وعليكم السلام ورحمة الله

يمكنك اختيار نموذج ال UML Unified Modeling Language


وتوجد مواضيع ومشاركات فى المنتدى عن استخدامات ال UML

------------
الفرق بين النموذجين

إن موضوع التحليل والتصميم بالكائنات من أهم المواضيع الني ينبغي لأي مبرمج أو مطور يستخدم لغه كائنيه أن يجيده ، حيث على (المحلل) المبرمج أن يقوم بتحليل النظام أولا ويعرف ما هي المشكله التي يريد أن يحللها Analysis ومن ثم يبدأ هذا (المحلل) المبرمج بطرح الحلول وكيف يمكن أن تتفاعل هذه الكائنات مع بعضها البعض design ، ومن ثم يقوم المبرمج بعمليه الCoding ويقوم بتطبيق التصميم الذي طرحه في المرحله السابقه ، وأخيرا يقوم باجراء الTesting للبرنامج والتأكد من مطابقته لمتطلبات الزبون Customer Requirement .

العمليات السابقه التي ذكرتها (Analysis,Design,Coding,Testing) تعرف بدوره حياه المشروع Software Development Life Cycle . وبالطبع أي مشروع يجب أن يمر على جميع هذه المراحل بترتيب معين حيث أن عمليه التطوير يجب تكون على منهجيه معينه وباتباع طريقه ما Methodology والا ستعم الفوضي ولن تستطيع حتى كتابه سطر واحد صحيح من البرنامج .

باتباع هذه المهجيات سوف تضمن أن عمليه تطويرك للبرنامج تسير في المنحنى الصحيح ، كما أنها توفر لك كل ما تحتاجه من وقت البدء في تحليل المشروع الى وقت التسليم والصيانه للمشروع ، اضافه الى توضيح نوعيه الوثائق والمخططات التي ستنتجها كل مرحله Activities & Artifacts وليس هذا فقط فهناك منهجيات توفر لك نصائح وارشادات في عمليه جدوله المشروع واداره الفريق وما الى ذلك من العمليات الإداريه Management Task .

قديما كانت تجري هذه العمليات SDLC بالترتيب وبشكل متنازل وهو ما يعرف بنموذج الشلال Waterfall Model .. حيث يقوم أولا المحلل بتحليل البرنامج بالكامل وكتابه جميع الوثائق المطلوبه ومن ثم يمرر هذه الوثائق للمصمم الذي يقوم بتصميم النظام ووضع حلوله أيضا ، ومن ثم تمر بالمبرمج الذي يقوم بكتابه الكود وعندما ينتهي تجرى الأختبارات على هذا البرنامج وأخيرا يسلم الى الزبون ..


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

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

ناهيك عن الوقت المستغرق في كل مرحله ، حيث لأنها يجب أن تكون كامله وشامله يبدأ الخوف لدي المحللين فيأخذوا وقت أكثر من المفترض أن يكون به ويبدأ في ذكر "يبدوا أن هناك شيء ناقص ، سنعيد تحليل هذه النقطه" ، "يجب أن نراجع التحليل مره أخرى ، حيث اذا حدثت مشكله الأن سوف تبقى على اكتافنا" وهكذا يصاب المحلل ب Analysis Paralysis ، بنفس الأمر عند المصمم والمبرمج والشخص الذي يقوم بالأختبار كل منهم يصاب بهذه العقده خاصه ان كان قد فشل في مشروع سابق .

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

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

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

منقول

اخي امجد شكرا لك الف شكر
غمرتنا بلطفك
شكرا وان شاء الله سنعمل بكلامك
دعواتك اخي الكريم

اخي العزيز

بداية بالتوفيق في نظامك الجديد
وانا اعمل على نظام لمزاد السيارات ان احتجت لأي استشارة فأنا حاضر

وبالتوفيق مرة اخرى