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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rational Software Corporation (http://www.rational.com) یک پایگاه دانش ساختاریافته به نام Rational Unified Process (RUP) منتشر کرده است که مجموعه ای از توصیه های جامع برای ایجاد تقریباً هر محصول نرم افزاری است. با جذب تجربه بهترین پیشرفت ها، RUP با جزئیات می گوید چه زمانی، چه کسی و چه کاری باید در پروژه انجام دهد تا به نتیجه برسد. سیستم نرم افزاریبا مهلت های تعیین شده، با عملکرد معین و در چارچوب بودجه تخصیص یافته.

فرآیند یکپارچه را می توان به عنوان مجموع نشان داد انواع مختلففعالیت های شرکت توسعه برای تبدیل نیازهای مشتری به یک سیستم نرم افزاری ضروری است. سیستمی که «نتایج معنی‌داری» را برای کاربران فراهم می‌کند و دقیقاً همان چیزی را که از سیستم انتظار دارند انجام می‌دهد. بنابراین، فرآیند توسط موارد استفاده از سیستم، یا در غیر این صورت - سوابق کنترل می شود.

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

برنج. 1 فاز RUP و جریان کار

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

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

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

مدل‌ها به شما امکان می‌دهند سیستم آینده، اشیاء آن و تعامل آنها را حتی قبل از سرمایه‌گذاری قابل توجه در توسعه در نظر بگیرید؛ آنها به شما این امکان را می‌دهند که آن را از چشم کاربران آینده از بیرون و توسعه‌دهندگان از داخل، حتی قبل از اولین خط منبع ببینید. کد ایجاد می شود. بیشتر مدل‌ها با نمودارهای UML نشان داده می‌شوند؛ برای مثال، می‌توانید اطلاعات بیشتری درباره UML بخوانید.

زبان مدل سازی یکپارچه در اواخر دهه 80 و اوایل دهه 90 ظاهر شد، عمدتاً به لطف تلاش های "سه دوست" Gradi Bucha، Jim Rambo و Ivar Jacobson. اکنون توسط کنسرسیوم OMG به عنوان یک زبان مدل‌سازی استاندارد پذیرفته شده است که به توسعه‌دهندگان یک نماد واضح ارائه می‌دهد که به مدل‌ها اجازه می‌دهد در عناصر گرافیکی نمایش داده شوند که عموماً توسط همه افراد پروژه پذیرفته شده و قابل درک است.

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

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

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

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

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

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

1-تعریف الزامات

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

شکل 2. نمونه ای از نمودار مورد استفاده

نمودار انعکاسی از بازیگران (عملگران) است که با سیستم در تعامل هستند و واکنش اشیاء نرم افزار به اعمال آنها. Actants می توانند هم کاربران و هم عوامل خارجی باشند که نیاز به انتقال یا دریافت اطلاعات دارند. نماد use case پاسخ سیستم به ورودی خارجی را نشان می دهد و نشان می دهد که چه کاری باید برای فعال کننده انجام شود.

برای جزئیات یک مورد خاص، از نمودار فعالیت استفاده می شود که نمونه ای از آن در شکل 3 آورده شده است.

برنج. 3 نمونه ای از نمودار فعالیت

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

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

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

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

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

2. تجزیه و تحلیل

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

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

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

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

شکل 4. نمونه ای از نمودار همکاری

شماره گذاری پیام ها ترتیب آنها را نشان می دهد، اما هدف از نمودار در نظر گرفتن ترتیب پیام های رد و بدل شده نیست، بلکه به وضوح روابط کلاس ها را با یکدیگر نشان می دهد.

اگر روی ترتیب تعامل تمرکز کنیم، آنگاه یک نمایش دیگر یک نمودار توالی (Sequence) خواهد بود که در شکل 5 نشان داده شده است. هنگام استفاده از ابزار ایجاد مدل مانند Rational Rose، این دو نوع نمودار را می توان به طور خودکار از یکدیگر ایجاد کرد (برای مثال، می توانید اطلاعات بیشتری در مورد Rational Rose بخوانید).

برنج. 5 نمونه ای از نمودار توالی

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

3.طراحی

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

برای ایجاد یک مدل طراحی، از مجموعه کاملی از نمودارهای UML استفاده می شود: نمودارهای کلاس (شکل 5)، نمودارهای همکاری، نمودارهای تعامل، نمودارهای فعالیت.

شکل 6. نمونه ای از نمودار کلاس

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

4. پیاده سازی

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

برنج. 7 نمونه نمودار جزء

5-آزمایش

در طول فرآیند تست، نتایج پیاده سازی بررسی می شود. برای این فرآیند، یک مدل آزمایشی ایجاد می‌شود که شامل موارد تست، رویه‌های تست، اجزای آزمایشی است، اما نمایش نمودار UML ندارد، بنابراین ما روی آن تمرکز نمی‌کنیم.

6. نتیجه گیری

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

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

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

کراتچن. F. مقدمه فرآیند یکپارچه منطقی . اد. دوم - م.: انتشارات ویلیامز، 2002. - 240 ص: ill.

Jacobson A., Buch G., Rambo J. Unified software development process - St. Petersburg: Peter, 2002. - 496 pp.: ill.

Fowler M., Scott K. UML به طور خلاصه. کاربرد زبان مدلسازی شی استاندارد: Transl. از انگلیسی – م.: میر، 1378. – 191 ص.، بیمار.

بک E. برنامه نویسی شدید. – سن پترزبورگ: پیتر، 2002. – 224 ص: بیمار.

تروفیموف اس. فناوری های CASE: کار عملیدر رشنال رز.
اد. 2 - M.: Binom-Press, 2002 - 288 p.

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

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

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

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

(آ)

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

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

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

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

یک نمایش کامل از یک سیستم نرم افزاری در RUP شامل 9 مدل است که با هم تمام تصمیمات حیاتی در مورد تجسم، مشخصات، طراحی و مستندسازی یک سیستم نرم افزاری را پوشش می دهد (شکل 7.3):

1. مدل فرآیند کسب و کار، که انتزاع سازمان را رسمی می کند (با تمام گزینه های استفاده از سیستم مدیریت و ارتباط آنها با کاربران)؛

2. مدل مورد استفاده- الزامات عملکردی سیستم را رسمی می کند.

3. مدل دامنهیا مدل تجاری، زمینه سیستم را توصیف می کند.

4. مدل تحلیل، که دو هدف دارد - روشن کردن جزئیات موارد استفاده و ایجاد توزیع اولیه رفتار سیستم بر روی مجموعه ای از اشیاء که ارائه می کنند. گزینه های مختلفرفتار - اخلاق؛

5. مدل فرآیند(اختیاری) - مکانیسم های موازی و هماهنگ سازی را در سیستم رسمی می کند.

6. مدل طراحی، که تعریف می کند: ( آ) - ساختار ایستا سیستم، مانند زیر سیستم ها، کلاس ها و رابط ها، و ( ب) - موارد استفاده اجرا شده در فرم همکاری هابین زیرسیستم ها، کلاس ها و رابط ها؛

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

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

9. مدل تست، که موارد آزمایشی را برای تأیید موارد استفاده توصیف می کند.

برنج. 7.3.مدل های RUP (در قالب نمودارهای UML مربوطه)
و ارتباطات آنها،

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

تأکید اصلی در 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) اختصاص خواهد داشت.