مطابق با GOST 34.601-90 "AS. مراحل ایجاد" مراحل زیر را برای ایجاد یک AIS ایجاد می کند که به نوبه خود می تواند به مراحل تقسیم شود:

· تشکیل الزامات برای AIS.

· توسعه مفهوم AIS.

· وظیفه فنی؛

· طراحی اولیه;

· پروژه فنی;

· اسناد کاری؛

· راه اندازی.

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

هنگام استفاده از روش UML برای ایجاد نرم‌افزار AIS و پشتیبانی اطلاعات، پیشنهاد می‌شود مجموعه‌ای از مدل‌های به هم پیوسته ایجاد شود که ویژگی‌های استاتیک و دینامیکی سیستم آینده را منعکس می‌کند:

· مدل مورد استفاده؛

· مدل تحلیل؛

· مدل طراحی؛

· مدل استقرار؛

· مدل پیاده سازی؛

· مدل تست.

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

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

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

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

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

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

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

1.5 اجزای زبان UML

UML زبان مدلسازی یکپارچه(Unified Modeling Language) یک زبان مدلسازی بصری است که برای تعیین، تجسم، پیکربندی و مستندسازی سیستم های پیچیده (از جمله نرم افزار) با استفاده از فناوری شی گرا.

هنگام ایجاد یک AS در روش UML، از اصول تجزیه و تحلیل سیستم ساختاری شناخته شده از روش های Hein/Sarson و SADT استفاده می شود:

· توسعه مرحله به مرحله از بالا به پایین.

· تکنیک نمودار.

· سلسله مراتب توصیفات.

· رسمی سازی دقیق شرح راه حل های طراحی.

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

· مدلسازی مفهومی از نظر حوزه موضوعی برای درک مشتری از طراحی سیستم.

· پشتیبانی فن آوری با ابزار (سیستم های CASE).

یک مدل از یک سیستم پیچیده در UML را می توان برای به دست آوردن ویژگی های تخمینی کارایی فرآیندها در سیستم مطالعه کرد.

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

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

-ایستا(ساختاری) - ترکیب، ساختار اجزاء و روابط آنها.

-پویا(رفتاری) - توصیف منطق فرآیندهای رخ داده در سیستم یا اجرا شدن.

روش اصلی نمایش مدل‌های اتخاذ شده در UML، نمودارهایی است که با اطلاعات متنی، از جمله عبارات در زبان محدودیت داخلی OCL، و همچنین در زبان‌های برنامه‌نویسی و پرس و جوی اطلاعاتی که برای پیاده‌سازی سیستم استفاده می‌شوند، ارائه می‌شود.

اصل اساسی مدل‌سازی: یک سیستم به عنوان گروهی از اشیاء گسسته مدل‌سازی می‌شود که به گونه‌ای با یکدیگر تعامل دارند تا نیازهای کاربر را برآورده کنند.

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

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

مدل دارای دو جنبه است: اطلاعات معنایی (معناشناسی) و بازنمایی بصری (نشان گذاری).

ترکیب کامل نمایش های مدل در زبان UML در جدول 1 آورده شده است

جدول 1 - نمایش مدل های سیستم در UML.

متداول ترین مدل مفهومی یک سیستم، نمودار کاربرد مورد است؛ این نمودار نقطه شروعی برای ساختن نمودارهای دیگر است.

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

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

این زبان دارای 4 نوع ساختار گرافیکی است:

· نمادها (پیکتوگرام)؛

· نمادهای گرافیکی در یک هواپیما.

· مسیرها (خطوط)؛

· خطوط متن.

1.6 سطح مفهومی. از مدل موردی استفاده کنید

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

نمودار سطح بالا، نموداری است که توسط A. Jacobson در OOSE پیشنهاد شده است نمودار مورد استفادهسیستم ها به عنوان یک کل این است که بازنمایی مفهومی اولیه سیستم است و با این هدف ساخته شده است:

· تعیین مرزهای کلی و زمینه حوزه موضوعی مدل شده.

· فرم الزامات کلیبه رفتار عملکردی و رابط سیستم؛

· تهیه مستندات اولیه برای تعامل بین توسعه دهندگان و مشتریان - کاربران سیستم.

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

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

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

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

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

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

یک عامل را می توان به دو صورت در نمودارها نشان داد:

3. نماد کلاس (مستطیل) با نشانه داخلی کلیشه

4. استانداردتر: "مرد" با کتیبه (نماد یک شخص)

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

مشتری

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

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

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

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

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

نمودار مورد استفاده را به دو صورت نشان می دهد:

1) یک بیضی، یک نام در داخل قرار داده شده است

2) یک مستطیل - مانند هر کلاس

مشتری

سنسور

بین اکتانت ها و موارد استفاده، ارتباط تنها نوع ارتباط است. علاوه بر این، دارای معناشناسی است سوئیچینگ ارتباطات، یعنی ارسال پیام، بنابراین معمولاً علامت گذاری نمی شود زیرا زمینه از نماد فعال و استفاده از حروف بزرگ مشخص است. اما می توانید آن را علامت گذاری کنید و همچنین تعدد اتصال را نشان دهید:

مشتری بانک

کثرت(تعدد) تعداد نمونه های خاص یک کلاس را که در یک اتصال معین شرکت می کنند مشخص می کند (یک مشتری می تواند تعداد نامحدودی وام صادر کند).

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

نام انجمن، در صورت وجود، باید منحصر به فرد باشد. با توجه به معنای روابط بین طبقاتی که در انجمن شرکت می کنند شکل می گیرد. به عنوان مثال، "کارمند کار می کند در مدیر بخش کامل می کند کامپیوتر» و غیره

انجمن ها خودشان کلاس هستند ( کلاس انجمن، کلاس انجمن)، هم ویژگی کلاس و هم خصوصیات ارتباطی دارد. نمونه هایی از این کلاس اتصالاتی هستند که نه تنها به اشیا پیوند دارند، بلکه دارای مقادیر ویژگی (ویژگی) نیز هستند.

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

تعدد اتصالات در قطب ها نشان داده شده است.

اتصالات می توانند در طول عملکرد سیستم ظاهر شوند و ناپدید شوند؛ محدودیت ها و محمولات مربوطه را می توان در قطب های انجمن مشخص کرد.

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

یک انجمن به عنوان یک خط پیوسته نشان داده می شود که مرزهای 2 کلاس را به هم متصل می کند n-ary، سپس یک لوزی رسم می شود (نشانه ای از تجمع):

		بسیاری از انجمن ها - تجمع
	ارتباط باینری

موارد استفاده با یکدیگر پیام رد و بدل نمی کنند و فقط می توانند در روابط (اتصالات) باشند. پسوندها(توسعه دادن، گسترش) شمول(شامل) و تعمیم ها(تعمیم).

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

فرآیند یکپارچهتوسعه یافته توسط 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 ایجاد می‌شوند، که مدت‌هاست به استاندارد واقعی برای توصیف سیستم‌های پیچیده تبدیل شده است و به توسعه‌دهندگان اجازه می‌دهد تا مصنوعات سیستم‌های نرم‌افزاری را تعریف، تجسم، ساخت و مستند کنند. پیچیدگی

Rational Unified Process (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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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