عملية موحدة عقلانية

الموسوعة الحرة
جزء من سلسلة عن
تطوير البرمجيات
الأنشطة الأساسية
النماذج والأنماط
المنهجيات والأطر
دعم التخصصات
الممارسات
أدوات
المعايير وهيئات المعرفة
القواميس
الخطوط العريضة
  • ف
  • ت
  • هـ

العملية الموحدة العقلانية ( RUP ) هي إطار عمل لعملية تطوير برمجيات متكررة أنشأتها شركة Rational Software Corporation، وهي قسم من IBM منذ عام 2003. [1] RUP ليست عملية وصفية ملموسة واحدة، بل هي إطار عمل عملية قابل للتكيف ، ومقصود منها أن يتم تصميمها من قبل منظمات التطوير وفرق مشاريع البرمجيات التي ستختار عناصر العملية المناسبة لاحتياجاتها. RUP هو تنفيذ محدد للعملية الموحدة .

تاريخ

طورت شركة Rational Software في الأصل عملية Rational الموحدة كمنتج عملية برمجي. يتضمن المنتج قاعدة معرفية مترابطة تحتوي على عينات من العناصر وأوصاف تفصيلية للعديد من أنواع الأنشطة المختلفة. يتم تضمين RUP في منتج IBM Rational Method Composer (RMC) الذي يسمح بتخصيص العملية.

تم تكليف فيليب كروشتن ، الممثل الفني ذو الخبرة في Rational، برئاسة فريق RUP الأصلي.

جمعت هذه الإصدارات الأولية بين الخبرة الميدانية الواسعة التي اكتسبتها منظمة Rational Software في بناء الأنظمة الموجهة للكائنات (والتي أشار إليها موظفو Rational الميدانيون باسم Rational Approach) وإرشادات Objectory بشأن الممارسات مثل حالات الاستخدام، وتضمنت محتوى واسع النطاق من نهج Jim Rumbaugh's Object Modeling Technology (OMT) للنمذجة، وطريقة Booch الخاصة بـ Grady Booch ، و UML 0.8 الذي تم إصداره حديثًا. [2] [3]

للمساعدة في جعل قاعدة المعرفة المتنامية هذه أكثر سهولة في الوصول إليها، تم تكليف فيليب كروشتن بتجميع إطار عمل واضح للعمليات للهندسة البرمجية الحديثة. وقد استخدم هذا الجهد آلية تسليم العمليات القائمة على HTML التي طورتها Objectory. وقد أكملت "عملية Rational Unified Process" الناتجة (RUP) ثلاثية الأرجل الاستراتيجية لشركة Rational:

  • عملية قابلة للتخصيص لتوجيه التطوير
  • الأدوات التي تعمل على أتمتة تطبيق هذه العملية
  • الخدمات التي سرّعت اعتماد كل من العملية والأدوات.

وقد تم تعزيز هذه الإرشادات في الإصدارات اللاحقة بالمعرفة المستندة إلى خبرة الشركات التي استحوذت عليها شركة Rational.

في عام 1997، تمت إضافة متطلبات وانضباط الاختبار إلى النهج، وتم الحصول على الكثير من المواد الإضافية من طريقة كلية المتطلبات التي طورها دين ليفينجويل وآخرون في شركة Requisite، Inc.، وطريقة عملية SQA التي طورتها شركة SQA Inc.، حيث تم الاستحواذ على كلتا الشركتين من قبل شركة Rational Software.

في عام 1998 أضافت شركة Rational Software تخصصين جديدين:

  1. نمذجة الأعمال، كان الكثير من هذا المحتوى موجودًا بالفعل في عملية الاعتراض
  2. تخصص في إدارة التكوين والتغيير، تم الحصول عليه من خلال الاستحواذ على شركة Pure Atria Corporation.

تؤدي هذه الإضافات إلى مجموعة شاملة من المبادئ التي حددتها Rational وتم التعبير عنها داخل RUP باعتبارها أفضل ستة ممارسات للهندسة البرمجية الحديثة:

  1. التطوير بشكل تكراري، مع اعتبار المخاطرة المحرك الأساسي للتكرار [4]
  2. إدارة المتطلبات
  3. استخدام بنية قائمة على المكونات
  4. نموذج البرمجيات بصريا
  5. التحقق المستمر من الجودة
  6. التحكم في التغييرات

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

تم تضمين تقنيات إضافية بما في ذلك اختبار الأداء وتصميم واجهة المستخدم وهندسة البيانات وتحديث ليعكس التغييرات في UML 1.1.

