فرآیند یکپارچه– این یک چارچوب کلی از فرآیند ایجاد نرم افزار است که می تواند باشد تخصصی برای طیف گسترده ای از سیستم های نرم افزاری. فرآیند یکپارچه از یک زبان مدل سازی یکپارچه برای توسعه مدل یک سیستم نرم افزاری استفاده می کند.

شروع به حمله به خطرات اصلی کنید، آن را به طور مداوم انجام دهید، در غیر این صورت خطرات به شما حمله خواهند کرد.

اطمینان از برآورده شدن نیازهای مشتری: الزامات را به گونه ای مستند کنید که مشتری بتواند آن را درک کند و به شدت به این الزامات در طول طراحی و اجرا پایبند باشد.

روی برنامه در دست تمرکز کنید: در حال اجرا نرم افزارگذراندن آزمون ها بهتر از مستندات جامع

از همان ابتدای پروژه با تغییرات سازگار شوید: برنامه های مدرن به اندازه کافی پیچیده هستند که می توانیم در همان ابتدای توسعه نیازهای خاصی را دریافت کنیم. بنابراین لازم است معماری نرم افزار به گونه ای طراحی شود که مستعد تغییر باشد.

هر چه زودتر پایه یک معماری اجرایی را بنیانگذاری کنید. معماری اجرایی - موارد استفاده کلیدی. کلید VI عملکرد سیستم است که بدون آن نرم افزار معنی ندارد. کلید. VI ها 7 تا 10 درصد از کل گزینه ها را تشکیل می دهند

یک سیستم از اجزا بسازید. برنامه های کاربردی مبتنی بر مؤلفه سریعتر ساخته می شوند، از نظر تغییرات انعطاف پذیرتر هستند و هزینه نسبتاً پایینی دارند.

به عنوان 1 تیم کار کنید

کیفیت را به یک روش زندگی تبدیل کنید، نه یک فکر بعدی

6 چرخه زندگی یک فرآیند یکپارچه. اهداف هر مرحله

فرآیند یکپارچه به صورت چرخه ای تکرار می شود. این توالی از تکرار فرآیند یکپارچه نشان دهنده چرخه حیات سیستم است. هر چرخه با تحویل یک محصول به مشتریان پایان می یابد.

هر چرخه شامل چهار مرحله است - تجزیه و تحلیل و برنامه ریزی نیازمندی ها، طراحی، ساخت و اجرا. هر مرحله، همانطور که در زیر مورد بحث قرار می‌گیرد، به تکرارها تقسیم می‌شود.

در حین مراحل تحلیل و برنامه ریزی الزامات ایده خوبی استتبدیل به مفهومی برای یک محصول نهایی شده و یک طرح تجاری برای توسعه این محصول ایجاد می شود. به ویژه در این مرحله باید به سوالات زیر پاسخ داده شود:

سیستم ابتدا باید برای کاربران اصلی خود چه کاری انجام دهد؟

معماری سیستم چگونه باید باشد؟

برنامه چیست و هزینه توسعه محصول چقدر است؟

در این مرحله یک نسخه آزمایشی از معماری ایجاد می شود. معمولاً یک طرح کلی حاوی مهمترین زیرسیستم ها است. در طول این مرحله، مهم ترین ریسک ها شناسایی و اولویت بندی می شوند، مرحله طراحی با جزئیات برنامه ریزی می شود و کل پروژه به طور تقریبی برآورد می شود.

در حین مراحل طراحی بیشتر موارد استفاده با جزئیات شرح داده شده و معماری سیستم توسعه یافته است.

در پایان مرحله طراحی، مدیر پروژه به برنامه ریزی فعالیت ها و محاسبه منابع مورد نیاز برای تکمیل پروژه مشغول است. سوال کلیدی در این مرحله این خواهد بود: آیا موارد استفاده، معماری و طراحی به اندازه کافی بالغ هستند و آیا خطرات تحت کنترل برای تضمین تعهد قراردادی برای تکمیل کار توسعه کافی است؟

در حین مراحل ساخت و ساز یک محصول در حال ایجاد است - ماهیچه ها (برنامه های تکمیل شده) به اسکلت (معماری) اضافه می شوند. در طول این مرحله، سطح پایه معماری به یک سیستم کامل بالغ تبدیل می شود. مفاهیم تبدیل به محصولی می شوند که آماده تحویل به کاربران است. در طول فاز، مقدار منابع مورد نیاز افزایش می یابد. در پایان این مرحله، محصول شامل تمام موارد استفاده است که مدیریت و مشتری توافق کردند که در نسخه فعلی گنجانده شوند. درست است، آنها ممکن است حاوی خطا باشند. اکثر عیوب در مرحله اجرا کشف و اصلاح خواهند شد. سوال کلیدی پایان مرحله این است: آیا محصول نیازهای کاربر را تا حدی برآورده می کند که برخی از مشتریان را می توان از قبل تحویل داد؟

مرحله اجرا دوره ای را پوشش می دهد که طی آن محصول به عنوان نسخه بتا یا نسخه بتا وجود دارد. تعداد کمی از کاربران واجد شرایط که با نسخه بتا محصول کار می کنند، نقص ها و کاستی ها را گزارش می دهند. سپس توسعه‌دهندگان باگ‌هایی را که پیدا می‌کنند برطرف می‌کنند و برخی از پیشرفت‌های پیشنهادی را در نسخه اصلی که برای توزیع گسترده آماده است، وارد می‌کنند. مرحله اجرا شامل فعالیت هایی مانند تولید نسخه ها، آموزش کارکنان مشتریان، سازماندهی پشتیبانی خط تلفن و اصلاح عیوب کشف شده پس از تحویل است.

فرآیند یکپارچه منطقی (RUP)- متدولوژی توسعه نرم افزار، ایجاد شده توسط Rationalنرم افزار.

اصول: شناسایی زودهنگام و حذف مستمر (تا پایان پروژه) خطرات عمده. تمرکز بر برآوردن نیازهای مشتری برای برنامه اجرایی (تجزیه و تحلیل و ساخت مدلی از سوابق (مورد استفاده)). انتظار تغییرات در الزامات، تصمیمات طراحی و اجرا در طول فرآیند توسعه را داشته باشید. معماری کامپوننت در اوایل پروژه اجرا و آزمایش شد. تضمین کیفیت مستمر در تمام مراحل توسعه پروژه (محصول).

کار بر روی یک پروژه در یک تیم نزدیک، که در آن معماران نقش کلیدی دارند.

RUP استفاده می کند مدل توسعه تکراری. در پایان هر تکرار (به طور ایده آل 2 تا 6 هفته طول می کشد)، تیم پروژه باید به اهداف برنامه ریزی شده برای این تکرار دست یابد، مصنوعات طراحی را ایجاد یا اصلاح کند و یک نسخه متوسط ​​اما کاربردی از محصول نهایی را به دست آورد.

چرخه عمر کامل توسعه محصول شامل چهار فازکه هر کدام شامل یک یا چند تکرار است: فاز اولیه، مرحله شفاف سازی، طراحی و اجرا.

برنامه نویسی شدید (XP)

برنامه نویسی افراطی(برنامه نویسی شدید، XP) - یکی از متدولوژی های توسعه نرم افزار انعطاف پذیر

12 تکنیک اساسیبرنامه نویسی افراطی (طبق ویرایش اول کتاب برنامه نویسی افراطی توضیح داده شده) را می توان در چهار گروه ترکیب کرد:

