العملية الموحدة لراشيونال

العملية الموحدة لراشيونال ( Rational Unified Process) (RUP) هي إطار عملية تطوير البرمجيات أنتجتها شركة راشيونال سوفت وير، وهي قسم من أقسام شركة IBMآي‌ بي‌ إم منذ عام 2003.[1][2][3][4] وRUP ليست عملية توصيفية فردية، ولكنها ليست إطار عمل (برمجة) لعملية قابلة للتكيف يقصد بها أن تتم تهيئتها عبر مؤسسات التنمية وفرق مشروع البرمجة والتي ستختار عناصر العملية الملائمة لاحتياجاتهم

تحتوي هذه المقالة ترجمة آلية، يجب تدقيقها وتحسينها أو إزالتها لأنها تخالف سياسات ويكيبيديا.(نقاش) (أبريل 2019)
عملية تطوير البرمجيات
نشاطات وخطوات
المتطلبات · مواصفة وظيفية
البنيان · تصميم البرمجيات
التنفيذ · الفحص
نشر البرمجيات · صيانة البرمجيات
منهجيات
أجيل · هندسة برمجيات الغرفة النظيفة · Iterative
RAD · RUP · Spiral
Waterfall · XP · Lean
سكرم · V-Model · TDD
اختصاصات داعمة
إدارة تكوين البرمجيات
توثيق البرمجيات
ضمان الجودة
Project management
تصميم تجربة المستخدم
أدوات
المصرف · المصحح · Profiler
GUI designer · ب ت م

تاريخ

العملية الموحدة لراشيونال (RUP) هو منتج برمجي تم ابتكاره في الأساس بواسطة شركة راشيونال سوفت وير التي استحوذت عليها IBM في فبراير 2003. يتضمن المنتج قاعدة معرفية مرتبطة بالنتاج الاصطناعي البسيط من صنع الإنسان وتوصيفات تفصيلية لأنواع مختلفة من الأنشطة. وRUP مدرجة في منتج مؤلف الوسيلة لراشيونال لIBM والذي يسمح بتفرد العملية وتخصيصها.

مع حلول عام 1997، استحوذت شركة راشيونال على فيردكس وأوبجيكتوري وريكويسيت وإس كيو إيه وبيرفورمانس أويرنيس وبيور أتريا. دمج قاعدة الخبرة للشركات يؤدي إلى صياغة ست ممارسات أفضل لهندسة البرمجيات العصرية:

  1. التطوير بصورة متكررة مع المخاطر كمشغل تكراري أولي.
  2. تدبير المتطلبات
  3. نمذجة البرامج مرئيا
  4. التحقق عن الجودة بشكل مستمر
  5. تغييرات الضبط

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

  • عملية يمكن تهيئتها تهدي إلى التطوير
  • أدوات تعمل على أتمتة تطبيق هذه العملية
  • خدمات تسرع اتباع كلا من العملية والأدوات

موضوعات العملية الموحدة لراشيونال

قوالب بناء RUP

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

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

مع كل عملية تكرار، يتم تصنيف المهام إلى تسعة فروع:

  • ستة "أفرع هندسية"
    • نمذجة العمل
    • المتطلبات
    • التحليل والتصميم
    • التطبيق
    • الفحص
    • النشر
  • الفروع الداعمة:
    • التثبيت وإدارة التغيير
    • إدارة المشروع
    • البيئة

المراحل الأربعة في دورة حياة المشروع
مراحل وفروع RUB.

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

مرحلة البدء (Inception Phase)