في عام 1999، تم تقديم تخصص إدارة المشاريع، بالإضافة إلى تقنيات لدعم تطوير البرمجيات في الوقت الفعلي والتحديثات لتعكس UML 1.3. بالإضافة إلى ذلك، تم نشر أول كتاب يصف العملية، عملية تطوير البرمجيات الموحدة ( ISBN  0-201-57169-2 ) من تأليف إيفار جاكوبسون وجرادي بوتش وجيمس رامبو ، في نفس العام.

بين عامي 2000 و2003، تم إدخال عدد من التغييرات التي استُخدمت في التوجيهات المستمدة من الخبرة الميدانية المستمرة لشركة Rational في التطوير التكراري، بالإضافة إلى دعم الأدوات لتنفيذ حالات RUP وتخصيص إطار عمل RUP. وتضمنت هذه التغييرات ما يلي:

  1. تقديم مفاهيم وتقنيات من مناهج مثل البرمجة المتطرفة (XP)، والتي أصبحت تُعرف فيما بعد بشكل جماعي باسم الأساليب الرشيقة. وشمل ذلك تقنيات مثل البرمجة الزوجية، وتصميم الاختبار أولاً، والأوراق التي أوضحت كيف مكّنت RUP XP من التوسع للاستخدام في مشاريع أكبر.
  2. إصلاح شامل لنظام الاختبار ليعكس بشكل أفضل كيفية إجراء عمل الاختبار في سياقات التطوير التكرارية المختلفة.
  3. تقديم إرشادات داعمة - تُعرف باسم "مرشدي الأدوات" - لتطبيق ممارسات RUP في أدوات مختلفة. وقد وفرت هذه الإرشادات بشكل أساسي دعمًا منهجيًا خطوة بخطوة لمستخدمي أدوات Rational.
  4. أتمتة تخصيص RUP بطريقة تسمح للعملاء باختيار الأجزاء من إطار عملية RUP، وتخصيص اختيارهم بإضافاتهم الخاصة، مع الاستمرار في دمج التحسينات في الإصدارات اللاحقة من Rational.

استحوذت شركة IBM على شركة Rational Software في فبراير 2003.

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

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

كتل بناء RUP

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

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

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

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

مراحل وتخصصات RUP.

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

مرحلة التأسيس

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

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

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

مرحلة الإعداد

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

نتيجة مرحلة الإعداد هي:

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

يجب أن تجتاز هذه المرحلة معايير معلم دورة حياة الهندسة المعمارية من خلال الإجابة على الأسئلة التالية:

  • هل رؤية المنتج مستقرة؟
  • هل العمارة مستقرة؟
  • هل يشير العرض التوضيحي القابل للتنفيذ إلى أنه تم معالجة عناصر المخاطر الرئيسية وحلها؟
  • هل خطة مرحلة البناء مفصلة ودقيقة بما فيه الكفاية؟
  • هل يتفق جميع أصحاب المصلحة على أنه يمكن تحقيق الرؤية الحالية باستخدام الخطة الحالية في سياق البنية التحتية الحالية؟
  • هل الإنفاق الفعلي للموارد مقارنة بالمخطط له مقبول؟

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

إن التحليل المجالي الرئيسي للإعداد هو بنية النظام.

مرحلة البناء

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

مرحلة الانتقال

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

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

منتج IBM Rational Method Composer

منتج IBM Rational Method Composer هو أداة لتأليف العمليات وتكوينها وعرضها ونشرها. راجع IBM Rational Method Composer ومشروع إطار عمل Eclipse للعمليات (EPF) مفتوح المصدر للحصول على مزيد من التفاصيل.

شهادة

في يناير 2007، تم إصدار امتحان شهادة RUP الجديد لـ IBM Certified Solution Designer - Rational Unified Process 7.0 والذي يحل محل الإصدار السابق من الدورة التدريبية المسماة IBM Rational Certified Specialist - Rational Unified Process . [6] لن يختبر الامتحان الجديد المعرفة المتعلقة بمحتوى RUP فحسب، بل سيختبر أيضًا عناصر بنية العملية. [7]

لاجتياز امتحان شهادة RUP الجديد، يجب على الشخص اجتياز اختبار IBM 839: Rational Unified Process v7.0 . يتم منحك 75 دقيقة لاجتياز الاختبار المكون من 52 سؤالاً. درجة النجاح هي 62%. [8]

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

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

