خلاصه ای از یک ابزار CASE متداول برای حمایت RAD
RAD نخستين بار در چهارچوب متدولوژي مهندسي اطلاعات (IE) و توسط جيمز مارتين مطرح شد (مارتين، 1991). مارتين در تحليل خود از علل ناکامي رهيافت سنتي به توسعه سيستم ها (رهيافت متکي به SDLC و حتي روشهاي ساخت يافته قديمي ) به اين نکته توجه کرد که عوامل زير در اين ناکامي ها مؤثر بوده است :
الف ) طولاني شدن روند توسعه؛ رهيافت سنتي بر طي مرحله به مرحله زيستچرخ توسعه سيستم ها که از برنامه ريزي، تحليل، طراحي، پياده سازي و بهره برداري تشکيل مي شد، تأکيد مي ورزيد و از اين رو در سيستم هاي گسترده، روند توسعه سيستم عملا تا توليد و استفاده از محصول نهايي ماهها و در برخي موارد سالها به درازا مي انجاميد. در اين مدت، محيط عمل سازمان و ساختار، اهداف و عملکرد دروني آن دستخوش تغييرات گاه عميقي مي شد که در نهايت ميزان کارآيي محصول نهايي اين روند را به طور جدي با ترديد مواجه مي ساخت .
ب ) عدم مشارکت کاربران نهايي؛ عليرغم همه تمهيداتي که در متدولوژي هاي ساخت يافته و به ويژه در IE براي مشارکت کاربران در روند توسعه سيستم ها انديشيده شده بود، به دليل عدم درگيري عملي آنها در مراحل تهيه سيستم و تقليل نقش کاربران به منابع اطلاعاتي و تأئيدکنندگان محصولات، اين مشارکت در عمل تحقق نمي يافت .
ج ) بزرگي گروههاي توسعه دهنده؛ در سيستم هاي اطلاعاتي گسترده، هر سيستم توسط سيستم هايي متشکل از تعداد زيادي تحليل گر، طراح، برنامه نويس، مستندساز و مشاور فني توسعه مي يافت . چنين ترکيب پرشماري از متخصصين، در ميان خود شبکه پيچيده اي از ارتباطات کلامي و کتبي برقرار مي کردند که مديريت پروژه ها را عليرغم پيشرفت ابزارهاي کنترل پروژه، بسيار دشوار و نتيجه نهايي را بسيار پر هزينه و زمانبر مي ساخت .
ايده RAD از تلاش براي غلبه بر اين مشکلات پديد آمد. در واقع، مارتين براي ابداع روشهاي RAD توجه را از فرآورده و فرآيند بار ديگر به کاربر معطوف ساخت و براي درگير ساختن کاربران نهايي در روند توليد سيستم ها، مکانيزم هايي را طراحي کرد که تحت عنوان RAD شناخته شد.
پس از پيدايش RAD، تلاشهايي براي تطبيق اين روشها در چهارچوب ساير متدولوژي هاي ساخت يافته به عمل آمد. همچنين گروهي از شرکتها و مؤسسات پشتيباني کننده از RAD، تشکلي را براي استانداردسازي اين روش تشکيل دادند که به روش توسعه پوياي سيستم ها (DSDM) معروف شد.
امروزه اصول و ايده هاي RAD در بخش وسيعي از ابزارها و محصولات توسعه نرم افزار به کار گرفته شده و در حيطه مهندسي نرم افزار، به پيدايش رده بسيار وسيع و موفقي از ابزارهاي توسعه نرم افزار، به نام محيط هاي ديداري انجاميده است .
به دليل آنکه RAD بيش از آنکه يک راه حل تجويزي مشخص براي توسعه سيستم ها باشد، مجموعه اي است از راهکارهاي عملي و در چهارچوب متدولوژي هاي مختلفي به کار بسته مي شود، آن را نمي توان بسادگي جزء يکي از دو گروه متدولوژي هاي پردازش ـ مدار و يا داده ـ مدار طبقه بندي کرد. به همين خاطر شايد بهتر باشد RAD را يک متدولوژي مبتني بر شبيه سازي با تأکيد ويژه بر مشارکت کاربران نهايي به شمار آورد.
در
چهارچوب مفهومي RAD، هر سيستم اطلاعاتي بخشي است از منابع اطلاعاتي يک
سازمان که در قالب يک ابزار (سيستم مکانيزه ) توسط طيف وسيعي از کاربران،
از مديران ارشد گرفته تا کارمندان عملياتي به کار گرفته مي شود. به دليل
ماهيت نرم افزاري سيستم ها، هر سيستم اطلاعاتي را مي توان مرکب از سه لايه
زير دانست :
- لايه فني (تکنولوژيکي ) که از بستر سخت افزاري، ارتباطات
و سطح پياده سازي نرم افزاري (سيستم عامل، ابزارهاي توسعه، RDBMS ها و
...) تشکيل مي شود.
- لايه اطلاعاتي که مبتني بر مدلهاي داده ـ فرآيند، بانکهاي اطلاعاتي و الگوهاي دستيابي و استفاده از اطلاعات است .
-
لايه کاربردي که به واسط سطح بالاي سيستم ـ کاربر مربوط شده و کاربردهاي
عملياتي، کنترلي، مديريتي و تصميم سازي را در برمي گيرد. در اين لايه ها به
ترتيب ميزان دخالت و حساسيت خبرگان فني کم شده و به ميزان دخالت و حساسيت
کاربران نهايي افزوده مي شود.
مطابق
اين الگو، به عنوان مثال در لايه فني، بيشترين نقش طراحي و تصميم گيري بر
عهده متخصصين خبرگان فني است و کاربران نهايي يا در انتخاب عناصر اين لايه
نقشي ندارند و يا اينکه نقش آنها به صرف تأييد و کنترل محدود مي گردد. از
سوي ديگر توسعه سيستم در لايه کاربردها اساساً بر عهده کاربران نهايي است
که با اعلام نيازها و تبديل آنها به زبان سيستم، ابزار سيستم اطلاعاتي را
به خدمت خود مي گيرند.
لايه مياني، يعني لايه اطلاعات که الگوسازي داده
ها و فرآيندها و کل عمليات سنتي تحليل سيستم در آن صورت مي گيرد، ميدان
عمليات مشترک خبرگان ـ کاربران است . در اين لايه، توسعه سيستم ها بايد با
بده بستان مستمر اطلاعاتي ميان کاربران و خبرگان صورت پذيرد. در هريک از
اين لايه ها، نوع اندرکنش بين اين دو گروه چنين است :
· در لايه فن آوري؛
o کاربران نيازها و امکانات خود را به خبرگان منتقل مي کنند.
o
خبرگان با تحليل اين نيازها و تطبيق اين خواسته ها با سطح تکنولوژي در
دسترس، گزينه ها و راه حل هاي امکان پذير را پيشنهاد مي کنند (امکان سنجي
).
· در لايه اطلاعات؛
o کاربران در طراحي منطقي پايگاههاي اطلاعاتي و تعيين ضوابط آن مشارکت مي کنند (طراحي منطقي ).
o خبرگان اين طراحي را با استفاده از ابزارهاي فني مناسب به پايگاههاي اطلاعاتي مناسب تبديل مي کنند (طراحي فيزيکي ).
· در لايه کاربردها؛
o کاربران در طراحي واسط ها شرکت مي کنند.
o خبرگان اين واسط ها را با استفاده از ابزارهاي مناسب پياده سازي کرده و به سطح عملياتي مي رسانند.
بايد
توجه کرد که اين تبادل اطلاعات و مشارکت دو جانبه در هر لايه به صورت
متقابل و در يک روند رفت و برگشت کامل شده و به صورت تدريجي نهايي مي شود.
مطابق با RAD، توسعه هر سيستم از چهار مرحله برنامه ريزي نيازها ، طراحي توسط کاربران ، ساخت و بهره برداري تشکيل مي شود. به کارگيري نهايي هر سيستم در درون سازمان حاصل انجام اين مراحل به صورت متوالي و در صورت لزوم به صورت مکرر خواهد بود.
در اين انگاره نکات زير را مي توان از ويژگيهاي مميزه روش RAD محسوب کرد:
· روش RAD بر مراحل سنتي زيستچرخ سيستم ها (SDLC) مبتني نشده است و به جاي آن بيشتر از نمونه سازي استفاده مي کند.
· روش RAD وسيعاً بر شناسايي و درگير کردن کاربران مهم در جريان توسعه سيستم تأکيد دارد.
· در روش RAD تأکيد زيادي بر متعهدسازي کاربران مؤثر صورت مي گيرد.
· اجراي روش RAD نياز به يک ابزار CASE دارد.
همانگونه که گفته شد براي اجراي روش RAD نيازي به طي مراحل سنتي SDLC نيست، و به جاي آن پيروي از يک الگوي چهار مرحله اي مطابق زير توصيه مي شود :
1. برنامه ريزي نيازها
در
روش RAD تأکيد زيادي بر روش انجام مراحل ابتدايي توسعه سيستم (برنامه ريزي
و امکان سنجي ) صورت مي گيرد. در اين مراحل است که وظيفه اساسي تعريف
نيازهاي کاربران به انجام مي رسد. روش اساسي توصيه شده براي اين مرحله
برگزاري جلسات برنامه ريزي مشترک نيازها (JRP) است . هدف از JRP ها تعيين
نيازهاي مديريتي سطح بالا در مورد سيستم، در سطحي راهبردي و کلان است . به
عبارت ديگر آنچه که بايد در جلسات JRP تعيين شود، نيازهاي مديريتي کلان،
اهداف سيستم و ارتباط آن با ساير سيستم ها و اهداف کلي سازمان است .
شرکت
کنندگان JRP به طور عمده از ميان مديران ارشد سازمان بايد انتخاب شوند.
مارتين دو شرط عمده را براي شرکت کنندگان در JRP ذکر مي کند :
· نفوذ
· ارشديت
به
عبارت ديگر شرکت کنندگان بايد قدرت اتخاذ تصميم و متعهد ساختن سازمان را
داشته باشند، به گونه اي که براي اتخاذ هر تصميمي نياز به ارجاع به رده هاي
بالاتر مديريتي نباشد. به ديگر سخن، شرکت کنندگان در JRP يا بايد خود از
ميان بالاترين سطح مديريتي انتخاب شوند و يا اينکه اختيار تام به آنها
تفويض شده باشد. غير از حدود اختيارات، شرط ديگري که بايد اين شرکت کنندگان
دارا باشند، عبارتست از شناخت اهداف و راهبرد کلي سازمان و شناخت حوزه
کاري که سيستم مورد بحث در آن زمينه بايد توليد شود.
اهميت اختيارات
شرکت کنندگان در JRP ها آنچنان زياد است که مارتين تأکيد مي کند اگر امکان
شرکت کاربران مناسب در اين جلسات وجود نداشت، بهتر است از برگزاري چنين
جلساتي صرف نظر شود، زيرا هدف اساسي از برگزاري JRP ها عبارتست از تعيين و
توافق بر روي نيازها در کوتاهترين زمان ممکن .
2. طراحي توسط کاربر
آنچه
که در مرحله طراحي توسط کاربر بايد انجام شود، آميزه اي است از وظايفي که
به طور سنتي، تحليل و طراحي ناميده مي شود. به عبارت ديگر، تعيين و تدقيق
نيازهاي کاربر (به صورت جزيي )، تهيه مدلهاي داده و فرآيند (مدلسازي )،
طراحي واسط ها، گزارش ها، صفحات و ساير عناصر سيستم از وظايف اين مرحله است
.
روش اصلي انجام اين مرحله برگزاري جلسات طراحي مشترک (JAD) است .
JAD
يک جلسه برنامه ريزي شده است که با شرکت ترکيبي از کاربران عمده سيستم،
مديران و کارشناسان توسعه سيستم تشکيل مي شود. سه عامل زير در برگزاري موفق
JAD مؤثر دانسته شده است :
· استفاده از اشخاص مناسب به عنوان شرکت کننده
· برگزاري در محيط (فيزيکي ) مناسب
· استفاده از ابزارهاي مناسب نمونه سازي
در روش پيشنهادي مارتين، از چهار روش نمودارسازي زير براي پيشبرد تحليل و طراحي سيستم در جريان JAD استفاده مي شود :
· مدلسازي هستنده ها
· تجزيه کارکردي
· نمودارهاي جريان داده (DFD)
· نمودارهاي کنشي
فرض
بر اين است که همه شرکت کنندگان JAD با اين روشها اجمالا آشنايي دارند.
هرچند توصيه شده است براي تحليل و تثبيت نتايج بيشتر از زبان آشناي کاربران
استفاده شود. استفاده از يک ابزار مجتمع CASE براي تهيه نمودارها، تجزيه و
تحليل خواسته ها، تضمين سازگاري بين نتايج طراحي و نهايتاً نمونه سازي
واسط ها و خروجي ها قوياً توصيه مي شود. در واقع وجود چنين ابزاري يکي از
شرايط قطعي موفقيت جلسات JAD است .
در برگزاري هر جلسه JAD عناصر زير بايد مورد توجه قرار گيرد:
· ترکيب مناسب شرکت کنندگان
· تعيين زمان مناسب براي هر جلسه (بين 1تا 2روز)
· استفاده از يک مکان مشخص براي برگزاري جلسات با آرايش فيزيکي مناسب
· وجود يک مدير جلسه باتجربه در امر برگزاري جلسات JAD
· استفاده از يک يا چند منشي براي ثبت نتايج
در روش پيشنهادي مارتين به ويژه بر نقش مدير جلسه تأکيد زيادي مي شود. اين مدير بايد ضمن دارا بودن نفوذ و اختيارات کافي، توان هدايت گروههاي مختلف شرکت کننده و جمع بندي سريع نتايج را نيز داشته باشد. همچنين وجود يک حامي قدرتمند در درون سازمان براي موفقيت JAD ضروري است . اين حامي بايد از جايگاه مناسب سازماني براي حمايت از روش، دادن تعهد انجام فعاليت ها و حمايت مالي پروژه برخوردار باشد.
3. ساخت
در
مرحله ساخت طراحي انجام شده توسط کاربران در مرحله قبل، به طراحي تفصيلي و
سپس به کد (برنامه ) تبديل مي شود. اين مرحله توسط گروههاي کوچکي از
کارشناسان طراح و برنامه نويس که به ابزارهاي مناسب CASE مجهزند صورت مي
گيرد. هريک از اين گروهها را يک گروه SWAT مي نامند. تعداد اعضاي هر گروه
SWAT معمولا بايد بين 3 تا 4 نفر باشد و هر گروه بايد بتواند ظرف 4 تا 6
هفته قسمت اساسي سيستم را تهيه کند. در کليه مراحل روش کار به اين ترتيب
خواهد بود :
· براي هر قسمت (هر صفحه يا گزارش يا تراکنش )، يک نمونه اوليه توسط يکي از اعضاي گروه تهيه مي شود.
· در صورت عدم تصويب، تغييرات خواسته شده اعمال شده و کار مجدداً از مرحله اول تکرار مي شود.
حاصل
اين روند تکراري، تکميل تدريجي برنامه هاي سيستم، همراه با آزمون و
مستندسازي آنهاست . به دليل نظارت مستمر کاربران نهايي در مراحل ساخت،
فرآورده نهايي نيازي به تجديدنظر نخواهد داشت .
لازم به تذکر است که در
اين مرحله نيز، همچون مراحل قبل، استفاده از يک ابزار CASE مناسب و
قدرتمند، براي تکميل سريع سيستم الزامي است .
4. بهره برداري
پس
از تحويل برنامه هاي سيستم به کاربران، به همراه مستندات لازم، مرحله بهره
برداري آغاز مي شود. هدف اصلي اين مرحله آزمون و اجراي واقعي سيستم در
محيط عملياتي سازمان است . در اين مرحله، اقدامات زير صورت مي گيرد :
· تحويل و نصب برنامه ها در محيط واقعي
· آموزش کاربران
· انجام تغييرات سازماني لازم براي عملياتي شدن سيستم
· اجراي همزمان سيستم هاي جديد و قديم و انتقال تدريجي به سيستم جديد
چنانکه
در بخش قبل گفته شد، روش RAD به عنوان نحوه اي رويکرد به زيستچرخ توسعه
سيستم ها، با متدولوژي هاي مختلفي قابل ترکيب است و به همين دليل در آن از
مجموعه متنوعي از ابزارها مي توان استفاده کرد. با وجود اين چون شرح ما از
مراحل اين روش، مطابق با فرمولبندي مارتين و در قالب متدولوژي IE انجام
شده، در اين بخش نيز به ابزارهايي اشاره مي کنيم که RAD مطابق با روايت
مارتين از آنها استفاده مي کند.
اين روشها را اصولا به سه مقوله مي توان تقسيم کرد :
1. ابزارها و روشهاي نمودارسازي
به
طور کلي استفاده از همه ابزارهاي نمودارسازي توصيه شده در IE در اين روش
نيز مجاز است . به ويژه در مراحل طراحي توسط کاربر و ساخت از نمودارهاي زير
استفاده مي شود :
· مدلسازي هستنده ها (ERD)
· تجزيه کارکردي (Functional Decomposition)
· نمودارهاي گردش داده (DFD)
· نمودارهاي کنشي
2. ابزارهاي CASE
يکي
از ويژگيهاي مميّزه RAD تأکيد شديد آن بر استفاده از ابزارهاي CASE در
جريان پيشبرد مراحل تحليل، طراحي و ساخت سيستم است . استفاده از CASE به دو
دليل عمده زير براي اجراي روش RAD ضروري است :
· سرعت در تبديل خواسته ها و نظرات کاربران به مستندات سيستم
· تبديل سازگار و سريع مستندات طراحي سيستم به نمونه هاي قابل بازديد توسط کاربر
RAD
بر استفاده از ابزارهاي مجتمع CASE تأکيد دارد، يعني ابزارهايي که همه
مراحل تحليل، طراحي، ساخت، آزمون و مستندسازي سيستم ها را بتوان با کمک
آنها در يک محيط واحد انجام داد. اين محيط همچنين بايد توانايي توليد سريع
نمونه هايي از صفحات، دريچه ها، منوها و گزارشهاي مورد نياز کاربران را
داشته باشد.
مارتين خود استفاده از نرم افزار IEF را براي اجراي موفقيت آميز RAD پيشنهاد مي کند.
3. جلسات JAD
به
دليل اهميتي که جلسات JAD در روند اجراي روش RAD دارند، شايسته است اين
جلسات را به عنوان ابزارهاي عمده پيشبرد روش مورد بررسي قرار دهيم .
در
واقع جلسات JAD بيش از آنکه يک ابزار واحد باشند محملي براي اجراي مجموعه
اي از روشها و ابزارهاي ديگرند. سابقه JAD به پيش از پيدايش روش RAD بازمي
گردد.
نخستين بار در سال 1977شرکت IBM در جلسات JAD براي اجراي مرحله
تعريف خواسته ها استفاده کرد. اما استفاده از اين روش تا اواسط دهه 80
ميلادي توسط ساير شرکت ها عمومي نشد. در حال حاضر JAD در بسياري از
متدولوژي هاي توسعه سيستم به عنوان يک روش سريع و مناسب براي دريافت نظرات
کاربران، به عنوان جايگزيني براي روشهاي سنتي مصاحبه و تکميل پرسشنامه
پذيرفته شده است .
مارتين، همزمان با تلفيق تکنيک JAD در روش RAD دو عنصر مهم را به اين جلسات افزود :
· استفاده از يک ابزار CASE مجتمع به عنوان کانون جلسه
· تأکيد بر نمونه سازي به عنوان روش مبادله افکار و نظرات در جلسات JAD
امروزه روش برگزاري جلسات JAD به عنوان يک فن جمع آوري اطلاعات يا جزيي از ساير متدولوژي ها پيشرفت بسيار کرده و کتابهاي راهنما و مراجع مختلفي، اين روش را با جزئيات لازم آموزش مي دهند.
چون
RAD خود يک متدولوژي مستقل نيست، سخن در مورد کاربردپذيري آن بسادگي امکان
پذير نمي باشد. آنچه مي توان گفت اين است که RAD علاوه بر استفاده مستقيم
توسط توسعه دهندگان سيستم (بيشتر در چهارچوب متدولوژي IE)، به عنوان يک
تکنولوژي پيشرفته، تأثير دورانسازي در توسعه محيطهاي مهندسي نرم افزار در
دهه 90 ميلادي گذاشته است .
به تعبيري شايد بتوان مهمترين دستاورد
مهندسي نرم افزار را در دهه 90 ميلادي، استفاده و رواج محيطهاي برنامه
نويسي ديداري ذکر کرد. اين محيطها از نظر فني حاصل برخورد سه تکنولوژي
پيشرو در زمينه هاي مختلف بوده است :
الف ) زبانهاي برنامه نويسي نسل چهارم (4GL)
ب ) تکنيکهاي شي ءگرايي
ج ) روش RAD
اين محيط ها اينک به عنوان ايده مسلط بر بازار ابزارهاي توسعه نرم افزار درآمده اند و نقش مهمي در همه گير شدن و رواج اين ابزارها ايفاد مي کنند. يک پايه اين محيط ها ايده هايي است که در تکنولوژي RAD نقش اساسي داشته اند، يعني لزوم مشارکت عملي کاربران نهايي در جريان توسعه سيستم، نمونه سازي سريع، تلفيق CASE با ابزارهاي برنامه نويسي و ... به همين دليل کل محيط هاي ديداري را مي توان از کاربردهاي غير مستقيم RAD دانست .
RAD
به عنوان متدولوژي از سوي هيچ شرکتي پشتيباني نمي شود. اما گروههايي از
کاربران اين روش در سراسر دنيا، دست به تشکيل تشکلهايي زده اند که هدف آنها
قاعده مند کردن و تدوين استانداردهاي استفاده ار روش RAD است . از آن جمله
کنسرسيوم DSDM در انگلستان با هدف تدوين استانداردهاي استفاده از روش RAD
تشکيل شده است .
علاوه بر اينها، هم اينک همه شرکتهايي که در زمينه
توليد ابزارهاي توسعه نرم افزار کار مي کنند (از جمله Microsoft، Borland،
Oracle، ...) در طراحي ابزارهاي خود به طور روزافزوني ايده هاي RAD را به
کار مي گيرند.
1. مزايا
· چون RAD با هدف سرعت بخشيدن به روند توسعه سيستم ها طراحي شده است، بديهي است که مزيت عمده آن سرعت بالايي است که با آن مي توان سيستم ها را تهيه کرد. زمان پيشنهادي مارتين براي تهيه هر سيستم (بخش اساسي سيستم ) در حدود 90 روز است . به اين ترتيب همه اشکالاتي که از طولاني شدن زمان توسعه سيستم ناشي مي شود (هزينه هاي بالا، تغيير سازمان و در نتيجه تغيير خواسته ها، کاهش حمايت مديريت و ...) با اين روش مرتفع مي شود.
· مراحل RAD به گونه اي طراحي شده است که در تمام مراحل، مشارکت عملي کاربران نهايي را در تصميم گيري و حتي طراحي سيستم تضمين کند. به اين ترتيب فرآورده نهايي، هنگامي که براي استفاده عملي تحويل مي شود، قاعدتاً بايد بيشترين تناسب را با نيازها و سليقه هاي کاربران داشته باشد و تغيير در آن، حداقل براي مدتي لازم نباشد.
· محدود بودن گروههاي توليد کننده سيستم در روش RAD (بين 3 تا 4نفر) ارتباطات لازم را براي هماهنگي و کنترل پروژه ها به ميزان قابل توجهي کاهش مي دهد و به همين دليل راهبري و مديريت پروژه هاي RAD را بسيار ساده تر مي کند.
2. معايب
· RAD اصولا براي تهيه سيستم هاي کوچک و متوسط طراحي شده است . تعداد کاربران و گروههايي که از سيستم هاي بزرگ و بسيار بزرگ استفاده مي کنند (مانند سيستم هاي بانکي توزيع شده، يا سيستم هاي کنترل صنعتي گسترده ) آنچنان زياد است که عملا مشارکت دادن همه آنها در روند توسعه سيستم غيرممکن مي شود. علاوه بر اين طراحي و ساخت چنين سيستم هايي در مدت کوتاه قطعاً غيرممکن است .
· استفاده از ابزار اصلي RAD يعني جلسات JAD در بسياري از موارد دشوار يا حتي غيرممکن است . اولا تفهيم کارآيي و ضرورت اين روش به مديران سازمان و ساير کاربران آسان نيست . ثانياً مديران ارشد و مياني معمولا آنچنان درگير فعاليت هاي اجرايي و روزمره هستند که انتزاع آنان از کارهاي عادي حتي به مدت يک يا دو روز آنهم به صورت جمعي عملا ناممکن مي نمايد. ثالثاً در کشورهايي مانند کشور ما نبايد انتظار داشت که همه مديران شرکت کننده در JAD با مفاهيم و روشهاي تهيه سيستم و به ويژه با ابزارهاي مدلسازي آشنا باشند. به همين دليل مشارکت عملي اينان در جريان تحليل و طراحي که در روش RAD حياتي است، عملا متحقق نخواهد شد.
· کارآيي RAD بيشتر در سازمانهاي است که سابقه استفاده از سيستم هاي مکانيزه را دارند و فرهنگ استفاده از سيستم هاي اطلاعاتي تا حد زيادي در آنها رايج شده است . استفاده از RAD به ويژه در سازمانهايي که فاقد سيستم هاي مکانيزه قبلي هستند، دشوار است .

با سلام خدمت شما بازديد كننده عزيز اميدوارم كه لحظات خوشي در اين وبلاگ داشته باشيد.