الهدف الرئيسي هو تحديد نطاق النظام بصورة كافية ليكون أساس صحة التكاليف والميزانيات الأولية بشكل مناسب. في هذه المرحلة يتم تأسيس حقيبة العمل التي تتضمن سياق العمل، وعناصر النجاح (باستثناء العائدات، تقدير السوق....الخ) والتنبؤات المالية التي تم توقعها.لا ستكمال عملية دراسة الجدوي، يتم انشاء مبدئياً "نموذج حالة" (Use Case، خطة عمل، تقييم أولي للمخاطر (Risk) ووصف المشروع (متطلبات المشروع الأساسية، القيود والمميزات الرئيسية). بعد الانتهاء من تلك العمليات، يتم فحص المشروع مقابل المعايير التالية:

  • التقاء أصحاب المصالح على تعريف للنطاق وتقديرات للتكاليف/ الجدول الزمني.
  • المتطلبات المفهومة كدلائل بواسطة دقة حالات الاستخدام Use Cases الأولية.
  • مصداقية تقديرات التكاليف/ الجدول الزمني، الأولويات، المخاطر، عملية التطوير.
  • عمق واتساع أي نموذج أصلي معماري (architectural prototype) تم تطويره.
  • تأسيس خط أساسي يمكن عن طريقه مقارنة النفقات الفعلية بالنفقات المخططة.

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

مرحلة التفسير أو التفصيل (Elaboration Phase)

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

يجب أن تجتاز هذه المرحلة الركيزة الأساسية للشكل المعماري لدورة الحياة عبر الوفاء بتحقيق النتائج التالية:

  • نموذج حقيبة قابل للاستخدام يتم فيها التعرف على حقائب الاستخدام والممثلين ويتم تطوير معظم مواصفات حقيبة الاستخدام. يجب أن يكون نموذج حقيبة الاستخدام مكتمل بنسبة 80%.
  • وصفا لهندسة البرنامج المعمارية في عملية تطوير نظام البرنامج.
  • طرازا معماريا قابل للتنفيذ يحقق حقائب الاستخدام البارزة معماريا.
  • حقيبة العمل وقائمة المخاطر التي تم تنقيحها
  • خطة تطوير للمشروع بأكمله.
  • نماذج أصلية تخفف المخاطر الفنية المعرفة بشكل واضح.

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

تحليل النطاق الرئيسي للتفسير هو هندسة النظام.

مرحلة الإنشاء (Construction Phase)

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

هذه المرحلة ينتج عنها الإصدار الخارجي الأول للبرنامج. وتتميز نهاية هذا البرنامج بركيزة أساسية للإمكانية الأولية للتشغيل.

مرحلة الانتقال (Transition Phase)

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

إذا تم تحقيق كافة الأهداف، يتم التوصل إلى الركيزة الأساسية لإصدار المنتج وتنتهي دورة التطوير.

منتج مؤلف وسيلة راشيونال IBM

منتج مؤلف وسيلة راشيونال IBM هو أداة لتأليف وتركيب وعرض ونشر العمليات. أرجع إلى مؤلف وسيلة راشيونال IBM ونسخة مصدر مفتوح إطار عملية إكليبس Eclipse Process Framework لمزيد من التفاصيل.

الشهادة

في يناير 2007، تم إصدار شهادة فحص RUP الجديدة لمصمم الحلول المعتمدبIBM- العملية الموحدة 0.7 لراشيونال والتي تستبدل النسخة السابقة من الدورة المسماة المتخصص المعتمد لراشيونال IBM- عملية راشيونال الموحدة.[5] الفحص الجديد لن يختبر فقط المعرفة المتعلقة بمحتوى RUP ولكن أيضا عناصر هيكل العملية.[6]

ولاجتياز فحص شهادة RUP الجديدة، على الشخص اجتياز فحص IBM839 للعملية الموحدة لراشيونال بالنسخة 7. وسيتم منحك 75 دقيقة لاجتياز اختبار مكون من 52 سؤال. ودرجة اجتياز هذا الاختبار هي 62%.[7]

أفضل ستة ممارسات

أفضل الممارسات الستة المذكورة في العملية الموحدة لراشيونال هي نموذج في هندسة البرمجيات والذي يتضمن ستة أفكار ينبغي إتباعها عند تصميم أي مشروع لبرنامج لتقليل الأخطاء وزيادة الإنتاجية. هذه الممارسات هي:[8][9]

التطوير بشكل تكراري(Develop iteratively )
من الأفضل معرفة كافة المتطلبات مقدما، إلا أن هذا ليس الحال دائما. العديد من عمليات تطوير البرامج الموجودة تتعامل مع توفير الحلول حول كيفية تقليل التكاليف فيما يتعلق بمراحل التطوير.
إدارة المتطلبات(Manage requirements)
دائما تذكر المتطلبات التي وضعها المستخدمين.
استخدام المحتويات (Use components)
تقسيم مشروع متقدم ليس أمر مقترح فقط ولكنه في الواقع أمر لا يمكن تجنبه. يعزز ذلك إمكانية فحص المحتويات الفردية قبل أن يتم دمجها في نظام أكبر. أيضا يعتبر استخدام الشفرة مرة أخرى إضافة كبيرة ويمكن إنجازها بشكل أسهل عبر استخدام برمجة كائنية التوجه.
أكثر مرئية (Model visually)
استخدام الرسومات البيانية لتمثيل كافة المكونات الرئيسية والمستخدمين وتفاعلها مع بعضها البعض. ويعد UML أو اختصار لغة موحدة للنمذجة أداة يمكن استخدامها لتكون هذه المهمة أكثر مرونة.
التحقق من الجودة (Verify quality)
دائما اجعل الاختبار جزءا رئيسيا من المشروع في أي وقت. يصبح الاختبار أثقل مع تقدم المشروع ولكن يجب أن يكون عنصرا ثابتا في خلق أي منتج برمجيات.
تغيير الضوابط (Control changes)
يقوم العديد من الفرق بخلق العديد من المشروعات، في بعض الأحيان يتم ذلك في مواقع متعددة، وربما يستخدم منصات مختلفة... الخ. نتيجة لذلك من الأساسي التأكد من أن التغييرات التي ستتم على النظام سيتم مزامنتها والتحقق من صحتها بشكل ثابت. تكامل متواصل

انظر أيضا

المراجع
  1. Jacobson, Sten (2002-07-19). "The Rational Objectory Process - A UML-based Software Engineering Process". Rational Software Scandinavia AB. مؤرشف من الأصل في 27 مايو 2019. اطلع عليه بتاريخ 17 ديسمبر 2014. الوسيط |CitationClass= تم تجاهله (مساعدة)
  2. Kruchten, Philippe (2004-05-01). "The Rational Unified Process: An Introduction". أديسون-ويسلي . صفحة 33. مؤرشف من الأصل في 15 أبريل 2017. اطلع عليه بتاريخ 17 ديسمبر 2014. الوسيط |CitationClass= تم تجاهله (مساعدة)
  3. "Test 839: Rational Unified Process v7.0". آي بي إم. اطلع عليه بتاريخ 13 مايو 2008. الوسيط |CitationClass= تم تجاهله (مساعدة)
  4. IBM Acquires Rational
  5. Krebs, Jochen (2007-01-15). "The value of RUP certification". آي بي إم. مؤرشف من الأصل في 06 يونيو 2008. اطلع عليه بتاريخ 13 مايو 2008. الوسيط |CitationClass= تم تجاهله (مساعدة)
  6. "Spacer IBM Certified Solution Designer - IBM Rational Unified Process V7.0". آي بي إم. مؤرشف من الأصل في 12 يونيو 2017. اطلع عليه بتاريخ 13 مايو 2008. الوسيط |CitationClass= تم تجاهله (مساعدة)
  7. "Test 839: Rational Unified Process v7.0". آي بي إم. مؤرشف من الأصل في 22 يونيو 2014. اطلع عليه بتاريخ 13 مايو 2008. الوسيط |CitationClass= تم تجاهله (مساعدة)
  8. Stephen Schach (2004). Classical and Object-Oriented Software Engineering. 6/e, WCB McGraw Hill, New York, 2004.
  9. Rational Unified Process white paper [وصلة مكسورة] نسخة محفوظة 30 يناير 2014 على موقع واي باك مشين.

    لمزيد من القراءة
    • إيفار جاكوبسون, Grady Booch, and جيمس رامبوغ (1999). The Unified Software Development Process
    • Per Kroll, Philippe Kruchten (2003). Rational Unified Process Made Easy, The: A Practitioner's Guide to the RUP
    • Per Kroll, Bruce Mac Isaac (2006). Agility and Discipline Made Easy: Practices from OpenUP and RUP
    • Philippe Kruchten (1998). The Rational Unified Process: An Introduction
    • Ahmad Shuja, Jochen Krebs (2007). RUP Reference and Certification Guide
    • Walker Royce, Software Project Management, A Unified Framework

    وصلات خارجية

    قالب:UML

    • بوابة تقنية المعلومات
    • بوابة علم الحاسوب
    • بوابة برمجة الحاسوب
    This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.