تطوير بشكل متكرر
من الأفضل معرفة كافة المتطلبات مسبقًا؛ ولكن هذا لا يحدث غالبًا. توجد العديد من عمليات تطوير البرامج التي تتعامل مع توفير الحلول لتقليل التكلفة من حيث مراحل التطوير.
إدارة المتطلبات
ضع دائمًا في الاعتبار المتطلبات التي وضعها المستخدمون.
استخدم المكونات
إن تفكيك مشروع متقدم ليس مجرد اقتراح فحسب، بل إنه أمر لا مفر منه في الواقع. وهذا يعزز القدرة على اختبار المكونات الفردية قبل دمجها في نظام أكبر. كما أن إعادة استخدام التعليمات البرمجية تعد ميزة كبيرة ويمكن إنجازها بسهولة أكبر من خلال استخدام البرمجة الموجهة للكائنات .
نموذج بصريا
استخدم المخططات البيانية لتمثيل جميع المكونات الرئيسية والمستخدمين وتفاعلهم. "UML"، وهو اختصار لـ Unified Modeling Language ، هو إحدى الأدوات التي يمكن استخدامها لجعل هذه المهمة أكثر قابلية للتنفيذ.
التحقق من الجودة
اجعل الاختبار دائمًا جزءًا رئيسيًا من المشروع في أي وقت. يصبح الاختبار أكثر ثقلًا مع تقدم المشروع، ولكن يجب أن يكون عاملًا ثابتًا في إنشاء أي منتج برمجي.
التحكم في التغييرات
يتم إنشاء العديد من المشاريع بواسطة العديد من الفرق، وفي بعض الأحيان في مواقع مختلفة، وقد يتم استخدام منصات مختلفة، وما إلى ذلك. ونتيجة لذلك، من الضروري التأكد من مزامنة التغييرات التي يتم إجراؤها على النظام والتحقق منها باستمرار. (انظر التكامل المستمر ).

انظر أيضا

مراجع

  1. ^ آي بي إم تستحوذ على شركة راشيونال
  2. ^ Jacobson, Sten (2002-07-19). "The Rational Objectory Process - A UML-based Software Engineering Process". Rational Software Scandinavia AB. مؤرشف من الأصل في 2019-05-27 . تم الاسترجاع في 2014-12-17 .
  3. ^ كروشتن، فيليب (2004-05-01). العملية الموحدة العقلانية: مقدمة. أديسون ويسلي . ص 33. ISBN 9780321197702. تم الاسترجاع بتاريخ 2014-12-17 .
  4. ^ أكيد، مارك (2003-11-25). "RUP in Brief". IBM . تم الاسترجاع في 2011-07-12 .
  5. ^ "OpenUP". مؤرشف من الأصل في 2014-01-06 . تم الاسترجاع 2013-08-03 .
  6. ^ كريبس، يوتشن (15 يناير 2007). "قيمة شهادة RUP". IBM . تم الاسترجاع في 5 مايو 2014 .
  7. ^ "Spacer IBM Certified Solution Designer - IBM Rational Unified Process V7.0". IBM . مؤرشف من الأصل في 8 يناير 2007 . تم الاسترجاع في 2008-05-13 .
  8. ^ "اختبار 839: Rational Unified Process v7.0". IBM . تم الاسترجاع في 2008-05-13 .[ رابط ميت دائم ‍ ]
  9. ^ ستيفن شاش (2004). هندسة البرمجيات الكلاسيكية والبرمجية الموجهة للكائنات . المجلد 6/الطبعة الثانية، دبليو سي بي ماكجرو هيل، نيويورك، 2004.
  10. ^ ورقة بيضاء حول عملية Rational Unified Process محفوظ في 2009-05-01 على موقع Wayback Machine

قراءة إضافية

  • إيفار جاكوبسون ، جرادي بوتش ، وجيمس رامبو (1999). عملية تطوير البرمجيات الموحدة
  • جاري بوليس، وليز أوغسطين، وكريس لو، وجاس مادور (2003). تطوير البرمجيات للفرق الصغيرة: نهج يركز على RUP
  • بير كرول، فيليب كروشتن (2003). عملية موحدة عقلانية سهلة، دليل الممارسين لعملية موحدة عقلانية
  • بير كرول، بروس ماك إسحاق (2006). المرونة والانضباط أصبحا سهلين: ممارسات من OpenUP وRUP
  • فيليب كروشتن (1998). العملية الموحدة العقلانية: مقدمة
  • أحمد شوجا، يوتشن كريبس (2007). دليل RUP المرجعي والشهادات
  • ووكر رويس، إدارة مشاريع البرمجيات، إطار عمل موحد
  • بول شيمكوفياك، فيليب كروشتن (2003). الاختبار: فلسفة RUP [1]
  • موقع IBM Rational Unified Process على الويب
  1. ^ Szymkowiak, Paul; Kruchten, Philippe (فبراير 2003). "Testing: The RUP Philosophy". Academia.Edu . Rational Software (مجلة Rational Edge الإلكترونية). ص. 11. تم الاسترجاع في 2022-10-13 .
Retrieved from "https://en.wikipedia.org/w/index.php?title=Rational_unified_process&oldid=1242252653"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate