کاربرد روش RAD در توسعه سیستم

1 - مقدمه مساله زمان در پروژه هاي سيستمهاي اطلاعاتي همواره از عوامل حساس وتعيين كننده بوده است . درصورت طولاني شدن زمان يك پروژه ، ممكن است پروژه باتغيير مديريت در سازمان كارفرما يا تغيير در اهداف مديريت مواجه شود كه اين مواردمي توانند بر موفقيت پروژه تاثير منفي بگذارند. ازطرف ديگر در بخش مجري يا كارگزار،طولاني شدن پروژه مي تواند باعث بالارفتن نرخ كارشناسي و درنتيجه افزايش هزينه پروژه گردد.
طولاني شدن زمان پروژه ازنظر تكنولوژي اطلاعات نيز مي تواند مساله ساز باشد. هرروز كه مي گذرد پايگاههاي داده ها، سيستمهاي عامل ، زبانهاي برنامه سازي و ابزارهاي مهندسي نرم افزار "CASE TOOLS"توسعه يافته وگونه هاي جديدي از آنهابه بازار مي آيد وچنانچه زمان پروژه طولاني گرددممكن است روشها، ابزارها،وپلاتفورم انتخابي پروژه توجيه پذيري خود را از دست بدهد.
به دليل مسائل فوق در سطح جهاني كوششهايي براي استفاده از روشها و ابزارهاي بهتر به منظور كاهش زمان ، هزينه و ريسك پروژه و افزايش قابليت اعتماد به سيستمهاي ساخته شده صورت گرفته است كه در مقاله حاضر خلاصه اي از آنها ارائه مي گردد.
درمقاله حاضر پس از مطرح كردن مسائل و مشكلات روشهاي سنتي ، روشهاي موسوم به FASTTRACK يا RAD همراه با شرايط بكارگيري موفقيت آميز آنها ارائه مي شوند.

ادامه نوشته

روش های مهندسی توسعه نرم افزار

به درخواست یکی از دوستان اندکی در مورد مدل های توسعه نرم افزار صحبت خواهیم کرد:

روش های مهندسی توسعه نرم افزار

با بزرگ شدن پروژه های نرم افزاری و پیشرفت علم مهندسی نرم افزار ، روش های سازمان یافته ای برای توسعه نرم افزارها ابداع شد که هر کدام بسته به نوع پروژه و محدودیت های آن در جای خاصی کاربرد دارد. برخی روش ها مانند R.A.D به دلیل کمبود زمان تولید، برخی مانند spiral به دلیل مشخص نبودن نیازمندی های اولیه نرم افزار و برخی مانند X.P برای کسانی که کار طراحی نرم افزار را با کدنویسی شروع میکنند ابداع شدند. ایجاد پروژه های بزرگ بدون بکارگیری یکی از روش های مهندسی نرم افزار ممکن نیست.
ادامه نوشته

فناوری نمونه سازی سریع

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

به طور کلی می توان مزیتهای فناوری نمونه سازی سریع را در موارد زیر خلاصه نمود:

 

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



مهمترین و کاربردی ترین روشهای نمونه سازی سریع عبارتند از:

Stereolithography (SLA)، Selective Laser Sintering (SLS®)، Laminated Object Manufacturing (LOM™)، Fused Deposition Modeling (FDM)، 3D PRINTING


آرشیتکت و معماری:

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

ماکت سازی:

فناوری نمونه سازی سریع به دلیل ساخت مستقیم از روی مدل طراحی شده در CAD ، امکان ساخت هر مدل و ماکت پیچیده ای را که بتوان آن را در یکی از نرم افزارهای SOLID WORK، CAD ، MECHANICAL DESKTOP و CATIA طراحی نمود را با دقیقترین جزیئات دارا می باشد.

پزشکی:

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

ساخت و تولید و قالب سازی :

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

صنعت جواهر سازی:

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

بازاریابی و کاربردهای تجاری:

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

درآمدي بر مدل‌سازي چابك (Agile Modeling)

  جکیده مطلب

مدل‌سازي چابك (Agile Modeling) رويكرد نسبتا جديدي است به توليد، به خصوص توليد نرم‌افزار. اساس اين رويكرد، چنان چه از نامش پيدا است، چابكي در تحليل، طراحي، ساخت و تست نرم‌افزار و هدف آن توليد نرم‌افزار با كيفيت است. در اين رويكرد، مدل‌سازي و مستندسازي تا اندازه‌اي توصيه مي‌شود كه مورد نياز و مفيد باشد، نه بيش از آن.

 

 اين ديدگاه، توليد مدل‌ها و مستندات را به صرف پيروي از يك متدولوژي يا چارچوب، مضر و اتلاف وقت مي‌داند.

 

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

 

 

 
  • پروژه کوچک است (تعداد افراد درگير 2 تا 30 نفر هستند)
  • مشتريان و توسع دهندگان نرم افزار در تماس مداوم با يکديگر هستند
  • ممکن است نيازمنديهاي در طول اجراي پروژه تغيير کند
  • قلمروي پروژه به طور کامل تعريف نشده است
  • مسئله پيچيده است


 

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


چه چیز یک روش توسعه را تبدیل به agile می کند؟
اگر توسعه نرم افزار به صورت
-
افزایشی (incremental) نشر های کوچک نرم افزاری با گردشهای سریع
-
مشارکتی (cooperative) کاربر و توسعه دهندگان با یک ارتباط نزدیک به صورت ثابت با یکدیگرکار می کنند
- 
سر راست (straight forward) خود روش برای یادگیری و تغییر دادن آسان می باشد و خوب مستند شده است
-
سازگار (adaptive)قابلیت تغییر پذیری در آخرین لحظات می باشد یعنی انطباق با شرایط
شود متدلوژی به صورت Agile در می آید

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

مدیریت: 
در متدلوژی های سنگین وزن مدیریت بصورت مطلق و استبدادی است در حالیکه مدیریت متدلوژی های سبک وزن بصورت غیر متمرکز و آزاد است که این مدیریت غیر متمرکز باعث تصمیم گیری بهتر برای این روش ها می شود.
نحوه مستند سازی :
یکی از عیب های متدلوژی های سنگین وزن مستند سازیهای سنگین می باشد که کار بسیار دشوار و زمانبری می باشد و باید بصورت جامع و کامل انجام شود (مثلا در Rup باید تمامی مستندات برای هر فاز بطور کامل تهیه شود) در حالیکه در متدلوژی های سبک وزن مستند سازی محدود وبسته به نیاز پروژه انجام می شود.
چرخه های توسعه :
در متدلوژی های سنگین وزن (Cycles) تعداد چرخه ها کم است ولی زمان آنها بسیار زیاد است بنابراین طولانی شدن چرخه ها موجب طولانی شدن زمان انتظار برای رسیدن به نشرها (Release) می شود و این برای کارفرماهای کم طاقت چیز جالبی نمی تواند باشد ! ولی در متدلوژی های سبک وزن چرخه ها بسیار زیاد است اما زمان آنها کوتاه است بنابراین اثر پروژه زودتر مشخص خواهد شد.
معیار موفقیت :
در متدلوژی های سنگین وزن معیار موفقیت در راستای طرح اولیه می باشد که در غیر این صورت پروژه به شکست و تحمل هزینه بر خواهد خورد ولی در متدلوژی های سبک وزن معیار موفقیت بر اساس ارزش کاری (Bussiness Value) مشخص می شود که این باعث انعطاف پذیری این متدلوژی ها می شود .در حالیکه در متدلوژی های سنگین وزن به دلیل همان طرح اولیه این انعطاف پذیری وجود ندارد.
اندازه تیم :
متدلوژی های سنگین وزن احتیاج به یک تیم بزرگ دارند که باید بر اساس تخصص خود در هر کدام از فازها باید عملیات مربوط به خود را انجام دهند که باعث دشوار شدن مدیریت فاز ها خواهد شد.در متدلوژی های سبک وزن اندازه تیم کوچک (حداکثر 30 نفر) می باشد که کوچکی تیم می تواند به بیشتر شدن خلاقیت و همکاری در تیم شود .
بازگشت سرمایه

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


سخن آخر

يك پروسه چابك، پروسه‌اي است كه هميشه آماده در آغوش كشيدن درخواستهاي جامعه بوده و اين درجه از سازگاري را دارا باشد. بنابراين منظور از سرعت عمل، فقط كاستن از حجم پروسه توليد نرم‌افزار يا سرعت ارائه آن به بازار نيست؛ بلكه منظور، انعطاف‌پذيري و حفظ کيفيت است.



انواع متدلوژی ها سبک وزن :
XP(Extreme Programming)
Scrum
Crystal Family
FDD(Feature Driven Development)
Dynamic System Development
Adaptive Software Development
Open Source Software Development
سعی خواهم کرد بعدا در مورد هر کدام از این روش ها بیشتر صحبت کنم .



متودولوژی SSADM

مقدمه

SSADM يکي از اعضاي خانواده روشهاي توسعه سيستمهاي اطلاعاتي است که از ابتداي دهه 1980، به عنوان مهمترين روش تحليل و طراحي سيستمهاي اطلاعاتي در انگلستان به کار گرفته شده است.

اين روش در ابتدا توسط مهندسين مشاور مديريت سيستمهاي لارمونت و بورچت (LBMS) معرفي شد و سپس با همکاري آژانس مرکزي مخابرات و محاسبات ماشيني (CCTA) که مسئول آموزش کامپيوتر و تأمين سخت‌افزار جهت سازمانهاي دولتي در انگلستان ميباشد، توسعه يافت.

روش پيشنهادي LBMS در سال 1981مقبوليت عام يافت و در پروژه‌هاي متعددي به کار گرفته شد. در ژانويه 1983، اين روش به عنوان روش رسمي در پروژه‌هاي دولتي انگلستان برگزيده شد. از آن سال، اين روش مرتباً بهنگام شده و روايت 4آن در ژوييه 1990منتشر شد. در اواخر دهه 1980، CCTA روش SSADM را به عنوان يک "استاندارد باز" جهت توسعه سيستمها مطرح نمود. در سال 1992، روايت 4اين روش به عنوان استاندارد کامل مورد موافقت قرار گرفت و به عنوان روش استاندارد دولتي بريتانيا پذيرفته شد. جهت استاندارد شدن اين روش، محصولات، روش ارائه و مدل ساختاري SSADM بسيار بيشتر از تکنيکهاي آن مورد توجه قرار گرفت.

از سال 1988، CCTA بر آن شد که SSADM را از انحصار کاربران دولتي خارج ساخته و در ميان کاربران عمومي نيز ترويج دهد. براي اين امر يک سري واحدهاي درس توسط گروه آزمون سيستمهاي اطلاعاتي جامعه انفورماتيک بريتانيا طراحي و به کارآموزان گواهينامه تخصصي در SSADM اهدا شد. اين امر به جايي منتهي شد که از سال 1991تمام قراردادهاي مشاوره در زمينه توسعه سيستمهاي اطلاعاتي با SSADM براي دولت بايستي با ارائه اين گواهينامه انجام ميپذيرفت. در حال حاضر، همه ساله تنها در انگلستان چندين پروژه ميليارد پاوندي به کمک روش SSADM انجام ميپذيرد.

در مجموع بايد گفت که SSADM چنين به نظر ميرسد که در ميان متدولوژيهاي توسعه سيستمهاي اطلاعاتي عمر درازي داشته است.

مبانی و مفاهیم

الف) داده‌گرايي : SSADM يک متدولوژي داده‌گرا است و بر روي مدلسازي داده و تشکيل پايگاه‌هاي داده تأکيد دارد. داده‌ها، به مراتب از فرآيندها و يا روالهايي که بر روي آنها عمل ميکنند، پايدارتر هستند. به همين دليل، داده جوهره پايدار هر سيستم اطلاعاتي است.

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

ب) اصل نمودارسازي : بهترين، گوياترين و سريعترين وسيله برقراري ارتباط با کاربران، استفاده از نمودارها براي مستندسازي و طراحي سيستم است.

SSADM در اين اصل با بيشتر متدولوژيهاي ساخت‌يافته مشترک است. تمامي متدولوژيهاي ساخت‌يافته بر استفاده از نمودارها براي مستندسازي يا طراحي سيستم تأکيد دارند و چنانکه ديديم اين ويژگي از مميّزات ذاتي روشهاي ساخت‌يافته است. اصل نمودارسازي در روش SSADM از اهميت خاصي برخوردار است، به طوري که محصول نهايي مراحل مختلف اين روش در قالب يک يا چند نمودار ارائه ميگردد.

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

د) تضمين کيفيت : تضمين کيفيت يکي از ارکان اساسي در روش SSADM به شمار ميرود. پايان هريک از مراحل SSADM با تضمين کيفيت محصولات آن مرحله همراه است. محصولات نهايي هر مرحله، از نظر کيفيت، تماميت، سازگاري و کارآيي از چندين جنبه توسط مديران، کاربران، توسعه‌دهندگان و کارشناسان به طور دقيق ارزيابي ميشوند.

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

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

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

تجزيه و تحليل رابطه‌اي داده‌ها، رويکردي از پايين به بالا است که در آن کوچکترين اجزاي اطلاعاتي به طور دقيق مورد تجزيه و تحليل قرار ميگيرند تا يک سازماندهي کامل و انعطاف‌پذيري از داده‌ها توليد نمايند.

 

 

تشريح متدولوژي SSADMدر تجزيه و تحليل و طراحي سيستمها :

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

مراحل SSDAM به گونه اي تدوين شده اند که هر مرحله داراي هدفي کاملاٌ روشن و محدوده اي معين است و شامل مجموعه‌اي مشخص از خروجي‌ها است

مراحل SSADM :

مرحله1 : تحليل

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

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

مرحله 2: مشخصات نيازمنديها

 اين مرحله به 3 بخش تقسيم مي‌شود :

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

بخش دوم به مستند سازي تفصيلي مدلها مي‌پردازد. شرح موجوديتها و ورودي / خروجي هاي هر کارکرد به صورت فهرستي از ويژگيها مستند مي‌شوند.

در بخش سوم ، ديدگاه تفصيلي نسبت به سيستم را ارائه مي‌دهد ، اين ديدگاه علاوه بر ديدگاه ايستا از سيستم که توسط نمودارهاي جريان دادها (DFD ) ها و مدل موجوديتها ( EM ) ها به دست مي‌آيد، تاثير کارکردها را در طي زمان به نمايش مي‌گذارد اين ديدگاه پويا بوده و درک اوليه اي از وظايف ايجاد شده در سيستم جديد را به دست مي‌دهد.

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

مرحله 3 انتخاب گزينه مطلوب : 

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

مرحله 4 طراحي منطقي داده‌ها :

مرحله 4 شرح وروديها و خروجيها را براي ايجاد ساختار داده‌ها در سومين شکل هنجاري آن به کار مي‌گيرد براساس اين ساختار مدل موجوديت و شرح آنها تهيه شده ، سپس با مدلي که قبلا در مرحله 2 ايجاد شده بود ، مقايسه مي‌گردد . اختلاف بين اين دو دسته ، براساس نيازمنديهاي سيستم ونيز نظريات کاربر رفع شده ودر نهايت مجموعه اي از شرح موجوديتها و مدل منطقي آنها جهت استفاده در مراحل «5» و «6» آماده مي‌گردند.

هدف مرحله4 اين است که اطمينان حاصل گردد ساختار داده ها و روابط ميان آنها کاملا تشريح و درک شده‌اند . در اين مرحله شرح و موجوديتها و مدل آنها به صورت پائين به بالا ايجاد مي‌گردند.

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

مرحله 5 : طراحي منطقي پردازشها :

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

هدف مرحله 5 دسته بندي کارکردها در داخل پردازش‌هاي منطقي ، بر اساس نيازمنديهاي پردازشي و تشريح تفصيلي اين پردازشها مي‌باشد

 مرحله 6 طراحي فيزيکي :

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

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

ابزار های SSADM

يکي از مزاياي مهم SSADM استفاده از طيف وسيعي از ابزارها و تکنيکها براي پيشبرد مراحل توسعه سيستم مي باشد. SSADM ابزارهاي استاندارد مختلفي براي اجراي هر گام و هر عمل ارائه مي نمايند. ابزارهاي مورد استفاده در متدولوژي SSADM را مي توان به دو دسته ابزارهاي نموداري و غيرنموداري تقسيم نمود. در اين قسمت، به طور خلاصه به معرفي پاره اي از مهمترين ابزارها و روشهاي اين متدولوژي مي پردازيم :

ابزارهاي نموداري

 نمودارهاي جريان داده (DFD)

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

تکنيک DFD در حقيقت براي نخستين بار در روش دومارکو معرفي گرديد که با کمي تغيير در علامت گذاريها، در روش SSADM هم به کار گرفته مي‌شود.

DFD ها به طور وسيعي در مراحل اوليه SSADM براي تعريف سيستم اطلاعاتي به کار گرفته مي شوند. اين نمودارها، همچنين ابزار مهمي براي ارتباط با کاربر در خلال تعريف و انتخاب گزينه سيستم کاري به شمار مي رود. در هر حال، استفاده از DFD ها بعد از گام استخراج کارکردهاي سيستم به پايان مي رسد.

تضمين کيفيت 

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

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

برآورد پروژه

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

کاربردها

CCTA که مسئول توسعه متدولوژي SSADM است، در برنامه هاي راهبردي خويش جهت توسعه سيستمهاي اطلاعاتي، به يک رهيافت برنامه ريزي و تحليل سازمان نگر معتقد مي باشد. تکنيکهاي به کار گرفته شده در اين رهيافت همگي مبتني بر شرايط سازمان بوده و فرصت هاي بهبود اين شرايط را معرفي مي کنند.

رهيافت سازمان نگر به طرز عميقي بر فلسفه، ابزارها، تکنيکها و نحوه مستندسازي SSADM تأثير گذاشته است . اين تأثير SSADM را جهت ارائه راه حلهاي جامع و يکپارچه اطلاعاتي براي سازمانهاي گسترده مناسب ساخته است .

SSADM يک متدولوژي جامع نگر است که تمام مراحل زيست چرخ را کم و بيش پوشش مي دهد.

پشتیبانی

همانطور که گفته شد خاستگاه SSADM کشور انگلستان است و بيشتر پروژه هاي بزرگي که با استفاده از اين متدولوژي انجام شده مربوط به اين کشور بوده است . از اين رو بديهي است که هرگونه مستندات و يا انتشارات دست اول راجع به اين روش را بايستي از طريق منابع انگليسي جستجو نمود. ساختار SSADM قابل تدريس بوده و در بسياري از دانشگاه ها بريتانيا اين متدولوژي براي واحدهاي سيستم اطلاعاتي انتخاب مي‌شود.

پس از آنکه در ابتداي دهه 198شرکت "مهندسين مشاور مديريت سيستم هاي لارمونت و بورچت " SSADM را به جهان معرفي نمود، آژانس مرکزي مخابرات و محاسبات ماشيني (CCTA) انگلستان وظيفه پشتيباني و توسعه اين متدولوژي را عهده دار شد. در حقيقت بايستي گفت که بدون فعاليتهاي CCTA، بي شک SSADM موقعيت کنوني خويش را نداشت .

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

امروزه SSADM در خارج از انگلستان نيز يک متدولوژي کاملا شناخته شده است . به گفته طرفداران اين متدولوژي، تاکنون نزديک به 14سازمان SSADM را براي ساماندهي اطلاعات خويش برگزيده اند، 28 مؤسسه آموزشي آن را تدريس مي کنند و 3ابزار CASE پشتيباني آن را به عهده دارند. 

