کاربرد روش RAD در توسعه سیستم
1 - مقدمه مساله
زمان در پروژه هاي سيستمهاي اطلاعاتي همواره از عوامل حساس وتعيين كننده
بوده است . درصورت طولاني شدن زمان يك پروژه ، ممكن است پروژه باتغيير
مديريت در سازمان كارفرما يا تغيير در اهداف مديريت مواجه شود كه اين
مواردمي توانند بر موفقيت پروژه تاثير منفي بگذارند. ازطرف ديگر در بخش
مجري يا كارگزار،طولاني شدن پروژه مي تواند باعث بالارفتن نرخ كارشناسي و
درنتيجه افزايش هزينه پروژه گردد.
طولاني شدن زمان پروژه ازنظر تكنولوژي
اطلاعات نيز مي تواند مساله ساز باشد. هرروز كه مي گذرد پايگاههاي داده
ها، سيستمهاي عامل ، زبانهاي برنامه سازي و ابزارهاي مهندسي نرم افزار
"CASE TOOLS"توسعه يافته وگونه هاي جديدي از آنهابه بازار مي آيد وچنانچه
زمان پروژه طولاني گرددممكن است روشها، ابزارها،وپلاتفورم انتخابي پروژه
توجيه پذيري خود را از دست بدهد.
به دليل مسائل فوق در سطح جهاني
كوششهايي براي استفاده از روشها و ابزارهاي بهتر به منظور كاهش زمان ،
هزينه و ريسك پروژه و افزايش قابليت اعتماد به سيستمهاي ساخته شده صورت
گرفته است كه در مقاله حاضر خلاصه اي از آنها ارائه مي گردد.
درمقاله
حاضر پس از مطرح كردن مسائل و مشكلات روشهاي سنتي ، روشهاي موسوم به
FASTTRACK يا RAD همراه با شرايط بكارگيري موفقيت آميز آنها ارائه مي شوند.
يكي از كوششهايي كه براي اين منظور
مي شود مستندسازي مراحل مختلف توسعه سيستم ، ارسال آنها براي كاربران و اخذ
تاييديه از آنهاست . ولي همه مي دانيم كه اين گونه مستندات اولا با زبان
سيستم آناليست ها نوشته مي شوند كه بسياري از آنها براي كاربران قابل فهم
نيست . ثانيا آنقدر قطور وحجيم هستند كه كاربران وقت مطالعه و بررسي آنها
راندارند. بويژه مستندات مرحله طراحي معمولا آنقدر به صورت جزيي تهيه مي
گردند كه برنامه نويسان بتوانند از روي آنها برنامه نويسي كنند و همين امر
باعث حجيم شدن مستندات اين مرحله مي گردد. بنابراين حتي اگر تاييدي ازجانب
كاربر درمورد اين گونه مستندات صورت گيرد چنين تاييدي خيلي قابل اعتماد
نيست .
آمارهاي كشف خطا در پروژه هاي يك موسسه انفورماتيك معتبر نشان مي
دهد كه باوجود اخذ تاييديه ازكاربران ، 93% از خطاها متعلق به مراحل
آناليز و طراحي و فقط 7%آنها متعلق به مرحله برنامه سازي بوده است . اين
امر نشان مي دهد كه مسائل اصلي اين گونه پروژه ها مربوط به مراحل قبل از
برنامه سازي است .
باتوجه به نكات فوق ، چه راه حلي براي كاهش زمان
اجراي پروژه ، كاهش مقدارخطاها و حجم مدارك و مستندات مراحل مختلف و افزايش
قابليت اعتماد به سيستم وجود دارد؟3 - بهبود روشهاي سنتي در
اينجا منظور از روشهاي سنتي همان مدلهاي آبشاري "WATERFALL" است كه مراحل
توسعه سيستم را به چند مرحله تقسيم مي كند و خروجي هاي هر مرحله وروديهاي
مرحله بعد حساب مي شوند و تا وقتي كه يك مرحله تمام نشده است مرحله بعد نمي
تواند آغاز گردد.
نخستين كوششها براي بهبود روشهاي آبشاري در اوائل دهه
90 صورت گرفت .|GANEدر سال 1987 روش RAD و BOEHM در سال 1988 روش توسعه
"SPIRAL"را مطرح كردند. همچنين در سال 1991 جيمزمارتين كتابي درمورد
"RAD"RAPID APPLICATION DEVELOPMENTنوشت و BUDDE بحث نمونه سازي در توسعه
سيستم را مطرح كرد.
در بخشهاي تجاري و صنعتي كمپاني
اوراكل در سال 4991 كتاب
ORACLE FAST-TRACK A RAD APPROACHرا منتشر كرد.
درواقع
، هدف همه كوششهاي فوق ، افزايش كارايي و كاهش ريسك روشهاي توسعه سيستم
است و از اين نظر روشهاي موسوم بهRADداراي كارايي بالاتر و ريسك كمتري نسبت
به روشهاي آبشاري هستند.
4 - روش RAD چيست ؟
تعريف : درميان
صاحبنظران تعريف واحدي از روش RAD وجود ندارد ولي از مطالعه نظرات بيان شده
در اين زمينه مي توان اينگونه استنباط كرد كه RAD مجموعه اي ازتكنيك ها و
فنوني است كه براي ايجاد شتاب بيشتر در فرايند توسعه سيستم به طورمشترك با
كاربران و ساير طرفهاي ذينفع صورت مي گيرد. به عبارت ديگر در اين روش تاكيد
عمده بر كار مشترك در مراحل مختلف توسعه سيستم است . ازجمله تكنيك ها
وفنوني كه در روش RAD از آنها استفاده مي شود مي توان به موارد ذيل اشاره
كرد:
الف - شكستن پروژه هاي بزرگ به پروژه هاي كوچكتر و قابل اجرا;
ب - اولويت بندي انجام كار براساس زمان ثابت ;
ج - نمونه سازي ;
د - آناليز و طراحي مشترك ازطريق برگزاري كارگاه .
رويهمرفته
در روش RAD نمونه سازي در مراحل مختلف و بررسي نهايي سازي آنهادر جلسات
مشترك به كمك مراحل آناليز و طراحي هاي سنتي آمده و به جاي هزاران صفحه
مدارك همين نمونه هاي ساخته شده موردبررسي و اظهارنظر قرار مي گيرند.
درسطور زير درمورد هركدام از تكنيك ها و فنون مورداستفاده در RAD توضيحات
مختصري داده مي شود.
شكستن پروژه ها به واحدهاي كوچكتر: اولين قدمي كه
بايد در فاز برنامه ريزي پروژه صورت گيرد بررسي پروژه ازنظر بزرگي و امكان
شكستن آن به پروژه هاي كوچكتر است .همچنين هركدام از اجزا بايد ازاين جهت
كه قابل نمونه سازي هستند يا نه موردبررسي قرار گيرند چون ممكن است برخي از
اجزا پروژه قابل نمونه سازي نبوده و نتوان روش RAD را براي ساخت آنها به
كارگرفت . اين اجزا بايد با روشهاي ديگري طراحي و ساخته شوند. نتيجه نهايي
اين فعاليت فهرستي از اجزا پروژه و روش طراحي و ساخت هريك است .
اولويت
گذاري براساس زمان ثابت : در اين روش فرض مي شود زمان ثابت و غيرقابل تغيير
است . با چنين فرضي ممكن است اجزايي از پروژه يا جنبه هايي از يك سيستم
داراي اولويت بيشتري باشند كه لازم است اين اولويتها در توسعه سيستم مدنظر
قرارگيرند. در زمان ثابت معمولا چهار سطح اولويت به شرح زير پيش بيني مي
گردد:
الف : عمليات يا جنبه هاي اجباري عبارت از اقلامي هستند كه حتما بايد در پروژه موردنظر گنجانده شوند و بدون آنها پروژه ارزش ندارد;
ب
: عمليات يا جنبه هاي الزامي عبارت از اقلامي هستند كه بودن آنها ضروري
است ومعمولا در برنامه پروژه نيز گنجانده مي شوند، ولي اگر شرايط به گونه
اي پيش رفت كه لازم بود بخشي از زمان يا منابع آنها براي عمليات يا جنبه
هاي اجباري اختصاص يابد، ممكن است بخشهايي از آنها به نفع عمليات اجباري
كنار گذاشته شوند;
ج : عمليات يا جنبه هاي شايسته عبارت از اقلامي هستند
كه بودن آنها در پروژه مفيداست ولي جنبه الزامي نداشته و درصورتي كه زمان و
منابع از بندهاي الف و ب زياد آمدبه اين اقلام اختصاص داده مي شوند;
د: عمليات يا جنبه هاي غيرضروري عبارت از اقلامي است كه بهتر است در پروژه موردنظر وجود نداشته باشند.
درصورت
اولويت بندي عمليات پروژه يا جنبه هاي مختلف يك سيستم به صورت فوق ، اين
اطمينان وجود دارد كه ابتدا اجزا و جنبه هاي مهمتر ساخته مي شوند و چنانچه
زمان از دست برود جنبه هاي كم ارزش تر باقي مي مانند كه مي توان براي آنها
در مقاطع بعدي چاره اي انديشيد.
نمونه سازي : نمونه سازي روشي است كه در
آن يك نمونه سريع و تقريبي از يك سيستم يا بخشي از آن ساخته مي شود. چنين
نمونه هايي معمولا براي نمايش به كاربران و سايرافراد ذينفع تهيه مي شوند.
نمونه
هاي ساخته شده ممكن است پس از دستيابي به اهداف خود كنار گذاشته شوند.
كنار گذاشتن نمونه به معني بي فايده بودن نمونه سازي نيست چون ممكن است
نمونه سازي به اهداف خود كه روشن كردن برخي از مطالب و يا اخذ تاييديه از
كاربران باشد برسد ولي خود نمونه ساخته شده كاربرد بعدي نداشته باشد.
بعضي
مواقع نمونه ساخته شده بخشي از سيستم واقعي است و به مثابه جزيي ازسيستم
كاركردي مي تواند عمل كند. در اين صورت با استفاده از فنون توسعه تدريجي مي
تواند تبديل به سيستم واقعي يا بخشي از آن گردد.
نمونه سازي در مراحل
مختلف توسعه سيستم مي تواند با اهدافي صورت گيرد كه به همان مرحله مربوط مي
شود. معمولا در مرحله آناليز نمونه سازي انجام مي شود كه بيشترنمونه سازي
ساختار سيستم و برخي از صفحات نمايش است . در مرحله طراحي معمولاطرح نمونه
سازي تهيه مي گردد كه كاركردهاي عمده سيستم را داراست و بعدا مي تواندتبديل
به سيستم نهايي شود.
نمونه هاي ساخته شده معمولا فاقد جنبه هاي كنترلي
پشتيباني هستند. بنابراين چنين نمونه اي هرچند مي تواند وظايف اصلي يك
سيستم را انجام دهد ولي نمي تواندجايگزين سيستم نهايي شود.
ابزارهاي
نمونه سازي : نمونه سازي از زماني به درستي عملي شد كه زبانهاي نسل چهار
وابزارهاي CASE|I به بازار آمد زيرا كه فقط با اين ابزارها مي توان نمونه
هاي سريعي ازصفحات نمايش ، گزارشها و حتي يك سيستم كاربردي ساخت و بارها آن
را برحسب نظركاربران و ساير افراد ذينفع اصلاح كرد. در صورت استفاده از
اين ابزارها، نمونه ساخته شده در بسياري از مواقع قابل ارتقا به سيستم
نهايي است .
رويهمرفته ابزارهاي نمونه سازي بايد خاصيت تعامل داشته و
براي ساخت و اصلاح نمونه ها، سريع و كاربردي باشند و قابليت استفاده از يك
پايگاه داده پيشرفته را داشته باشند. اين ابزارها بايد حداقل داراي اجزا
زير باشند:
ابزاري براي ساخت صفحات نمايش و گزارشها;
ابزاري براي ساخت برنامه "زبان نسل 4 يا "CODE GENERATOR";
يك پايگاه داده پيشرفته و يكپارچه با ابزارهاي ديگر نمونه سازي ;
يك فرهنگ CASE
يك داده خوان براي استخراج اطلاعات از پايگاه داده ها.
چه
كساني نمونه را مي سازند: نمونه سازي معمولا توسط يك الي دو نفر انجام مي
شود.درصورتي كه يك نفر نمونه را بسازد معمولا اين شخص كسي است كه مسلط به
ابزارهاي نمونه سازي است ولي درحالتي كه دو نفر چنين كاري را انجام مي
دهند، نفر دوم معمولا عضوي از كاربران نهايي سيستم است . درگير شدن تعداد
زيادي از افراد درنمونه سازي توصيه نمي شود و ساير افراد بهتر است در جلسات
بررسي نمونه نظر خود رابيان كنند.
بررسي نمونه : نمونه هاي ساخته شده
در جلسات يا كارگاهها موردبررسي قرار مي گيرند.در مورد چگونگي تشكيل اين
كارگاهها / جلسات در بندهاي بعدي توضيح داده خواهدشد.
انجام آناليز و
طراحي مشترك : برگزاري كارگاه يا جلسات مشترك بين عوامل ذينفع درتوسعه
سيستم يكي از ابزارهاي الزامي در متدولوژي RAD به طوري كه درتمام مراحل
توسعه سيستم كارگاهها و جلساتي به منظورهاي مختلف تشكيل مي شود.
دراصل ،
تشكيل كارگاه يكي از شيوه هايي است كه از طريق آن مي توان آناليز مشترك
|"JRP"و يا طراحي مشترك "JAD" را به سرانجام رساند. تا قبل از نمونه سازي ،
تشكيل كارگاه عمدتا به منظور تعيين حدود و ثغور سيستم ها و دريافت نيازهاي
عوامل ذينفع انجام مي شود ليكن پس از نمونه سازي غالبا كارگاهها براي
بررسي نمونه هاي ساخته شده صورت مي گيرد.
الف - چه كساني در كارگاه شركت
مي كنند: كارگاهها درمراحل مختلف توسعه سيستم به منظورهاي مختلفي تشكيل مي
گردند و برحسب مورد افراد شركت كننده آنها متفاوت است . ليكن تقريبا عناصر
ذيل در اغلب كارگاهها حضور دارند:
نمايندگان كاربران نهايي سيستم كه بايد در آينده سيستم را اجرا كنند;
تكنولوگ هاي صنعت و افرادي كه از نوع كار و صنعتي كه بايد سيستم در آنجاپياده سازي شود اطلاع كافي داشته باشند;
نمايندگان كارفرما و مدير پروژه كارگزار;
كارشناسان تكنولوژي اطلاعات "IT" از دستگاه مجري "كارگزار" و كارفرما;
گرداننده جلسه ، اين فرد بايد داراي ويژگيهاي مناسب براي اين كار باشد;
منشي جلسات ، اين شخص بايد كليه بحثها، تصميم گيريها و نتايج جلسات را ثبت وصورتجلسه نهايي هر جلسه را تنظيم كند;
كارشناسان و متخصصان رشته هاي مختلف برحسب مورد.
ازنظر
فني تشكيل كارگاههاي بالاتر از ده نفر توصيه نمي شود و بهتر است از
حضورافراد غيرموثر در جلسات جلوگيري شود و تعداد درحد 7-8 نفر نگهداشته شود
تا بتوان بهتر نتيجه گيري كرد.
ب - مزاياي برگزاري كارگاه : هدف اصلي
برگزاري كارگاه تبادل نظر بين عوامل ذينفع درتوسعه سيستم است و از مزاياي
آن مي توان موارد ذيل را ذكر كرد:
كاهش زمان در تمامي مراحل توسعه سيستم بويژه مراحل برنامه ريزي ، تحليل وطراحي ;
افزايش كيفيت و مقبوليت سيستم ساخته شده و پايين آوردن ريسك عدم پذيرش سيستم ;
افزايش مشاركت كاربران و احساس مالكيت آنها نسبت به سيستم ساخته شده ;
كاهش تاثير مسائل غيرحرفه اي "سياسي ، اقتصادي و غيره " و ساير مسائل بالقوه روي فرايند توسعه سيستم ;
بهبود رابطه طراح و كاربر.
ج - كارگاه چگونه برگزار مي شود: براي تشكيل كارگاه بايد چهار قدم اساسي برداشته شودكه عبارتند از:
برنامه
ريزي : اين كار مشتركا به وسيله مدير پروژه كارگزار، گرداننده جلسه و
نماينده كارفرما صورت مي گيرد. در اينجا بايد تعداد جلسات ، زمان و محل
برگزاري جلسات ، نام شركت كنندگان ، نتايج قابل انتظار از جلسات ، و لوازم و
تجهيزات موردنياز براي برگزاري كارگاه روشن گردند.
تدارك جلسه : منظور
آماده سازي مكان ، تامين تجهيزات سمعي و بصري ، و آماده سازي مطالبي است كه
در جلسات عرضه و يا توزيع مي شوند. معمولا اين مسئوليت برعهده گرداننده
كارگاه است .
برگزاري كارگاه : پس از برنامه ريزي و تدارك كارگاه ،
جلسات بايد در راس زمان مقررتشكيل شود. در برگزاري كارگاه ، ابتدا بايد
جلسه توسط مدير پروژه يا نماينده كارفرماافتتاح گردد و درمورد اهداف جلسه
توضيح داده شود. سپس حضار به هم معرفي شوند ودستورجلسه مشتركا مرور گردد.
در جلسات بايد تصميماتي كه در جلسات قبل اتخاذگرديده اند و اينكه چقدر از
آنها اجرا شده اند مرور گردند و سپس به بحث درمورد اقلام جديد پرداخت .
جمع
بندي و صدور مستندات نهايي كارگاه : در برگزاري هركدام از جلسات و بويژه
درپايان آن بايد نسبت به مستندسازي تمامي تصميمات و ثبت نتايج بررسي نمونه
ها وسيستم هاي ساخته شده اقدام نمود و وظايفي كه بايد تا جلسات بعدي توسط
هركدام ازشركت كنندگان صورت گيرد تدوين و مشخص گردد. پس از اتمام جلسات
كارگاه تمامي صورتجلسات بايد براي شركت كنندگان ارسال گشته و تاريخ جلسات
بعدي تعيين گردد.5 - شرايط استفاده از RADروش
RAD تاكيد عمده را بر تشكيل كارگاهها و نمونه سازي با استفاده از ابزارهاي
پيشرفته "CASETOOLS" مي گذارد. زيرا كه در اين روش تغيير و بازنگري اجتناب
ناپذيراست و فقط با استفاده از ابزارهاي پيشرفته مي توان تغييرات را
پيوسته اعمال كرد.
در روش RAD چون طراح از ابتدا نمونه ها را براي
نظرخواهي از ديگران مي سازد، نه تنها از انتقاد و ايرادگيري از آنها نگران
نمي شود بلكه از اين كار استقبال مي كند. چون انجام اصلاحات در فازهاي
اوليه پروژه خيلي راحت تر و كم هزينه تر از اصلاحات درمراحل پاياني پروژه
است .
از عوامل ديگري كه در موفقيت به كارگيري اين روش دخالت دارد
انتخاب درست افرادي است كه در كارگاه شركت مي كنند. بايد سعي شود اين گروه
زياد بزرگ نشود وافرادي در اين كارگاههاشركت كنندكه درتصميم گيري يا
اظهارنظر كارشناسي مفيدوموثرباشند. تجربه نشان داده است كه فنون نمونه سازي
/ مرور / اصلاح "PROTOTYPE/REVIEW/CORRECT" كه مي تواند با يك گروه كوچك
يا متوسط وهمنظر به خوبي كار كند با گروههاي وسيع و داراي اختلاف نظر نمي
تواند به خوبي موفق باشد.
- در شرايط ذيل استفاده از روش RAD توصيه نمي شود:
الف
- جايي كه تعداد زيادي كاربر وجود دارد كه ازنظر جغرافيايي پراكنده اند و
امكان تشكيل يك گروه كوچك يا متوسط كه بتواند همه آنها را نمايندگي كند
وجود نداشته باشد.
ب - درصورتي كه طراحان سيستم "كارگزار يا مجري "
تجربه كافي در توسعه سيستم بااستفاده از ابزارهاي مهندسي نرم افزار بويژه
CASETOOLS نداشته باشند.
ج - درصورتي كه كاربران و تكنولوگ هاي صنعت در
زمينه كاري تحت بررسي داراي دانش و تجربه كافي نباشند و نتوانند محيط فني
پياده سازي سيستم و نيازهاي اطلاعاتي خود را به خوبي تعريف كنند.
د -
درصورتي كه محيط سيستم يا سيستم هاي مرتبط با آن در سازمان كارفرما به
دلايل سياسي ، اقتصادي و مديريتي دستخوش تغييرات زياد باشد و هر راه حل
اعتراض عده اي را برانگيزد به طوري كه نتوان به راه حل واحدي در رابطه با
مسائل كاربران و ساير عوامل ذينفع رسيد.6 - مراحل توسعه سيستم در روش RADمراحل
توسعه سيستم در روش RAD با روشهاي آبشاري متفاوت است ، حتي اين مراحل
دربين صاحبنظران مهندسي سيستم نيز يكي نيست و ما براي اينكه بتوانيم يك روش
واحد را دراينجا معرفي كنيم ، مراحل روش RAD رااز كتاب CASE METHOD
FAST-TRACK A RAD APPROACH از انتشارات اوراكل انتخاب و به طورخلاصه ذكر مي
كنيم .
در متدولوژي CASE METHOD اوراكل ، مراحل توسعه سيستم شامل
برنامه ريزي ،آناليز، طراحي ، ساخت و مستندسازي و انتقال است . باتوجه به
تفاوت مختصر روش RAD با روش فوق حدود پوشش دهي اين روش در مقايسه با روش
آبشاري در نمودارشماره 1 نمايش داده شده است .
براساس روش RAD در كتاب مذكور مراحل توسعه سيستم در اين روش عبارتند از:
مرحله برنامه ريزي ;
مرحله تعيين نيازها;
مرحله ساخت ;
مرحله انتقال .
اكنون به شرح مختصر هركدام از مراحل فوق مي پردازيم .
مرحله
برنامه ريزي : هدف اين مرحله دستيابي به يك تعريف روشن از حدود و
ثغورپروژه ، اولويت بندي اجزا پروژه و برنامه اجرايي پروژه است . در اين
رابطه توضيحات زيرمفيد است :
الف - معمولا حدود و ثغور با كمك تركيبي از
جلسات كارگاهي ، نمونه سازي و يا گرفتن بازخورد از كاربران انجام مي شود و
شامل تعيين اهداف ، فعاليتهاي عمده ، واحدهاي سازماني درگير در انجام
فعاليتها، ترتيب انجام فعاليتها و امثال آن است .
ب - اولويت بندي اجزا پروژه براساس روش زمان ثابت انجام مي شود و از اقلام اجباري تا اقلام غيرضروري تفكيك مي گردد.
ج
- برنامه اجرايي پروژه شامل برنامه نيازهاي پروژه "به منابعي مانند نيروي
انساني ،مالي ، سخت افزار و نرم افزار و غيره "، اقلام قابل تحويل پروژه ،
جزئيات فعاليتهاي پروژه ،طرح كيفيت پروژه ، برآوردهاي مالي و زماني پروژه ،
برنامه زماني وفرسنگ شمارهاي پروژه |"MILE STONES"مي شود.
مرحله آناليز
نياز: در روش آبشاري CASE METHOD اوراكل در مرحله آناليز بيشتر به اين
توجه مي شود كه چه كاري انجام مي شود و چگونه انجام شدن آن در مرحله طراحي
روشن مي شود. در روش RAD چنين مرزي وجود ندارد و جلسات كارگاهي ونمونه
سازيها ممكن است هر دو موضوع را شامل شود. هدف اين مرحله دستيابي به يك مدل
اطلاعاتي ، يك مدل عملياتي ، مدل معماري سيستم و يك نمونه ساخته شده است
.در اين خصوص توضيحات زير مفيد است :
الف - تعيين نيازها معمولا از طريق تشكيل جلسات كارگاهي انجام مي شود;
ب - قبل از نمونه سازي معمولا استانداردهاي صفحات نمايش ، گزارشها و امثال آن نمونه سازي شده و نظر كاربران اخذ مي گردد كه بدان
LOOK & FEEL PROTYPING "يعني ديدن و پسنديدن " گفته مي شود.
ج - نمونه سازي سيستم خود شامل فعاليتهاي ذيل است :
تعيين هدف نمونه سازي ;
طراحي پايگاه داده سيستم نمونه ;
طراحي عمليات سيستم نمونه ;
طراحي ساختار يا معماري سيستم نمونه ;
ساخت سيستم نمونه ;
بررسي ، مرور، اصلاح و نهايي سازي نمونه ساخته شده در جلسات كارگاهي با كاربران و ساير افراد ذينفع در پروژه .
ملاحظه
مي شود كه در اينجا پس از طراحي اوليه مدلهاي اطلاعاتي و عملياتي سيستم ،
نمونه سازي سيستم انجام مي شود و از طراحي تفصيلي سيستم و توليد هزاران
صفحه مدارك طراحي تفصيلي خبري نيست .
مرحله ساخت : در اين مرحله نمونه
ساخته شده در مرحله آناليز نياز، اصلاح و تكميل گرديده و سيستم نهايي ساخته
مي شود. در اين مرحله نيز هر سيستم پس از ساخت ، درجلسات پيوسته كارگاهي
يا به صورتهاي ديگر بررسي شده و نظر كاربران و ساير افرادذينفع اخذ مي شود و
بتدريج سيستم ساخته شده نهايي مي گردد. اين نوع ساخت راساخت تدريجي مي
گويند. صرف نظر از اينكه نمونه سازي چگونه و در چه سطحي انجام مي شود،
سيستم نهايي درهمين مرحله ساخته مي شود. خروجيهاي نهايي اين فاز عبارتنداز:
متن برنامه ها;
پايگاه داده هاي ساخته شده ;
سيستم ساخته شده ، تست شده و آماده اجرا;
مدارك كاربري و راهبري سيستم ;
مدارك تست سيستم .
در
اين مرحله ، علاوه بر تست برنامه ها كه توسط برنامه ساز صورت مي گيرد، دو
نوع تست ديگر مطرح است ، يكي تست سيستم كه براي هر سيستم صورت مي گيرد
وديگري تست يكپارچگي است كه بايد براي مجموعه سيستم هاي پروژه صورت گيرد.
مرحله انتقال : اين مرحله در روش RAD تفاوت چنداني با مرحله مشابه در روش آبشاري CASE METHOD ندارد و اهم فعاليتهاي آن عبارتند از:
الف - نصب و آموزش سيستم ;
ب - تست پذيرش سيستم توسط كاربران و انجام تحويل موقت ;
ج - اجراي موازي و اجراي آزمايشي سيستم ;
د - انتقال از سيستم قبلي به جديد;
ه - تحويل قطعي .
منابع
1- BOHEM, B -1998-. A SPIRAL MODEL OF SOFTWARE DEVELOPMENT AND ENHANCEMENT COMPUTER, 2161-72
2-BUDDE, R.ET. AL-1991-. PROTYPING, AN APPROACH TO EVOLUTIONARY SYSTEM DEVELOPMENT. BERLIN, SPRINGER VERLAG.
3- MARTIN. J. -1991-. RAPID SYSTE,S DEVE;P[,EMT" USA, MACMILLAN.
4- MARTIN.J.-1990-INFORMATION ENGINEERING, BOOK. 1, 2, 3, PRENTICE HALL
5-BARKER, R.ET AL. -1991- ORACLE CASE METHOD TASKS AND DELIVERABLES. WOKINGHAM ENGLAND, ADDISON-WESLEY
6- BARKER, R. -1990-ORACLE CASE METHOD ENTITY RELATIONSHIP MODELLING. WOKINGHAM, ENGLAND, ADDISON-WESLEY.
7- BARKER, R. AND LONGMAN, C. -1993-. ORACLE CASE METHOD FUNCTION AND PROCESSMODELLIN. WOKIN HAM, ENGLAND, ADDISON-WESLEY.
8- BARKER, R. AND CLEGG D.1994. ORACLE CASE METHOD, FAST - TRACK A RAD APPROACH, ADDISON-WESLEY
9- BILLINGS, C. AND BILLING, M. -1993- RAPID DEVELOPMENT WITH ORACLE CASE, A WORKSHOP APPROACH, ENGLAND, ADDISON-WESLEY.
10 - يوردون - ادوارد - تحليل ساخت يافته نوين . ترجمه
مرجان رضايي ، ماندانا كاوياني فرو محمد جواد بهرامي . از انتشارات سازمان
مديريت صنعتي ، 1376.
11 - شركت ا.اف . فرگوسن و سازمان مديريت صنعتي - متدولوژي توسعه سيستم هاي اطلاعاتي . از انتشارات سازمان مديريت صنعتي ، 1375.
21 - مدارك و مستندات توسعه سيستم هاي مختلف در شركت مهندسين پردازش
برای مهندسین بن بستی وجود ندارد...