[احمد عز الدين على الطاهر]

السلام عليكم ورحمة الله تعالى وبركاته اخوتى أسال من شئ فى غير مواضيع المكتبات وأريد حلا سريع وهو ماهى لغة الumlأو ماهى لغة النمزجه الموحده أو دلونى على ومقع به قال عن ذللكاحمد

[العنقود]

وعليكم السلام والرحمةهلا فيك اخوي احمداريد ان افيدك بما عندي والله اعلم واتمنى ان اكون افتدك بما لديقبل أن نخوض في نظرية UML ، سنقوم بجولة مختصرة للإطلاع على بعض المفاهيم الأساسية ل UML.أوّل ما يتم ملاحظته عن UML هو أنه يوجد العديد من المخطّطات المختلفة (نماذج) و التي يجب التعوّد عليها. السبب في هذا التنوّع يعود ألى ان المنظومة يُحتمل أن يُنظر اليها من زوايا مختلفة بحسب المشاركين فيها . تطوير البرمجيات يشترك فيه عدد من الأفراد، و كل واحد له دور - مثلا:المحلّلون المصمّمون المبرمجون القائمون بالاختبار مراقبو الجوة المستفيدون الكتّاب التقنيونكلّ هؤلاء الأفراد يهتمون بجوانب مختلفة من المنظومة، و كلّ واحد منهم يحتاج الى مستوى مختلف من التفاصيل. على سبيل المثال، المبرمج يحتاج الى ان يفهم التصميم الموضوع للمنظومة من أجل تحويله الى تعليمات برمجية في مستواها الأدني. بالمقابل الكاتب التقني (الموثّق) ينصبّ اهتمامه في سلوك المنظومة ككلّ، فيحتاج لفهم كيف يعمل المنتوج. تحاول UML أن تقدّم لغة قويّة التعبير بحيث يمكن للمشاركين الإستفادة و لو من مخطط واحد على الأقل من مخططات UML.حالة الاستخدام Use Case هي وصف لسلوك النظام من وجهة نظر المستخدم. فهي ذات فائدة خلال مراحل التحليل و التطوير، و تساعد في فهم المتطلبات. يكون المخطط سهلا للاستيعاب. مما يمكّن كلا من المطوّرين (محلّلون، مصمّمون، مبرمجون، مختبرون) و المستفيدون (الزبون) من الاشتغال عليه. لكن هذه السهولة يجب أن لا تجعلنا ننقص من شأن مخططات حالة الاستخدام. فهي بامكانها أن تحتمل كامل عمليات التطوير ، بدءا من الاستهلال و حتى التسليمرسم مخططات الأصناف جانب أساسي لأي منهج للتصميم بالمنحى للكائن، لذلك ليس بالغريب أن تقدّم لنا UML الصيغة المناسبة له. سوف نرى أنه بامكاننا استخدام مخطط الأصناف في مرحلة التحليل و كذلك في مرحلة التصميم - سوف نقوم باستعمال صيغ مخططات الأصناف لرسم خريطة للمفاهيم العامة التي يمكن للمستفيد = الزبون أن يستوعبها (و سوف نسمّيها النموذج المفاهيمي Conceptual Model). وهي بالاضافة الى مخطط حالة الاستخدام، تجعل من النموذج المفاهيمي أداة قوية لتحليل المتطلبات. نحن نقوم بتطوير برامج المنحى الكائني، أي شيء يحتاجه برنامجنا لأن يقوم به فسيكون بواسطة تعاون الكائنات. يمكننا رسم مخططات التعاون لوصف كيف نريد للكائنات التي نبنيها أن تتعاون مع بعض.هنا مثال جيد عن لماذا UML هي مجرد صيغة أكثر من كونها عملية حقيقية لتطوير البرمجيات. سوف نرى أن ترميز UML للمخطط بسيط جدا، و لكن تصميم تعاون فعّال، (لنقل "تصميم برنامج راسخ و يسهل صيانتة") ، يعدّ صعبا بالتأكيد. ربما علينا تخصيص فصلا بكامله يتناول الخطوط العريضة لمبادئ التصميم الجيّد، مع أن الكثير من مهارات التصميم تأتي من الخبرة.مخطط التتابع في في حقيقته له علاقة مباشرة بمخطط التعاون و يقوم بعرض نفس المعلومات، و لكن بشكل يختلف قليلا. الخطوط المنقطة إلى أسفل المخطط تشير إلى الزمن، لذلك فما نشاهده هنا هو وصف لكيفية تفاعل الكائنات في نظامنا عبر الزمن. بعض أدواة نمذجة UML ، مثل برنامح ناشيونال روز Rational Rose، يمكنها توليد مخطط التتبابع آليا من مخطط التعاون، أحيانا، يكون تعاقب التحوّلات بين الحالات معقّد جدا - في المثال أعلاه ، لا يمكننا أن ننتقل من حالة "خضراء" إلى حالة "حمراء" (و إلا تسبّبنا في حادث!).و برغم أن الإشارة الضوئية قد تبدو مثالا بسيطا، إلا أن التهاون في التعامل مع الحالات يمكن أن يؤدّي الى وقوع أعطال جدية و محرجة في برامجنا.خذ مثلا - فاتورة غاز مرسلة الى مستهلك توفّي منذ أربع سنوات - هذا يحدث في الواقع و سبب ذلك أن المبرمج في نقطة ما لم يأخذ في اعتباره تحوّلات الحالة.و كما يمكن لتحوّلات الحالة أن تكون معقّدة، فإن UML تقدّم صيغة تسمح لنا بتصويرها و نمذجتها.يوفّر UML عدة نماذج مختلفة لوصف النظام. القائمة التالية تعرضها كلها مع جملة واحدة توجز الغرض من كل نموذج:Use Casesوقائع الاستخدام - "كيف سيتفاعل نظامنا مع العالم الخارجي؟" Class Diagramمخطط الأصناف - "ما هي الكائنات التي نحتاجها؟ و ما علاقتها؟" Collaboration Diagramمخطط التعاون - "كيف تتعامل الكائنات مع بعض؟" Sequence Diagram مخطط التتابع - "كيف تتعامل الكائنات مع بعض؟" State Diagram مخطط الحالة - "ما الحالات التي يجب أن تكون عليها الكائنات؟" Package Diagramمخطط التحزيم - "كيف سنقوم بقولبة عملنا؟" Component Diagram مخطط المكونات - "كيف سترتبط مكونات برنامجنا؟" Deployment Diagramمخطط التجهيز - "كيف سيتم تجهيز البرنامج؟ اصبحت UML (لغة النمذجة الموحّدة) اللغة المعتمدة لترميز العمليات البرمجية لدى الوسط الصناعي. و بالرغم من انها خرجت من تحت عباءة ثلاثة يعدون من أهم أصحاب المنهجيات؛ الا انها لقت قبولا واسعا لدي المهتمين ببناء البرمجيات على اختلاف مشاربهم و منهجياتهم.هي تقدم وسيلة رموزية مبسطة للتعبير عن مختلف نماذج العمل البرمجي يسهل بواسطتها على ذوي العلاقة - من محللين و مصممين و مبرمجين بل و حتى المستفيدين - التخاطب فيما بينهم و تمرير المعلومات في صيغة نمطية موحدة و موجزة، تغنيهم عن الوصف اللغوي المعتاد. انها مثل مخططات البناء التي يتبادلها المساحون والمعماريون و مهندسو التشييد، أو مخططات الدوائر الكهربائية و الالكترونية التي يمكن لأي كان في هذا المجال أن يفهمها و يتعامل معها.هنا يجب التنويه الى بعض النقاط التي تشكل سوء فهم ارتبط ب UML لدى الكثيرين:UML ليست منهجية لبناء البرمجيات. بمعنى انها لن ترشدك الى افضل الطرق لتصميم البرمجيات و تطويرها.UML لا ترتبط بمنهجية محددة لتنشئة البرمجيات. بالرغم من أنها تولّدت من منهجيات سابقة و بالرغم من انها متوافقة و متممة لمنهجية: العملية الموحدة RUP التي صاغها نفس الافراد الذين قاموا بوضع UML. هذه اللغة يمكن توظيفها على مختلف العمليات البرمجية بغض النظر عن المنهجية المتبعة و بل بغض النظر عن وجود منهجية اصلا.لقد قمت بترجمة هذه النصوص ليس فقط لأنها تشرح عناصر UML ؛ و لكن ايضا لأن هذه الدروس تضع عناصر UML ضمن سياقها داخل مختلف العمليات في منهجية واحدة لتطوير البرمجيات. غير هذا فانها تتعرض بالشرح لكثير من المفاهيم السائدة في الوسط البرمجي مثل المنحى للكائن Object Orientation و التوريث و أنماط التصميم Design Patterns , و المرتكز المعماري للتنشئة Architecture-Centric Development كلها ضمن مسار واحد داخل الدورة الحياتية للمشروع البرمجي.أيضا أود أن أشير الى ان هذه الدروس تبنّت منهجية العملية الموحّدة من راشيونال RUP ، احدى اهم المنهجيات "الثقيلة". و بالرغم من عدم ميلي شخصيا لهذه المنهجية ، و تفضيلي لإحدى المنهجيات الأقلّ وزنا ، الا اني اجدها فرصة للتعرّف عن قرب على كيفيّة تنشئة البرامج ضمن منهجية معينة. اتخذ الأصدقاء الثلاثة قرارا واضحا جدا بعدم تضمين اللغة أية قضايا تتعلق بالعمليات process. ذلك لأن العمليات تثير الكثير من الجدل - فما يسري على شركة ما قد يشكل كارثة بالنسبة لشركة أخرى. فشركة مختصة بمجالات الدفاع تتطلب عمليات توثيق و جودة و اختبارات أعقد بكثير من شركة مختصة بالتجارة الإلكترونية. لذلك فإن لغة UML عمومية، لغة عامة تسمح بالتقاط المفاهيم الأساسية لتطوير البرمجيات و وضعها على "ورقة".بعبارة أخرى، UML هي ببساطة لغة أو أداة ترميز أو قواعد نحوية ، سمّها ما شئت. المهم، أنها لن ترشدك الى كيف يتم تطوير البرمجيات. لكي تتعلم كيفية استخدام UML بكفاءة، سوف نتعامل مع عملية process مبسّطة خلال الدروس القادمة، و نحاول فهم كيف تساعدنا UML في كل مرحلة. و كبداية، لنلقى نظرة أولا على بعض العمليات البرمجية الشائعة.النموذج الإنحداري Waterfall Modelبحسب النموذج الانحداري كل مرحلة يجب إنهائها قبل الشروع في المرحلة التي تليها.هذه العملية المبسطة (و التي يسهل ادارتها) تبدأ بالتداعي بمجرد أن يزداد تعقيد و حجم المشروع. أهم مشاكلها هي:حتى الأنظمة الضخمة يجب أن تكون مفهومة و سبق تحليلها بالكامل قبل مباشرة مرحلة التصميم. فيزداد بهذا التعقيد و يصبح عبئا على المطوّرين.المخاطر Risk تتجمع لاحقا. المشاكل عادة ما تظهر في المراحل الأخيرة من العملية - خاصة خلال التحام النظام. و للأسف، تزداد تكلفة تصحيح الأخطاء بصورة مضاعفة مع مرور الزمن.في المشاريع الكبيرة، كل مرحلة تستغرق فترات طويلة مبالغ فيها. مرحلة اختبار بطول سنتين ليست بالتأكيد وصفة جيدة لشحن ذاكرة العمل تتزايد المخاطر وتكلفة تصحيح الأخطاء مع مرور الزمن.أيضا، حيث أن مرحلة التحليل تنجز في مخاض قصير مع تدشين المشروع، سنواجه مخاطرة جدية تتمثل في القصور في فهم متطلبات الزبون. حتى لو التزمنا باجراءات صارمة لادارة المتطلبات و قمنا بصياغتها تعاقديا مع الزبون. هناك دائما احتمال بأنه مع استكمال التوليف coding و الدمج integration و الاختبار لن يكون المنتج النهائي بالضرورة هو ما يتوقعه الزبون.برغم كل ما ذكرنا، لا يوجد عيب في النموذج الانحداري، بشرط أن يكون المشروع صغيرا بما يكفي. صحيح ان تعريف "صغير بما يكفي" قابل للنقاش، و لكنه أساسي، فإذا أمكن لمشروع أن يتصدى له فريق صغير من الأفراد، كل فرد على دراية بجميع جوانب المشروع، و إذا كانت فترة المشروع قصيرة (بضعة أشهر)، عندها يكون النموذج الانحداري عملية لها قيمتها. فهو أفضل بكثير من الخبط العشوائي!بايجاز، النموذج الانحداري سهل الفهم و بسيط في ادارته. لكن مميزات هذا النموذج تبدأ في التداعي بمجرد أن يزداد تعقيد المشروع.النموذج اللولبيالاسلوب البديل هو النموذج اللولبي، حيث نقوم بالتصدّي للمشروع عن طريق تقسيمة إلى سلسلة من الدورات الحياتية lifecycles القصيرة ، كل دورة تنتهي باصدار لبرنامج قابل للتنفيذ.العملية اللولبية، هنا يتم تقسيم المشروع إلى خمسة أطوار، كل طور يُبنى فوق سابقه، و كل طور ينتهي بانتاج اصدارة لبرنامج جاهز للتشغيل.مع هذا الاسلوب:يستطيع فريق العمل أن يشتغل على كامل الدورة الحياتية (تحليل، تصميم، توليف Code، اختبار) بدلا من صرف سنوات على نشاط واحد.يمكننا الحصول على ملاحظات وتقييم الزبون مبكرا و بصورة منتظمة، ورصد الصعوبات المحتملة قبل التمادي بعيدا في عمليات التطوير.يمكننا التصدّي لنقاط المخاطرة مقدما، بالأخص التكرارات ذات المجازفة العالية (مثلا: التكرار الذي يتطلب تنفيذ بعض التقنيات الجديدة غير المجرّبة) يمكن تطويرها أولا.يمكن اكتشاف مدى حجم و تعقيد العمل مبكرا.الاصدار المنتظم للبرنامج يعزّز من الثقة.الوضع الحالي للمشروع (مثل: مقدار ماتم انجازه) يمكن تحديده بدقة أكبر.عيوب العملية اللولبية هي:عادة ما ترتبط هذه العملية بما يعرف بالتنشئة السريعة للتطبيقات Rapid Application Development ، و التي تعتبر من قبل كثيرين مجرد hacker's charter.العملية أكثر صعوبة في إدارتها. في النموذج الانحداري يمكن الاستعانة بالتقنيات التقليدية لإدارة المشروعات مثل مخططات كانط Gantt، لكن العمليات اللولبية تتطلب أساليب مختلفة.من أجل تدارك عيوب العملية اللولبية، لنلقي نظرة على أسلوب مشابه لكن أكثر تقنينا و يدعى اطار العمل التكراري التزايدي Itrative, Incremental Framework.اطار العمل التكراري التزايدياطار العمل التكراري التزايدي Itreative, Incremental Framework هو امتداد منطقي للنموذج اللولبي، لكنه أكثر تقنينا و صرامة. سوف نقوم بتبنّي اطار العمل التكراري التزايدي خلال بقية هذه الدروس.ينقسم اطار العمل الى أربعة أطوار رئيسية: الاستهلال Inception، التفصيل Elaboration، البناء Construction و التنقل Transition. يتم انجاز هذه الأطوار على التوالي، لكن يجب أن لا نخلط بين هذه الأطوار و المراحل في الدورة الحياتية للنموذج الانحداري. في هذا القسم سوف نشرح هذه الأطوار و نستعرض النشاطات التي يتم أداؤها في كل طور.الاستهلاليتعلق طور الاستهلال بوضع نطاق المشروع و تحديد التصوّر العام له. بالنسبة للمشاريع الصغيرة يمكن لهذا الطور أن يكون مجرد دردشة بسيطة على فنجان قهوة يعقبها اتفاق على البدء في المشروع. في المشاريع الكبيرة يتطلب الأمر المزيد من التحرّي. المخرجات deliverables المحتملة من هذا الطور هي:وثيقة التصوّر.استكشاف مبدئي لإحتياجات الزبون.التحديد الابتدائي لمفردات glossary المشروع (المزيد حول هذا لاحقا).دراسة جدوى (تتضمن مححدات النجاح، التنبؤات المالية، تقديرات العائد على الاستثمار، الخ).التحديد المبدئي لنقاط المخاطرة.خطة المشروع.سوف نناقش طور الاستهلال بشيء من التفصيل عندما نتعرض لدراسة حالة case study في الفصل الرابع.التفصيلالغرض من التفصيل هو تحليل المشكلة ، و المضي خطوة ابعد في اعداد خطة المشروع، و استبعاد المناطق الأكثر مخاطرة فيه. مع نهاية طور التفصيل نأمل في الحصول على فهم عام لكامل المشروع، و لكن ليس بالضرورة فهما متعمقا (لاحقا سيتم التصدي له بصورة أجزاء صغيرة يسهل مناولتها).نموذجان من UML يكون لهما قيمة كبيرة في هذه المرحلة. نموذج حالة الاستخدام Use Case سيساعدنا في متطلبات المستفيد= الزبون ، و مخطط الطبقة Class Diagram و الذي ايضا يمكن استخدامه لاستكشاف المفاهيم العامة التي يتصورها المستفيد. المزيد حول هذا الموضوع قريبا. البناءفي طور البناء، نقوم ببناء المنتج. هذا الطور لن يتحقق بأسلوب خطي Linear ؛ بل يتم بناؤه بنفس أسلوب النموذج اللولبي، من خلال سلسلة من التكرارات. كل تكرار هو نفسه الاسلوب القديم: نموذج انحداري(3) بسيط. و من خلال الحرص على أن يكون كل تكرار أقصر ما يمكن، نأمل أن نتجنب المشاكل المزعجة التي ترافق الانحداريات.نهاية أكبر عدد من من التكرارات سوف نطمح في الحصول على منظومة تعمل (مبدئيا بالطبع، ستكون منظومة محدودة جدا في المراحل المبكرة). هذه التكرارات تسمّى تزايدات Increments، ومن هنا أتت تسمية اطار العمل هذا!التحوّل (الانتقال) Transitionالطور النهائي يتعلق بنقل المنتج النهائي الى الزبائن. النشاطات المعتادة في هذا الطور تتضمن:الاصدارات المبدئية لأغراض الاختيار من قبل بيئة المستخدم. الاختبارات في الموقع، أو تشغيل المنتج بالتوازي مع النظام القديم الذي سيستبدل. تجهيز البيانات (مل تحويل قواعد البيانات و صبّها في قوالبها الجديدة، توريد البيانات ، الخ..) تدريب المستخدمين الجدد. التسويق والتوزيع و المبيعات.يجب أن لا نخلط بين طور التحوّل هذا و طور الاختبار التقليدي في نهاية النموذج الانحداري ، فمنذ بداية التحوّل يجب ان يكون لدينا منتجا قابلا للتشغيل و تم اختباره بالكامل، و أن يكون جاهزا و متوفرا للمستخدمين. و كما اوضحنا سابقا، بعض المشاريع قد تتطلب خطوة اختبار مبدئية ، و لكن المنتج يجب ان يكون مكتملا قد الامكان فبل الدخول في هذا الطور.كم عدد هذه التكرارات؟ و كم يجب ان تطول؟التكرار الواحد يجب عادة ان يمتد من اسبوعين الى شهرين، أية زيادة على شهرين سوف تؤدي الى زيادة في التعقيد و الوصول الى النقطة التي لامناص منها : "الانفجار الكبير" ، دوّامة ضم الأجزاء الى بعضها البعض، حيث العديد من المكونات البرمجية ستحتاج الى ان تنتظم و تلتحم لأول مرة.اذا كبر المشروع و زاد تعقيده فلا يعني هذا أن تكون التكرارات أطول - لأن هذا سوف يزيد من مستوى التعقيد الذي سيكون على المطوّرين التعامل معه في المرّة الواحدة. بدلا من ذلك المشروع الأكبر يجب أن يخصص له تكرارات أكثر.فيما يلي بعض العوامل التي يجب أن توثر في طول مدّة النكرار:دورات التطوير المبكرة قد تحتاج لأن تكون أطول. هذا يعطي المطوّرين فرصة لأداء اعمال استكشافية على تقنيات جديدة أو غير مختبرة ، أو لتحديد البنية التحتية للمشروع. الأفراد حديثو الخبرة. فرق العمل المتعددة والتي تعمل على التوازي. فرق العمل المتوزعة (في أكثر من موقع).ايضا ، أريد ان اضم الى هذه القائمة المشروع ذو المراسمية العالية الذي سيحتاج عادة الى تكرارات أطول. و نقصد بالمشروع ذو المراسمية العالية ذلك الذي يتطلّب اصدار و توفير الكثير من الوثائق الخاصة بالمشروع الى الزبون، أو ربما مشروع يجب ان يلبّي العديد من المتطلبات القانونية . مثال جيد على هذا المشاريع ذات العلاقة بلأمور العسكرية، ففي هذه الحالة فان أعمال التوثيق سوف تزيد من طول فترة التكرار - و لكن كمية التطوير البرمجي الذي يتم التصدي له في هذا التكرار يجب أن يكون في حدوده الدنيا لتجنّب عدّونا الرئيسي و هو عبء التعقيد.القيد الزمني Time Boxingالأسلوب الأمثل لادارة عملية تكرارية تزايدية هو هو فرض قيد زمني. بهذا الاسلوب الحازم يتم تحديد فترة زمنية ثابتة يجب خلالها اتمام تكرارية معينة.اذا لم تكتمل التكرارية مع نهاية القيد الزمني، فالتكرارية يتم انهاؤها على أية حال. النشاط الأهم في التقييد الزمني هو المراجعة في نهاية التكرارية. المراجعة يجب أن تبحث في أسباب التأخير، و أن تعيد جدولة الأعمال غير المنتهية و تضمينها في التكرارات القادمة.احدى النصائح لكيفية تطبيق القيد الزمني، أن يكون المطورون هم المسؤولون (أو على الأقل الكلمة العليا) عن تحديد ما هي المتطلبات التي يتم تغطيتها في كل تكرار ، باعتبارهم الذين سوف يلتزمون بهذه الآجال.الالتزام بالقيد الزمني يعد صعبا، فهو يتطلّب حسّا عاليا بالانضباطية خلال كامل المشروع. من المغري جدا التخلّي عن المراجعة و تخطّي القيد الزمني اذا حان أجل التكرار و كانت نسبة اكتمال"99%" . حالما يرضخ المشروع لمثل هذا الاغراء و يتم تجاهل مراجعة واحدة ، فان المفهوم بكامله يبدأ في التداعي. اذا تم تجاهل عدة مراجعات ، فان التخطيط للتكرارات القادمة سوف تكون مائعة و تبدأ الفوضى في أخذ مكانها.بعض المدراء يفترضون ان التقييد الزمني يعيق مرونة الارجاء، هذا غير صحيح، فاذا لم تكتمل التكرارية وقت انتهاء أجل القيد الزمني فإن العمل غير المكتمل يجب نقله الى التكرارات التالية، و يتم اعادة جدولة خطط التتكرارات - يمكن ان يتضمن هذا ارجاء تاريخ التسليم أو اضافة تكرارات أكثر. عموما للتقييد الزمني فوائد هي:الهيكلية الصارمة تفرض عملية التخطيط و معاودتها. فلا يتم التخلّي عن الخطط اذا بدأ المشروع في التمطط. إذا تم فرض التقييد الزمني، تتضائل فرص ان يغوص المشروع في الفوضى اذا ما ظهرت مشاكل، حيث ان هناك دائما مراجعة رسمية منتظمة تلوح في الأفق. إذا ما تسرّب الخوف و بدأ المطوّرون في التخبّط بصورة عشوائية، سيتم وقف هذا التخبّط حالما تتم المراجعة.بصورة اساسية، يسمح القيد الزمني للمشروع بكامله أن يتريث مرة بعد الأخرى ليحزم أمره من جديد. انه لا يعرقل امكانيات الارجاء، و يحتاج الى ادارة مشروعات قوية كي يعمل بصورة صحيحة.التوقيتات النمطية للمشروعكم يجب ان يستغرق كل طور من الأطوار الأربعة؟ هذا يتباين من مشروع لآخر، و لكن كمؤشّر عام 10% للإستهلال، 30% للتفصيل، 50% للبناء و 10% للإنتقال.العملية الموّحدة من راشيونالThe Rational Unified Processالعملية الموحّدة من راشيونال (the RUP) هي المثال الأكثر شهرة للدورة الحياتية التكرارية قيد الاستعمال حاليا. تم تطوير RUP من قبل نفس "الاصدقاء الثلاثة" الذين قاموا بتطوير UML ، و لذلك فان RUP متكاملة جدا مع UML.بصورة أساسية، تقدّر مؤسسة راشيونال بأن كل مشروع يختلف عن الآخر، و ذو احتياجات مختلفة، مثلا، بعض المشاريع لاتتطلب الا طورا قصيرا للإستهلال، بينما مشاريع ذات علاقة بأمور عسكرية فإن طور الاستهلال فيها قد يمتد لسنوات.حتى هذه النقطة، تعد RUP مرنة و تسمح باعادة تكييف كل طور في العملية. ايضا تحدد RUP و بكل عناية قواعدا لكل فرد في المشروع و بحسب الاحتياج.و قد اصدرت مؤسسة راشيونال منتوجا لمساعدة المشاريع التي تتبنى RUP و يمكن ايجاد المزيد من التفاصيل في www.rational.com . المنتوج بالأساس عبارة عن دليل على شبكة الانترنت يضم جميع ملامح RUP. و تقدم الشركة امكانية استعمالة على سبيل التجربة لمدة 30 يوما.خلك صديق العمر واذكرني بأوقاتك

[العنقود]

تحياتي مجددافقد نسيت ان اضيف لكم هذا الرابط لمزيد من الفائدةwww.shagrouni.comاتمنى ان قد اعطيت شئا مفيداخلك صديق العمر واذكرني بأوقاتك