SSADM از پشتيباني قوي ابزارهاي CASE برخوردار است . از سال 1989، اين متدولوژي توسط اين ابزارها حمايت مي شده است . شرکت ORACLE از طريق محصولي با نام تجاري CASE*METHOD اين متدولوژي را حمايت کرده و شرکت IBM نيز ابزار پشتيباني SSADM را با نام تجاري AD/cycle روانه بازار ساخته است .

SSADM در کشور ما نيز متدولوژي شناخته شده اي به شمار مي رود و به صورت پراکنده در برخي پروژه ها به کار گرفته شده است . همچنين مستندات و مراجعي به زبان فارسي در مورد اين متدولوژي وجود دارد.

SSADM ارزیابی مدل

پس از مطالب گفته شده پيرامون متدولوژي SSADM، حال زماني است که مي توانيم درباره ميزان کارآيي اين متدولوژي در شرايط خاص ايران به داوري بنشينيم .

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

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

منابع 

اصول، مراحل و تکنيکهاي SSADM مفصلا در کتاب زير تشريح شده است :

Downs, E., Structured Analysis and Design Method: Application and Context, Prentic-Hall, 1992

کتابهاي زير را مي توان به عنوان مراجع رسمي متدولوژي به کار برد:

Eva, M., SSADM Version 4: A User's Guide, 2nd ed., McGraw-Hill, 1994
Weaver, P.L., Practical SSADM Version 4: A Complete Turorial Guide, Pitman, 1993

شرح کوتاه و گويايي از روش SSADM را مي توان در منبع زير يافت : (بخش 5.6)

Avison, D.E. and Fitzgerald, G., Information Systems Development:
Methodologies, Techniques and Tools, 2nd edition, McGraw-Hill, 1995

از جمله مراجع فارسي، کتاب زير قابل ذکر است :

اشورت، ک . و گودلند، م .، روش ساخت يافته تجزيه و تحليل و طراحي سيستم ها، ترجمه شهناز پيروزفر، انتشارات دانشگاه هرمزگان، 1377

 

 

RUP

RUP

 

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

آر.یو.پی چیست؟

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

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

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

چرا آر.یو.پی را یکپارچه نامیده‌اند:

  1. این فرآیند از ترکیب و یکپارچه‌سازی چند فرآیند و متدولوژی شامل Booch، OMT و OSE دیگر ایجاد شده است.
  2. از زبان یکپارچه مدلسازی (UML) به طور موثری بهره می‌گیرد.
  3. مفاهیمی نظیر کلاس و شیء در متدهای قبلی علائم خاص و مختلفی داشته‌اند حال آنکه در آر.یو.پی یکسان شده‌اند.

مهم‌ترین مزایای آر.یو.پی

  • تسهیل توسعه تکراری نرم‌افزار
  • مدیریت نیازها
  • مدل کردن تصویری نرم‌افزار
  • بازبینی کیفیت نرم‌افزار
  • کنترل تغییرات در نرم‌افزار
  • امکان استفاده از طریق وب

 

مراحل آر.یو.پی

مرحله ۱ - آغازین (Inception)

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

مرحله ۲ - تحلیل پیچیدگی (Elaboration)

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

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

بررسی ریسک‌ها

ریسک‌های مرتبط با نیازمندیهای سیستم

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

در همین زمان سایر نمودارهای مدلسازی نظیر نمودارهای کلاس (Class Diagrams)، نمودارهای فعالیت (Activity Diagram) و نمودارهای تقابل (Interaction Diagrams) نیز به کمک کاربران سیستم بخصوص کاربران ارشد که اطلاعات بیشتر و مهم‌تری از عملکرد سیستم دارند باید تهیه شوند.

ریسک‌های تکنولوژیکی

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

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

نمودارهای یو.ام.ال زیر در این مرحله بکار می‌آیند:

ریسک‌های منابع انسانی

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

ریسک‌های سیاسی

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

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

مرحله ۳ - ساخت (Construction)

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

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

بطور خلاصه نتیجه این فاز کدنویسی و ایجاد نرم افزار است

مرحله ۴ - انتقال (Transition)

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