چرخه کوتاه بازخورد: (توسعه مبتنی بر آزمایش، بازی برنامه ریزی، مشتری همیشه آنجاست، برنامه نویسی جفتی

فرآیند پیوسته به جای دسته ای:ادغام مداوم، Refactoring، انتشار کوچک مکرر

تفاهم مشترک بین همه: سادگی، استعاره سیستم، مالکیت جمعی کد یا الگوهای طراحی منتخب، استاندارد کدگذاری

تامین اجتماعی یک برنامه نویس: 40 ساعت هفته کاری

برنامه نویسی جفت شامل تمام کدهایی است که توسط جفت برنامه نویسی که روی یک کامپیوتر کار می کنند ایجاد می شود. مالکیت جمعی به این معنی است که هر یک از اعضای تیم مسئول تمام کد منبع است. "مشتری" در XP کسی نیست که صورتحساب ها را پرداخت می کند، بلکه کسی است که در واقع از سیستم استفاده می کند.

استانداردهای مستندسازی

استانداردها سازگاری بین پروژه ها را تضمین می کند. استانداردها درک بین مهندسان را بهبود می بخشد. استانداردها باید توسط مهندسان به عنوان چیزی مفید برای آنها درک شود، نه به عنوان مجموعه ای از موانع. اهداف واضح و قابل اندازه گیری که نیازمند رویکردی منظم و مستند هستند معمولاً انگیزه خوبی برای توسعه دهندگان هستند.

SVVP-طرح تعیین می کند که مراحل پروژه چگونه و با چه ترتیبی باید آزمایش شوند. راستی‌آزمایی فرآیندی است برای تأیید اینکه یک برنامه به درستی ساخته شده است. اعتبارسنجی تأیید می کند که محصول مورد نیاز مونتاژ شده است.

SQAP-طرح کنترل کیفیت نرم افزار

SCMP-برنامه مدیریتی پروژه نرم افزاری

SRS-مشخصات مورد نیاز نرم افزار

SDD-مستندات طراحی نرم افزار

STD-مستندات تست نرم افزار

سازگاری و یکپارچگی اسناد.

مدیریت اسناد به مهارت های سازمانی قابل توجهی نیاز دارد. نوشتن اسناد خوب و منعطف مشابه نوشتن کد خوب و انعطاف پذیر است.

مدیریت اسناد به معنای حفظ آن است کامل بودنو ثباتو نیز شامل می شود مدیریت پیکربندی.

کامل بودن -در دسترس بودن مجموعه ای از اسناد و مدارک که فرآیند توسعه و نگهداری را پوشش می دهد.

ثباتبه این معنی که مجموعه اسناد حاوی تضادهای درونی نیست، مشکل این است که وقتی این مجموعه بزرگ باشد، اجتناب از ظاهر شدن عبارات متقابل در آن بسیار دشوار است.

پشتیبانی از پیکربندی -این هماهنگی نسخه ها و بخش های مختلف مستندات و کد برنامه است.

RUP نمونه ای از به اصطلاح است فرآیند "دشوار"، به تفصیل توضیح داده شده و پشتیبانی از توسعه واقعی کد منبع نرم افزار را با تعداد زیادی اقدامات کمکی پیشنهاد می کند. نمونه‌هایی از این فعالیت‌ها عبارتند از: برنامه‌های توسعه، تکالیف فنی، مدل های طراحی متعدد، مستندات طراحی و غیره. هدف اصلی این فرآیند جداسازی شیوه های توسعه و نگهداری نرم افزار موفق از افراد خاصی است که می دانند چگونه آنها را به کار گیرند. اقدامات حمایتی متعدد امیدی را برای امکان پذیر ساختن آن ایجاد می کند راه حل موفقوظایف ساخت و پشتیبانی سیستم های پیچیده با کمک کارگران موجود که لزوماً فوق حرفه ای نیستند.

برای دستیابی به این هدف، شرح دقیق سلسله مراتبی گام به گام اقدامات انجام شده در یک موقعیت معین انجام می شود تا به یک کارگر عادی آموزش داده شود که به روشی مشابه عمل کند. در طول یک پروژه، اسناد میانی زیادی ایجاد می‌شوند که به توسعه‌دهندگان اجازه می‌دهند کارهایی که با آن روبرو هستند را به طور متوالی به کارهای ساده‌تر تقسیم کنند. همین اسناد برای تأیید صحت تصمیمات اتخاذ شده در هر مرحله و همچنین ردیابی پیشرفت کلی کار و روشن کردن برآوردهای منابع مورد نیاز برای دستیابی به نتایج مطلوب است.

برنامه نویسی افراطی، برعکس، نشان دهنده به اصطلاح روش های توسعه "زنده" (چابک).، همچنین به نام "سبک"فرآیندها آنها بر استفاده از توسعه دهندگان خوب به جای فرآیندهای توسعه خوب تاکید دارند. روش‌های زندگی از تعهد به شفاف‌سازی نقشه‌ها برای اجازه دادن به انعطاف‌پذیری بیشتر بر اساس پروژه به پروژه اجتناب می‌کنند، و همچنین از توسعه اسناد اضافی که مستقیماً به یک برنامه کامل و کاری کمک نمی‌کنند، جلوگیری می‌کنند.

فرآیند یکپارچه منطقی

RUP بسیار پیچیده و با جزئیات است مدل چرخه زندگی تکراریتوسط .

از لحاظ تاریخی، RUP توسعه مدل فرآیند توسعه است که توسط اریکسون در دهه‌های 70 و 80 قرن بیستم اتخاذ شد. این مدل توسط Ivar Jacobson ایجاد شد که متعاقباً در سال 1987 شرکت خود Objectory AB را به طور خاص برای توسعه تأسیس کرد. فرآیند تکنولوژیکیتوسعه نرم افزار به عنوان یک محصول جداگانه که می تواند به سازمان های دیگر منتقل شود. پس از ادغام Objectory در Rational در سال 1995، تحولات یاکوبسون با کار رویس ادغام شد (واکر رویس، پسر نویسنده "کلاسیک" مدل آبشاری Kruchten (Philippe Kruchten) و Booch (Grady Booch) و همچنین با توسعه موازی زبان مدلسازی جهانی (زبان مدلسازی یکپارچه، UML).

RUP بر اساس سه ایده کلیدی است:

کل پیشرفت کار توسط اهداف نهایی پروژه هدایت می شود که در فرم بیان شده است موارد استفاده- سناریوهای تعامل سیستم نرم افزاری حاصل با کاربران یا سایر سیستم ها که طی آن کاربران نتایج و خدماتی را دریافت می کنند که برای آنها معنادار است. توسعه با شناسایی موارد استفاده آغاز می شود و در هر مرحله با درجه نزدیکی به اجرای آنها کنترل می شود.

• تصمیم اصلی اتخاذ شده در طول پروژه این است معماریسیستم نرم افزاری حاصل معماری مجموعه ای از مؤلفه هایی را که نرم افزار از آنها ساخته می شود، مسئولیت های هر مؤلفه (یعنی وظایف فرعی که در چارچوب وظایف کلی سیستم حل می کند) ایجاد می کند، به وضوح رابط هایی را که از طریق آنها می توانند تعامل داشته باشند، تعریف می کند. و همچنین نحوه تعامل اجزا با یکدیگر.

  معماری هم مبنای دستیابی به نرم افزار با کیفیت است و هم مبنای برنامه ریزی کار و برآورد پروژه از نظر زمان و منابع مورد نیاز برای دستیابی به نتایج معین. به شکل یک مجموعه می آید مدل های گرافیکیدر زبان UML

• اساس فرآیند توسعه است برنامه ریزی شدهو تکرارهای هدایت شده، که محدوده آن (عملکرد پیاده سازی شده در تکرار و مجموعه اجزاء) بر اساس معماری تعیین می شود.

فرآیند یکپارچه(UP) تعمیم یافته است قابفرآیندی که می تواند برای طیف وسیعی از سیستم های نرم افزاری، حوزه های کاربردی مختلف، سطوح مهارت و اندازه پروژه تخصصی شود.

فرآیند یکپارچه جزء گرااین بدان معناست که سیستم نرم افزاری ایجاد شده بر اساس نرم افزار ساخته شده است اجزاء, توسط رابط های به خوبی تعریف شده متصل می شوند.

جنبه های خاص UP در سه ویژگی آن نهفته است:

● توسط موارد استفاده هدایت می شود.

● دارای جهت گیری معماری است.

● تکراری و افزایشی است .

چرخه حیات فرآیند یکپارچه

چرخه عمر UP به چرخه هایی تقسیم می شود که هر یک از آنها با تحویل یک محصول به اوج خود می رسد. هر چرخه توسعه شامل چهار مرحله است - تجزیه و تحلیل و برنامه ریزی نیازمندی ها، طراحی، ساخت، اجرا. هر مرحله به تکرار تقسیم می شود.

UP شامل هشت گردش کار است: پنج اصلی- تعریف نیازمندی ها، تجزیه و تحلیل، طراحی، اجرا، آزمایش و سه مورد کمکی (برای پشتیبانی از موارد اصلی) - مدیریت پیکربندی و تغییر نیازمندی ها، مدیریت پروژه، مدیریت محیط.

برای تعریف ساختار گردش کار، ابتدا باید تعیین کنید که چیست انواع مجریاندر فرآیند شرکت کنند. سپس مشخص شد مصنوعات، که باید طی یک گردش کاری معین توسط هر نوع کارگر ایجاد شود.

18. XP یک فرآیند است.

برنامه نویسی افراطی(به انگلیسی: Extreme Programming, XP) یکی از متدولوژی های توسعه نرم افزار انعطاف پذیر است. نویسندگان روش شناسی کنت بک، وارد کانینگهام، مارتین فاولر و دیگران هستند.

دوازده تکنیک اصلی برنامه نویسی افراطی (طبق ویرایش اول کتاب برنامه نویسی افراطی توضیح داده شده) را می توان در چهار گروه ترکیب کرد:

1. چرخه بازخورد کوتاه (بازخورد در مقیاس خوب)

آ. توسعه آزمایش محور

ب بازی برنامه ریزی

ج مشتری همیشه در نزدیکی است (کل تیم، مشتری در محل)

د برنامه نویسی جفتی

2. فرآیند پیوسته به جای دسته ای

آ. یکپارچه سازی مداوم

ب Refactoring (بهبود طراحی، Refactor)

ج انتشارهای کوچک مکرر

3. تفاهم مشترک بین همه

آ. سادگی (طراحی ساده)

ب ارتباط

ج توجه

د مالکیت کد جمعی یا الگوهای طراحی انتخابی (مالکیت الگوهای جمعی)

ه. استاندارد کدنویسی یا قراردادهای کدگذاری

4. رفاه برنامه نویس:

آ. هفته کاری 40 ساعته (سرعت پایدار، چهل ساعت در هفته)

در XP، فرآیند در مقایسه با فرآیندهای زمان بندی شده به مراحل بسیار کوچک تقسیم می شود. این باعث می شود اولین قدم ها به جای ماه ها یا حتی سال ها برای هر مرحله در مدل آبشار روزها یا هفته ها طول بکشد. ابتدا، تست های خودکار برای توصیف اهداف توسعه نوشته می شوند. سپس کد نویسی می آید که در لحظه ای که تمام تست ها رد می شوند و برنامه نویسان نمی توانند تست های جدیدی ارائه دهند به پایان می رسد. طراحی توسط همان افرادی که کد می نویسند انجام می شود. (فقط آخرین مرحله - اتصال طراحی و کد - برای همه فرآیندهای چابک مشترک است). یک سیستم ناتمام اما کارآمد به دایره باریکی از کاربران نشان داده می شود (اغلب اینها خود توسعه دهندگان هستند). در این مرحله، آنها شروع به نوشتن تست برای بخش مهم بعدی سیستم می کنند.

19. ICONIX یک فرآیند است.

ICONIX توسط داگ روزنبرگ در نرم افزار ICONIXفرآیند ICONIX مبتنی بر موارد استفاده است، اما بسیاری از معایب آن را ندارد. این فرآیند همچنین از زبان مدل‌سازی UML استفاده می‌کند، اما فقط از نماد اولیه UML استفاده می‌شود - این 20٪ از زبان است. فرآیند ICONIX بر اساس چهار مرحله اصلی توسعه نرم‌افزار مبتنی بر استفاده است:

● مدل سازی دامنه.

● مدل سازی سوابق.

● تجزیه و تحلیل مناسب بودن نیازمندی ها (بررسی اینکه همه الزامات عملکردی برآورده شده اند).

● ساخت نمودارهای توالی.

مراحل اصلی فرآیند به شرح زیر است:

● تجزیه و تحلیل نیازمندی ها

● طراحی اولیه

● طراحی

● پیاده سازی

این فرآیند مبتنی بر ساخت حداقل تعداد مدل هایی است که سیستم آینده را منعکس می کند. در مرحله تجزیه و تحلیل، مدل‌های مورد استفاده، یک مدل رابط کاربر و یک مدل موجودیت دامنه ایجاد می‌شوند. در مرحله طراحی اولیه، یک نمودار استحکام ایجاد می شود. مدل قبلی و مدل موجودیت دامنه نیز تکمیل می شوند. در مرحله طراحی دقیق، یک نمودار توالی (SequenceDiagram) ایجاد می شود و یک نمودار کلاس ایجاد می شود. در مرحله پیاده سازی، کد منبع ایجاد می شود. شما همچنین می توانید یک نمودار استقرار و یک نمودار جزء ایجاد کنید. هر مرحله به نقطه عطف بازبینی ختم می شود که در آن نمودارهای تولید شده باید با همکاران مورد بحث قرار گیرند.

20. SCRUM یک فرآیند است.

اسکرام مجموعه ای از اصولی است که فرآیند توسعه بر اساس آنها ساخته شده است و امکان دوره های زمانی کوتاه مدت مشخصی را فراهم می کند. دوی سرعتاز 2 تا 4 هفته) نرم افزار کار با ویژگی های جدید که بالاترین اولویت را دارند در اختیار کاربر نهایی قرار دهد. قابلیت‌های نرم‌افزار برای پیاده‌سازی در اسپرینت بعدی در ابتدای اسپرینت در مرحله برنامه‌ریزی تعیین می‌شوند و نمی‌توانند در کل مدت آن تغییر کنند. در عین حال، مدت زمان کوتاه کاملاً ثابت دوی سرعت به فرآیند توسعه قابل پیش بینی و انعطاف پذیری می دهد.

نقش های اصلی بازیگری در اسکرام: ScrumMaster- کسی که رهبری می کند اسکرامتجمع می کند و تضمین می کند که همه اصول رعایت می شود اسکرام(نقش دلالت بر چیزی جز رفتار صحیح ندارد اسکرام-آه، مدیر پروژه بیشتر به آن اشاره می کند مالک محصولو نباید باشد ScrumMaster);مالک محصول (مالک محصول) - شخصی که منافع کاربران نهایی و سایر طرف های علاقه مند به محصول را نمایندگی می کند. و متقابل عملکردی است تیم (تیم اسکرام، متشکل از توسعه دهندگان و آزمایش کنندگان، معماران، تحلیلگران و غیره (با اندازه تیم ایده آل 2±7 نفر است). این تیم تنها شرکت کننده کاملاً درگیر در توسعه است و مسئولیت نتیجه را به عنوان یک کل واحد بر عهده دارد. هیچ کس به جز تیم نمی تواند در روند توسعه در طول اسپرینت دخالت کند.

در طول هر اسپرینت، رشد عملکردی نرم افزار ایجاد می شود. مجموعه ویژگی هایی که در هر اسپرینت ارائه می شوند از مرحله ای به نام می آیند عقب ماندگی محصول(مستندسازی درخواست های کاری) دارای بالاترین اولویت از نظر سطح الزامات کاری است که باید تکمیل شود. درخواست کار ( اقلام عقب مانده) در سراسر تعیین می شود شورای برنامه ریزی سرعت (جلسه برنامه ریزی اسپرینت، به مرحله اسپرینت منتقل می شوند. در طول این جلسه، مالک محصول وظایفی را که باید تکمیل شوند، در میان می گذارد. سپس تیم تعیین می‌کند که چه مقدار از آنچه را که می‌خواهد برای تکمیل قسمت‌های مورد نیاز در طول سرعت بعدی انجام دهد. در طول یک اسپرینت، تیم یک لیست ثابت مشخص از وظایف (به اصطلاح. عقب ماندگی سرعت). در طول این دوره، هیچ کس حق ندارد لیست الزامات شغلی را تغییر دهد، که باید به عنوان الزامات انجماد درک شود ( الزامات) در طول دوی سرعت.

مصنوعات

عقب ماندگی محصولسندی است که شامل فهرستی از الزامات عملکردی است که بر اساس اهمیت مرتب شده اند. بک لاگ محصول فهرستی از مواردی است که باید تحویل داده شود. موارد موجود در این لیست "داستان" نامیده می شوند ( داستان کاربر) یا عناصر عقب مانده ( اقلام عقب مانده). بک لاگ محصول برای همه شرکت کنندگان در فرآیند اسکرام برای ویرایش باز است.

معرفی

فرآیند یکپارچه منطقی (RUP) یکی از متدولوژی های توسعه نرم افزار مارپیچی است. این روش توسط نرم افزار Rational پشتیبانی می شود و محصول تقریباً دو بار در سال به روز می شود. به عنوان یک زبان مدل سازی در پایه مشترکدانش، زبان مدلسازی یکپارچه (UML) استفاده می شود.

توسعه نرم افزار تکراری در RUP شامل تقسیم یک پروژه به چندین پروژه کوچک است که به صورت متوالی انجام می شوند و هر تکرار توسعه به وضوح توسط مجموعه ای از اهداف تعریف می شود که باید در پایان تکرار به دست آیند. تکرار نهایی فرض می کند که مجموعه اهداف تکرار باید دقیقاً با مجموعه اهداف مشخص شده توسط مشتری محصول مطابقت داشته باشد، یعنی همه الزامات باید برآورده شوند.

RUP کاملاً رسمی شده است و بیشترین توجه به مراحل اولیه توسعه پروژه - تجزیه و تحلیل و مدل سازی است. بنابراین، این روش با هدف کاهش خطرات تجاری (کاهش ریسک) با شناسایی خطاها در مراحل اولیه توسعه است. ریسک‌های فنی در اوایل چرخه توسعه ارزیابی و اولویت‌بندی می‌شوند، و سپس در طول زمان و با تکامل پروژه از طریق تکرارهای بعدی بازنگری می‌شوند. بسته به اولویت های این ریسک ها، اهداف جدید ظاهر می شوند. نسخه‌های منتشر شده به گونه‌ای توزیع می‌شوند که ابتدا به ریسک‌های دارای اولویت پرداخته می‌شوند.

این فرآیند شامل تکامل مدل ها می شود. یک تکرار از چرخه توسعه به طور منحصر به فرد با نسخه خاصی از مدل نرم افزار مطابقت دارد. هر تکرار (گردش کار) شامل عناصر مدیریت چرخه عمر نرم افزار است: تجزیه و تحلیل و طراحی (مدل سازی)، پیاده سازی، یکپارچه سازی، آزمایش، پیاده سازی. از این نظر، RUP پیاده سازی مدل مارپیچی است، اگرچه اغلب به صورت نمودار جدولی نشان داده می شود. در زیر اجزای اصلی فرآیند را ارائه می کنیم.

برای روند موفقتوسعه به سه جزء نیاز دارد (شکل 1): یک فرآیند، یک نماد و مجموعه ای از ابزارها. یک فرآیند توصیف می کند که ما چه کاری انجام می دهیم، به چه ترتیب و به چه روشی. نشانه گذاری وسیله ارتباطی است. مجموعه ای از ابزارهای کمکی به خودکارسازی و مدیریت فرآیند کمک می کند.

برنج. 1. مثلث موفقیت

RUP شامل هر سه جزء است. ابتدا اجازه دهید به توابع نمادگذاری که کارهای زیر را انجام می دهند نگاه کنیم:

فرآیند "چسباندن" را در یک کل واحد انجام می دهد.

ابزاری مبتنی بر زبان برای تصمیم گیری است که از کد منبع مشخص نیست.

معناشناسی را برای نشان دادن تصمیمات استراتژیک و تاکتیکی مهم ارائه می دهد.

فرمی را ارائه می دهد که برای بازتاب و سپس تصمیم گیری و روش های خودکارسازی فرآیند به منظور دستکاری داده های رسمی شده کافی باشد.

در واقع، نماد توسعه نرم افزار، از تجزیه و تحلیل تا اجرای محصول را پوشش می دهد. علامت گذاری در مورد RUP-UML یک زبان رسمی برای توصیف یک فرآیند است (UML در زیر مورد بحث قرار خواهد گرفت). در مرحله بعد، ساختار فرآیند را در نظر خواهیم گرفت و همچنین مجموعه ای از ابزارهای مورد استفاده در فرآیند مدیریت توسعه پروژه را طبق RUP ارائه خواهیم داد.

ساختار RUP

UP یک رویکرد ساختاریافته برای توسعه نرم‌افزار تکراری ارائه می‌کند و فرآیند را در طول زمان به چهار نقطه عطف تقسیم می‌کند: آغاز، توسعه، ساخت و گذار. متأسفانه، هیچ اصطلاح ثابتی در زبان روسی وجود ندارد، بنابراین در آینده از اصطلاحات انگلیسی همراه با ترجمه آنها به روسی استفاده خواهیم کرد. در شکل شکل 2 یک تصویر پرکاربرد از فازهای RUP است. اهداف هر یک از این مراحل عبارتند از:

درک اولیه آنچه که ما ایجاد می کنیم. مرحله جمع آوری اطلاعات و تجزیه و تحلیل الزامات، تعریف تصویر پروژه به عنوان یک کل؛

تفصیل درک چگونگی ایجاد آن. تجزیه و تحلیل نیازمندی ها و مرحله طراحی سیستم، برنامه ریزی فعالیت ها و منابع مورد نیاز، مشخصات عملکردها و ویژگی های طراحی.

ساخت و ساز یک نسخه بتا از محصول. مرحله اصلی توسعه و کدگذاری، ساخت محصول به عنوان یک دنباله صعودی از تکرارها (نسخه های کد).

ایجاد انتقال نسخه نهایی محصول. مرحله معرفی محصول، تحویل محصول به یک کاربر خاص.

برنج. 2. مراحل RUP

اینها مراحل مدیریت تکامل محصول - تکرار چرخه عمر هستند. RUP شامل نزدیک شدن به هدف نهایی است، اما بر خلاف استاندارد کلاسیک ISO (روش آبشار)، که در آن انتقال فاز نهایی است، هر مرحله می تواند چندین بار تکرار شود، که منعکس کننده تغییرات در نیازهای مشتری برای محصول است.

متدولوژی RUP بر اساس نه گردش کار اصلی است که عناصری از تکرار چرخه عمر نرم افزار هستند:

مدل سازی کسب و کار (تحلیل کسب و کار) - شامل تجزیه و تحلیل الزامات در یک تکرار معین از چرخه عمر، تعیین پارامترهای سیستم مورد نظر و نیازهای کاربر است.

الزامات رسمی سازی تصویر سیستم. شامل جمع آوری و مدیریت نیازمندی ها، تبدیل نیازمندی ها به مشخصات عملکردی است. در اینجا تجزیه و تحلیل سوابق و ساخت موارد استفاده (داستان های کاربری) نگاشت رسمی نیازهای کاربر در UML آغاز می شود. نتیجه اسناد سطح مدیریت است.

تجزیه و تحلیل و طراحی (تحلیل و مدل سازی) - شامل ترجمه نیازمندی های جمع آوری شده به یک مدل نرم افزاری رسمی است. نتیجه توصیفی از سیستم در مرحله پیاده سازی است ( پروژه فنی) اسنادی در سطح توسعه دهندگان سیستم هستند. زبان رسمی سازی Unified Modeling Language (UML) است که در زیر مورد بحث قرار خواهد گرفت. در فرآیند توسعه تکراری، محصول این جریان خاص - مدل پروژه - تکامل خواهد یافت. تمام تغییرات در RUP مستقیماً به مدل ها گره خورده است و ابزارهای اتوماسیون و یک زبان مدل سازی نسبتاً انعطاف پذیر به شما این امکان را می دهد که این فرآیند را از نظر زمان و منابع کم و بیش بدون دردسر مدیریت کنید. این به این واقعیت اشاره دارد که نتیجه توسعه یک مدل نیست، بلکه کد قابل اجرا است، بنابراین مشتری معمولاً دوست ندارد برای مدل‌سازی هزینه بپردازد، زیرا مدل‌ها محصول مورد نیاز او نیستند).

پیاده سازی (پیاده سازی، کدگذاری) - در واقع شامل نوشتن کد است. عناصر کد در RUP قبلاً در مرحله تجزیه و تحلیل و طراحی ایجاد شده اند، زیرا ابزار پیاده سازی UML - Rational Rose - به شما امکان می دهد عناصر کد را در چندین زبان برنامه نویسی ایجاد کنید. روش شناسی - برنامه نویسی شی گرا.

تست شامل آزمایش محصول در یک تکرار معین است. شایان ذکر است که تست رگرسیون (تست بازگشت، آزمایش "عدم خراب شدن" محصول) در این مورد باید شامل تمام آزمایش های فعلی از تکرار قبلی و آزمون های پذیرش از مرحله انتقال قبلی باشد.

استقرار (پیاده سازی) شامل نصب محصول در سایت مشتری، آموزش پرسنل، راه اندازی سیستم به علاوه تست های پذیرش، تهیه استانداردهای بسته بندی و توزیع محصول، انتقال مواد به بخش فروش است (اقدامات بسته به مشخصات محصول اختیاری است. ).

عناصر فوق از نظر چرخه عمر توسعه نرم افزار جدید نیستند، زیرا تقریباً در هر روشی رخ می دهند - شاید به استثنای XP (که با این وجود به شکلی بسیار اصلی ارائه می شوند). یکی از ویژگی‌های پیاده‌سازی RUP تأکید زمانی است، یعنی اینکه در آن تکرار رشته‌های خاصی غالب خواهند بود، و همچنین وجود یک زبان جهانی و مجموعه‌ای از ابزارها که به فرد اجازه می‌دهد فرآیند توسعه را توصیف کند. همانطور که در شکل می بینیم. 2، در مراحل اولیه تکامل محصول، توجه اصلی به رسمی سازی پروژه (تجزیه و تحلیل، مدل سازی) است که با هدف کاهش ریسک های تجاری و کاهش هزینه خطاهای طراحی انجام می شود. زمانی که تصویر کم و بیش واضح باشد، توسعه واقعی، آزمایش و در نهایت اجرای محصول آغاز می شود.

مقدماتی داخلی اینها در واقع اسنادی هستند که توسط شورای فنی برای مدیران شرکت صادر شده است. هدف اصلی مراحل اولیه انعقاد قرارداد یا تعهدنامه است. تکرارهای بیشتر شروع واقعی کار تیم توسعه است که زمان و منابع لازم برای ساخت مدل های رسمی را دارد. UML در این مورد دارای ابزارهایی است که به شما امکان می دهد مدل را روی عناصر کد نگاشت کنید. به عنوان مثال، درختی از اشیا به طور مستقیم نمایش داده می شود، تغییرات به قدرت پیاده سازی زبان برنامه نویسی انتخاب شده توسط توسعه دهندگان و همچنین به همزمانی دیدگاه های G. Butch و توسعه دهندگان این زبان در مورد مدل شی بستگی دارد. . همین امر در مورد روش ها نیز صدق می کند.

حالا بیایید به عناصر مربوط به پشتیبانی محصول - گردش کار پشتیبانی اصلی نگاه کنیم:

مدیریت پیکربندی (مدیریت پیکربندی و تغییر) یک لایه قدرتمند از اقدامات اداری با هدف مدیریت نسخه‌های محصول است که شامل کنترل کد منبع (مدل، ماژول‌های اجرایی، آزمایش‌ها، مستندات)، کنترل نسخه محصول، استانداردهای شرکتی برای توسعه کد و مستندسازی است. ردیابی تغییرات و خطاها (ردیابی اشکال)؛ ارتباط نزدیک با تست و پشتیبانی مشتری؛

مدیریت (مدیریت پروژه) - شامل مجموعه ای از اقدامات اداری برای مدیریت پروژه مطابق با ایدئولوژی RUP است، از ابزارهای مدیریت پروژه استفاده می شود (برای لیستی از محصولات Rational به زیر مراجعه کنید).

محیط زیست شامل ایجاد و نگهداری است ابزار تجزیه و تحلیل، طراحی، توسعه، تست (هم نرم افزار و هم سخت افزار).

توسعه تکراری؛

مدیریت نیازمندی ها؛

استفاده از معماری های مدولار؛

مدل سازی بصری؛

بررسی کیفیت؛

تغییرات مسیر.

این روش‌ها مستقیماً بخشی از فرآیند RUP نیستند، اما به شدت توصیه می‌شوند. برخی از شیوه ها مستقیماً از ایدئولوژی RUP پیروی می کنند. بنابراین، توسعه تکراری در ساختار RUP ساخته شده است، زیرا این فرآیند یکی از پیاده سازی های "مارپیچ" است. مدیریت نیازمندی ها در RUP در اولین مراحل تحلیل ظاهر می شود. در تئوری، معماری مدولار امکان استفاده مجدد از کد را فراهم می کند و سیستم را انعطاف پذیرتر می کند. با توجه به اینکه UML یک زبان شی است، می توان ماژولار بودن را نادیده گرفت، اما ... تا حدودی دشوار است. مدل سازی بصری به شما این امکان را می دهد که به طور موثر با افزایش پیچیدگی سیستم ها مقابله کنید. علاوه بر این، مدل‌ها وسیله‌ای برای ارتباط بین توسعه‌دهندگان هستند، اما برای این منظور، توسعه‌دهندگان باید UML صحبت کنند که نیاز به آموزش دارد. مدل‌سازی بصری اغلب با استفاده از ابزار Rational Rose انجام می‌شود، که به شما امکان می‌دهد مجموعه‌ای از اسناد بسیار مفید را برای مدیران، مدیران سیستم، توسعه‌دهندگان، آزمایش‌کنندگان و تولید عناصر کد به دست آورید. این ابزار تنها پیاده سازی UML نیست - هر دو جایگزین تجاری (به عنوان مثال، Microsoft Visio) و موارد رایگان در دسترس هستند. لازم به ذکر است که گویش‌های UML پیاده‌سازی شده در ابزارهای مدل‌سازی همیشه یکسان نیستند: گویش Rational تفاوت‌های عمده‌ای دارد که هم در مستندات و هم در کتاب‌های UML توضیح داده شده است.

محصولاتی که از RUP پشتیبانی می کنند

محصولات زیر شناخته شده ترین محصولاتی هستند که از فرآیند یکپارچه منطقی پشتیبانی می کنند:

ابزار مدل‌سازی تصویری Rational Rose CASE سیستم های اطلاعاتی، که قابلیت تولید عناصر کد را دارد. نسخه ویژه محصول Rational Rose RealTime به شما امکان می دهد یک ماژول اجرایی را به عنوان خروجی دریافت کنید.

ابزار مدیریت نیازهای Rational Requisite Pro که به شما امکان می دهد تغییرات مورد نیاز را ایجاد، ساختار، اولویت بندی، پیگیری و کنترل کنید که در هر مرحله از توسعه اجزای برنامه ایجاد می شود.

Rational ClearQuest محصولی برای مدیریت تغییرات و ردیابی عیوب در یک پروژه (ردیابی اشکال)، کاملاً یکپارچه با تست و ابزارهای مدیریت نیازمندی‌ها و ارائه یک محیط واحد برای پیوند کلیه خطاها و اسناد با یکدیگر.

محصول SoDA منطقی برای تولید خودکار اسناد پروژه، به شما امکان می دهد یک استاندارد شرکتی برای اسناد داخلی تنظیم کنید. همچنین می توان اسناد را به استانداردهای موجود (ISO، CMM) رساند.

Rational Purify، Rational Quantify Rational PureCoverage، - ابزارهای تست و رفع اشکال:

Rational Purify یک ابزار بسیار قدرتمند برای یافتن اشکال در زمان اجرا برای برنامه نویسی برنامه نویسان برنامه و کامپوننت در C/C++ است.

ابزار سنجش عملکرد Rational Visual Quantify برای برنامه نویسی برنامه نویسان برنامه و کامپوننت در C/C++، Visual Basic و Java. به شناسایی و رفع تنگناها در عملکرد نرم افزار کمک می کند،

Rational Visual PureCoverage - به طور خودکار مناطقی از کد را که آزمایش نمی شوند شناسایی می کند.

Rational ClearCase محصولی برای مدیریت پیکربندی نرم افزار (Rational's Software Configuration Management، SCM) است که امکان کنترل نسخه تمام اسناد پروژه را فراهم می کند. با کمک آن، می توانید چندین نسخه از پروژه ها را به طور همزمان پشتیبانی کنید و به سرعت بین آنها سوئیچ کنید. Rational Requisite Pro از به روز رسانی ها پشتیبانی می کند و تغییرات در الزامات تیم توسعه را دنبال می کند.

ابزار اتوماسیون تست SQA TeamTest.

سیستم مدیریت آزمون Rational TestManager که تمامی ابزارها، مصنوعات، اسکریپت ها و داده های مربوط به آزمون را گرد هم می آورد.

ابزار Rational Robot برای ایجاد، اصلاح و اجرای خودکار تست ها.

SiteLoad، SiteCheck ابزار برای تست عملکرد وب سایت ها و وجود لینک های شکسته.

Rational PerformanceStudio - ویژگی های عملکرد سیستم را اندازه گیری و پیش بینی می کند.

مصنوعات و نقش ها

بخشی جدایی ناپذیر از RUP مصنوعات، سوابق و نقش ها هستند. مصنوعات برخی از محصولات یک پروژه هستند که در حین کار بر روی محصول نهایی تولید یا در پروژه مورد استفاده قرار می گیرند. موارد استفاده دنباله ای از اقداماتی هستند که توسط سیستم برای به دست آوردن یک نتیجه قابل مشاهده انجام می شود. در واقع، هر نتیجه ای از کار یک فرد یا گروه یک مصنوع است، خواه یک سند تجزیه و تحلیل، یک عنصر مدل، یک فایل کد، یک اسکریپت آزمایشی، یک شرح یک باگ و غیره باشد. متخصصان خاصی مسئول ایجاد یک یا نوع دیگری از مصنوعات هستند. بنابراین، RUP به وضوح مسئولیت های هر یک از اعضای تیم توسعه را در یک مرحله یا مرحله دیگر مشخص می کند، یعنی چه زمانی و چه کسی باید این یا آن مصنوع را ایجاد کند. کل فرآیند توسعه یک سیستم نرم افزاری در RUP به عنوان فرآیند ایجاد مصنوعات در نظر گرفته می شود - از اسناد تجزیه و تحلیل اولیه تا ماژول های اجرایی، کتابچه راهنمای کاربر و غیره. در زیر مجموعه ای از مصنوعات (مدل ها، اسناد و غیره) برای هر یک از جریان ها آورده شده است.

مدل سازی کسب و کار

مدل فرآیند کسب و کار تعیین الزامات تجاری برای سیستم در حال توسعه؛

مدل ساختار سازمانی - مصنوع برای توسعه یک مدل عملکردی سیستم.

مدل های اسناد، نهادهای تجاری، مدل های سناریوهای عملکردهای تجاری، مدل های وضعیت نهادهای تجاری - برای طراحی رابط کاربری، سیستم پایگاه داده؛ شرح حالات ایستا و پویا سیستم را از دیدگاه های مختلف نشان می دهد.

Business Rule Models Artifact برای مدل سازی قوانین در نرم افزار استفاده می شود.

مصنوعات سند مورد استفاده توسط RequisitePro، SoDA، واژه پردازها، پروژه مایکروسافت:

ارزیابی سازمان مشتری، ساختار کسب و کار؛

فرهنگ اصطلاحات حوزه موضوعی؛

مجموعه ای از قوانین تجاری؛

پیشنهاد تجاری;

مشخصات عملکرد تجاری؛

برنامه کاری در مرحله مدل سازی کسب و کار؛

تغییر درخواست ها

الزامات

مدل های مصنوع مورد استفاده توسط Rational Rose:

مدل عملکرد سیستم؛

مدل سناریوی عملکرد سیستم;

مدل رابط کاربری؛

مدل سناریوهای کاربر سیستم;

مدل فرم های خروجی;

مدل قوانین سیستم

طرح مدیریت نیازمندی ها؛

فرهنگ اصطلاحات سیستمی;

مشخصات برای سیستم نرم افزاری;

مشخصات عملکردهای سیستم؛

قوانین سیستم؛

سوالات ذینفعان؛

برنامه کاری در مرحله تعیین الزامات سیستم؛

تغییر درخواست ها

تحلیل و طراحی

مدل های مصنوع مورد استفاده توسط Rational Rose:

مدل داده های منطقی;

مدل داده های فیزیکی؛

مدل مشخصات اجزای سیستم;

سناریوهای تعامل بین کلاس هایی که اجزای سیستم را پیاده سازی می کنند.

مصنوعات سند مورد استفاده توسط RequisitePro، SoDA، پردازشگرهای کلمه، MS Project:

معماری نرم افزار؛

مشخصات اجزای نرم افزار;

برنامه کاری در مرحله تحلیل و طراحی؛

تغییر درخواست ها

پیاده سازی

مدل های مصنوع مورد استفاده توسط Rational Rose:

مدل کاربردی کامپوننت

مصنوعات-کد استفاده شده توسط Rational Rose، ابزارهای برنامه نویسی، واژه پردازها:

عناصر تولید کد منبع از Rational Rose.

کد برنامه واقعی؛

مستندات.

مصنوعات سند مورد استفاده توسط RequisitePro، SoDA، پردازشگرهای کلمه، MS Project:

برنامه ساخت اپلیکیشن؛

برنامه کاری در مرحله اجرا

تست

مدل های مصنوع مورد استفاده توسط Rational Rose:

مدل مورد آزمایشی؛

مدل عملکردی برنامه آزمون؛

مدل مشخصات اجزای برنامه تست;

سناریوهایی برای تعامل کلاس هایی که تعامل مؤلفه های برنامه آزمایشی را اجرا می کنند.

شرح موارد آزمایشی؛

طرح تست؛

برنامه کاری برای مرحله آزمایش؛

تغییر درخواست ها

اجرای آزمایش Quantify، Purify، PureCoverage، Robot، SiteLoad، SiteCheck.

گسترش

مدل های مصنوع مورد استفاده توسط Rational Rose:

توصیف مدل قرارگیری از قرار دادن اجزا در گره های پردازش.

مصنوعات سند مورد استفاده SoDA، واژه پردازها، MS Project:

مطالب آموزشی؛

اسناد نصب؛

شرح نسخه های سیستم؛

طرح پیاده سازی.

مقاله بعدی این مجموعه به زبان مدلسازی یکپارچه (UML) اختصاص خواهد داشت.