پژوهش مهندسی نرم افزار و روشهای آن - پایان نامه مهندسی نرم افزار و روشهای آن در 45 صفحه ورد قابل ویرایش
پژوهش مهندسی نرم افزار و روشهای آن در 45 صفحه ورد قابل ویرایش
فهرست مطالب
عنوان صفحه
فصل اول
مهندسی نرم افزار و روشهای آن 7
1-1 مهندسی نرم افزارچیست ؟ 7
2-1 ساخت یافتگی ومهندسی نرم افزارساخت یافته 7
3-1 شیء گرایی ومهندسی نرم افزار شیء گرا 8
4-1 معرفی Unified Modeling Language 8
5-1 تصورات غلط دررابطه با Rational Unified Process 9
فصل دوم
مقدمه ای بر( RUP)RationalUnified Process 11
1-2 RUP چیست ؟ 11
2-2 اصول ضروری RationalUnified Process 11
3-2 RUP وچرخه تکرار 12
4-2 فازها، اهداف ونکات اصلی 14
- فازشروع ( Inception ) 14
- فازشناخت ( Elaboration ) 15
- فازساخت (Constructin) 15
- فازانتقال ( Transition ) 15
5-2 نکات اصلی 15
- چهارعنصراصلی مدل سازی 15
6-2 نقش ها، فعالیت ها ومحصولات وجریان های کاری 16
- نقش ها(Roles ) 16
- فعالیت ها(Activites) 16
- محصولات (Artifacts ) 17
- جریان های کاری (Workflows ) 17
7-2 عناصردیگرموجود در RUP 17
8-2 ساختارایستای RUP 18
9-2 اصول RUP (جریان کاری ) 18
10-2 تعریف کلی RUP 19
11-2 چگونه می توان از RUPنهایت استفاده راکرد 19
12-2 مواردضروری دریک پروژه RUP 20
1-12-2 توسعه دید ونگرش 20
2-12-2 مدیریت برای اهداف 21
3-12-2 شناسایی وامکان سنجی ریسک ها 22
4-12-2 عوامل مورد پیگیری 22
5-12-2 امتحان کردن حالت تجاری 22
6-12-2 طراحی معماری قطعات سیستم 23
7-12-2 مراحل ساخت وآزمایش محصول 24
8-12-2 تصحیح وبازبینی نتیجه ها 24
9-12-2 مدیریت وکنترل تغییرات 24
10-12-2 مهیا کردن پشتیبانی ازکاربر 25
13-2 چرخه اصلی Rational Unified Process 25
1-13-2 تصورغلط 25
2-13-2 نکته مهم 26
3-13-2 جریان های کاری غیرثابت 27
فصل سوم
فازهای RUP 28
1-3 مقدمه 28
2-3 فاز Inception 28
1-2-3 فعالیت های لازم وضروری درفاز Inception 29
2-2-3 حیاتی ترین نکات (گلوگاه ها) درچرخ? حیات Inception 30
3-2-3- ارزیابی معیارها وضوابط 30
4-2-3 خروجی های الزامی فاز Inception 31
5-2-3 طرح توسعه نرم افزار (Software Development Plan ) 31
6-2-3 خروجی های اختیاری فاز Inception 33
3-3 فاز Elaboration 33
1-3-3 فعالیت های ضروری درفاز Elaboration 34
2-3-3 ساختارچرخه حیات فاز Elaboration 35
3-3-3 ارزیابی معیارها 35
4-3-3 محصولات وخروجی های الزامی این فاز 36
5-3-3 خروجی های اختیاری این فاز 38
4-3 فازساخت Construction 39
1-4-3 ذهنیت مقدماتی ازفاز Constructin 39
2-4-3 فعالیت های ضروری درفاز Constructin 40
3-4-3 نکات مهم درفاز Constructin 40
4-4-3 معیارارزیابی 40
5-4-3 خروجی های الزامی فاز Constructin 41
6-4-3 خروجی های اختیاری فاز Constructin 42
5-3 فاز انتقال Transition 42
1-5-3 فعالیت های ضروری فاز Transition 44
2-5-3 ارزیابی معیارها 44
3-5-3 خروجی های فاز Transition 45
منابع و مأخذ 47
چکیده
با توجه به نیاز روز افزون به استفاده از کامپیوتر و ضرورت توسعه و فراگیری علوم و فنون مربوط به آن به ویژه در زمینه مهندسی نرم افزار و با توجه به فقدان مطالب و منابع در این زمینه، بر آن شدیم تا گامی هرچند کوچک اما سازنده در این زمینه برداریم. مطالبی که پیش روی دارید حاصل تحقیقات مطالعات و گردآوری نکات مهم و اساسی در زمینه توسعه مهندسی نرم افزار به روش RUP می باشد. امید است که حاصل تلاش مان موثر و مفید واقع شود.
فصل اول
مهندسی نرم افزار وروش های آن
1-1 مهندسی نرم افزار چیست ؟
مهندسی نرم افزار، مدیریت برای به نظم درآوردن وقاعده مند نمودن وابستگی ها وارتباطات همه جنبه های محصول نرم افزاری که درتمامی مراحل سیستم شنا سایی وتعیین می گردد ، می باشد .
درواقع مهندسی نرم افزارفرایند تولید نرم افزار براساس فهم مسائل ومشکلات ، دستیابی به راه حل ها ودستیابی به تئوریها ، روش ها وابزارهای مورد نیاز ودرانتها رسیدن به هدف مطلوب می باشد .
مهندسی نرم افزارباید درطول ساخت ، نگهداری توسعه وانفصال یک نرم افزار برهمه عملکردها نظارت داشته باشد .
2-1 ساخت یافتگی ومهندسی نرم افزارساخت یافته
در رهیافت طراحی نرم افزار بر اساس روش ساحت یافته، ابتدا به مسئله در حالت کلی نگاه می شود، آنگاه مسئله به قسمت های کوچکتر شکسته می شود، این کار آنقدر تکرار می گردد تا مسائل خرد شده به اندازه کافی قابل فهم و ساده باشند. این مراحل به تجزیه عملیاتی معروف است. بیشتر اجزاء (توابع) در این روش نیاز به داده ها دارند که در سیستم عملیات در بانک های اطلاعاتی نگهداری می شوند. در واقع در این روش داده ها و توابع عملیاتی از هم تفکیک می گردند. پس از حل مسائل کوچکتر و ترکیب آنها با هم، مسئله اصلی قال حل خواهد بود.
مشکل اساسی در این رهیافت این است که اگر مسائل پیچیده باشد، سیستم در نگهداری اطلاعات با مشکل مواجه می شود. اگر در این سیستم ها نیاز باشد که تغییری صورت گیرد، این تغییر در مکان های زیادی باید اعمال گردد. در این صورت مشکلات تقریباً بزرگی به وجود می آید.
مهندسی نرم افزار ساخت یافته نیز بر اصول ذکر شده فوق مبتنی است. از جمله متدلوژی های مهندسی نرم افزار می توان به دو روش
( (structured Systems Analysis & Design Method SSADM روش تحلیل و طراحی سیستم های ساخت یافته و (Jackson System Development) JSD توسعه سیستم جکسون، اشاره نمود.
3-1 شی ء گرایی و مهندسی نرم افزار شیء گرا
از دید شیء گرایی داده ها و توابع به هم مرتبط هستند و در یک ماژول قرار می گیرند. در واقع هریک از این ماژول ها که مجموعه داده ها و توابع هستند که شیء نامیده می شوند. اشیاء در دنیای واقعی نیز می توانند به وسیله دو چیز مشخص گردند (مشخصه و رفتار).
اصول بنیادی که در شیء گرایی با آن مواجه هستیم، اشیاء، کلاس ها و وراثت می باشند. ایده شیء گرایی نیز به دنیای مهندسی نرم افزار راه یافته است و بر این اساس روش های مختلف مهندسی نرم افزار به وجود آمده است. که از آن جمله می توان به موارد ذیل اشاره نمود :
- (object Modeling Technique) OMT
- (Real – time Object – Oriented Modeling ) ROOM
-Object – Oriented Software Engineering ) OOSE)
-(Unified Modeling Language) UML
بدلیل آنکه از UML در مراحل توسعه نرم افزار (RUP) استفاده می گردد، در این قسمت جا دارد که در مورد UML توضیحات بیشتری بدهیم.
4-1 معرفی Unified Modeling Language
در میانه دهه نود، سه روش وجود داشت که از بقیه قویتر به نظر می رسید. این سه زبان که شروع به همگرایی کرده بودند، هریک دارای عناصری از دو روش دیگر نیز بود و دارای توانایی های منحصر بفردی نیز بودند :
- Booch برای طراحی و پیاده سازی عالی به نظر می رسید. گرچه روش بوچ خیلی قوی بود ولی علائم زبان به سختی درک می شد.
- OMT (تکنیک مدل سازی اشیاء) برای تجزیه و تحلیل بسیار عالی بود و بهترین روش برای سیستم های اطلاعاتی دارای داده های حساس به نظر می رسید.
- OOSE (مهندسی نرم افزار به روش شیء گرا) به عنوان یک مزیت به مدل Use Case معروف است. Use Case تکنیک توانمندی برای درک رفتار کل سیستم هستند. (محدوده ای که شیء گرایی به طور سنتی در آن ضعیف بود)
در سال 1994 Gim Rumbaugh تاسیس کننده OMT و در سال 1995 Ivar Jacobson بنیانگذار OOSE هم به گروه Booch در شرکت Rational پیوست. بدین ترتیب گروه سه نفر بوچ ، رامبو و جاکوبسن مدل یکپارچه UML را به وجود آوردند.
UML یک زبان استاندارد برای مدل سازی اشیاء در توسعه سیستم های شی ء گرا می باشد. UML از ترکیب و اتحاد سه متدلوژی و طراحی شیء گرای فوق به وجود آمده است.
هدف اصلی UML ایجاد یک زبان مشترک برای مهندسان و تولیدکنندگان نرم افزار در تحلیل و طراحی سیستم های شیء گراست.
5-1 تصورات غلط در رابطه با Rational Unified Process
علی رغم آنکه اغلب افراد تصور می کنند RUP یک متدلوژی و یا روش مهندسی نرم افزار است، باید اظهار داشت که این تصور و برداشت کاملاً نادرست می باشد.
RUP خود یک مدل از مهندسی نرم افزار است که بر تکرار و توسعه استوار است و هریک از متدها می تواند در قالب این مدل تکرار و توسعه نقش بگیرد. چنانچه قبلاً اظهار شد UML به عنوان زبان یکپارچه ساز و روشی شی ء گرا در مدل RUP استفاده می گردد. در واقع RUP استفاده می گردد. در واقع RUP رویکردها، وظایف و مسئولیت ها را در یک سازمان توسعه یافته نظام دهی می کند و هدف آن تضمین تولید محصول نرم افزاری خروجی با کیفیت بالا و منطبق بر نیازمندی های کاربران در زمان و هزینه پیش بینی شده می باشد. در واقع RUP پروسه تولید است و توسط شرکت نرم افزاری Rational پشتیبانی می گردد.
فصل سوم
فازهای RUP
1-3 مقدمه
از نظر مدیریتی ، چرخه حیات نرم افزاری RUP به چهار بازه زمانی که به ترتیب شامل Inception آغاز ، Elaboration جزئیات ، /Constrution ساخت و / Transition انتقال تقسیم می شود در واقعه هر فاز محدوده زمانی بین دو مرحله مهم و حیاتی از
چرخه حیات نرم افزاری را پوشش می دهد. در انتهای هر فاز یک ارزیابی برای تعیین اینکه آیا نتایج مورد انتظار و عینیات هر فاز به وقوع پیوسته یا خیر صورت می گیرد و اگر نتیجه ارزیابی رضایت بخش باشد، آنگاه پروژه اجازه می یابد که به فاز بعدی انتقال یابد.
2-3 فاز Inception
در این فاز هدف مهم و اساسی این مطلب می باشد که تمامی افراد ذینفع ) Stacke holder) بر روی مفاهیم موجود در پروژه توافق داشته باشند. بعلاوه در این فاز قبل از این که وارد روند کار شویم و اقدام به انجام پروژه نماییم باید هدف های کاری و ریسک ها و خطرات موجود در سیستم را تا حدی شناسایی کرده باشیم (هدف اولیه و مقدماتی).
در این فاز بر روی این مطلب متمرکز می شویم که در مورد یک سیستم آگاهی ها و معلومات بیشتری کسب کنیم. اما همچنان بر روی این نکته تمرکز خواهیم داشت که آیا یک پروژه با توجه به آگاهی ها دید کلی در ابتدای این فاز Inceotion ) ) شامل موارد زیر می باشد :
شناسایی محدودة نرم افزاری یک پروژه که شامل یک دید عملیاتی و آبجکتی و ضوابط قابل قبول و تعیین اهداف در راستای تولید محصول نهایی می باشد. (در واقع منظور از این بخش شناسایی محدوده و مرزهای پروژه می باشد).
شناحت حالت های بحرانی یا Use Case بحرانی سیستم ، ساخت یک سناریوی ابتدایی از عملکردهای سیستم به نحوی که با طراحی اصلی ما سازگار باشد. شناسایی و تشریح حداقل یک معماری برگزیده از روی سناریوی ابتدایی که قبلاً تهیه نموده ایم.
تخمین همة هزینه های مالی و هزینه های زمانی برای کل پروژه (این تخمین به صورت دقیق تر در فاز Elaboration که بزودی به آن خواهیم پرداخت، انجام خواهد گرفت).
تخمین ریسک ها و خطرات بالقوه که در این پروژه ممکن است با آنها برخورد داشته باشیم. ممکن است درصد اشتباه در تخمین و ارزیابی ما در این مرحله بالاتر باشد.
فراهم نمودن محیط پشتیبانی برای پروژه
1-2-3 فعالیت های لازم و ضروری در فاز Inception
قاعده سازی در حوزه پروژه : در این مرحله باید همة بخش ها ، زمینه های کاری و نیازمندی های مهم و اساسی و نکات ضروری و گلوگاه های سیستم شناسایی شوند و در قالب ضوابط قابل بول بگنجد بنحوی که همة شوابط و موارد شناسایی شده در دامنه سیستم و حوزه (محدودة) پروژه قرار بگیرند.
طراحی ، تصمیم گیری، آماده سازی یک کیس تجاری : در این قسمت ما دید تجاری به پروژه داریم که آیا انجام یک پروژه از نظر سود دهی مقرون به صرفه است یا خیر و یا ارزش انجام یک پروژه از نظر سوددهی تجاری مقرون به صرفه است یا خیر و یا ارزش انجام دادن دارد یا خیر. برای این منظور باید راه حل هایی برای مدیریت ریسک ها و خطرات موجود در پروژه همچنین راه حل های مدیریتی در برابر کارمندان (افرادی که در راستای تحقق پروژه فعالیت می کنند) ، طرح پروژه، هزینه ، زمان و میزان سود بخشی پروژه ارائه شود و ارزیابی گردد.
معرفی یک معماری(ساختار) برگزیده : در این بخش با توجه به ارزیابی سوددهی تجاری، تصمیم می گیریم که بخش های مختلف یک پروژه را بخریم یا بسازیم و یا استفادة مجدد از نمونه های قبلی نماییم تا بر اساس این تصمیم گیری بتوانیم هزینه های زمانی و منابع مورد نیازمان را تخمین بزنیم. البته برای پذیرش هریک از موارد فوق باید دلیل مناسب و کافی داشته باشیم و این استدلال به این صورت حاصل می شود که نیازمندی های پروژه را شبیه سازی کنیم یا یک نمونه اولیه داشته باشیم که با استفاده از آنها بالاترین خطرات و ریسک های پروژه را بتوانیم تخمین بزنیم . با استفاده از راهکار ارائه شده و تلاش برای تولید یک نمونه در طی این فاز باید از این مطلب اطمینان حاصل کنیم که آیا انجام یک پروژه سودهی دارد یا خیر و یا حتی این پروژه قابل حل می باشد یا خیر. البته راه فهمیدن و اطمینان کامل حاصل کردن این موضوع در دو فاز بعدی نیز ادامه پیدا می کند.
آماده سازی محیط برای پروژه : در این بخش باید محیط مناسبی را برای انجام پروژه ها آماده کنیم که این کار مستلزم تشخیص و ارزیابی صحیح پروژه و سازماندهی آن و انتخاب ابزار مناسب و تصمیم گیری لازم در مورد بخش هایی از فرآیند کاری که سبب بهبود عملکردها می شوند، می باشد.
2-2-3 حیاتی ترین نکات (گلوگاه ها) در چرخة حیات Inception
در انتهای فاز Inception مهمترین نکات و Object را مشخص می کنیم و سپس با بررسی چرخه حیات پروژه تصمیم می گیریم که نکاتی را که مهم و ضروری نیستند حذف کنیم.
3-2-3 ارزیابی معیارها و ضوابط
توافق افراد ذی نفع (Stackeholder) بر روی تعاریف حوزه و دامنه پروژه و تخمین زمانی و هزینه ای
توافق بر روی نیازمندی ها بر اساس فهم مشترک بدست آمده بر روی آنها
توافق بر روی تخمین هزینه ها، زمان، اولویت، ریسک ها و خطرات و فرآیندهایی که باعث توسعه سیستم می شود.
تعریف تمامی خطرات و ریسک ها و استراتژی مقابله با آنها
با توجه به نکات فوق، اگر در هریک از این گلوگاهها (نقاط بحرانی و حساس) با شکست مواجه شویم باید یا دوباره در مورد آن پروژه فکر کنیم و در غیر این صورت از آن صرف نظر نماییم.
خروجی فاز Inception به دو صورت الزامی و اختیاری (Optional) می باشند.
4-2-3 خروجی های الزامی فاز Inception
دید یا تصویر Vision)) : هستة احتیاجات و نیازمندی های پروژه می باشد که به عنوان مهمترین نکات در مستندات ما قرار می گیرند.
حالت تجاری ( Business Case) : تعریف توافق بر روی سودهای مالی و تجاری
عناوین خطرات و ریسک ها (Risk List) : شامل ریسک های شناسایی شده اولیه می باشد.
5-3-2 طرح توسعه نرم افزار ( Software Development Plan)
در طول فازهای ابتدایی در تمام مدت تعریف Object ها، طرح توسعه نرم افزاری باید مد نظر قرار بگیرد که شامل تخمین منابع (مخصوصاً زمان افرادی که بر روی پروژه کار می کنند و هزینه های توسعه در یک پروژه خاص) می شود که باید با نتایج حاصل از Business Case یعنی با هزینه های مالی سازگاری داشته باشد . تخمینی که در این مرحله می زنیم ممکن است تا انتهای پروژه ثابت بماند یا فقط تخمینی باشد برای رسیدن به فاز Elaboration (یعنی تخمین تکمیلی و ارزیابی صحیح تر در فاز بعدی صورت می گیرد) این تخمین و حدس ما ممکن است در این مرحله ناهنجار و نادرست باشد. به این ترتیب در هر فاز و در هر مرحله تکرار این تخمین و حدسیات ما باید به روز رسانی شوند. در واقع در تکرارها صحت و دقت تخمین های ما بیشتر می گردد.
رعایت نکات ذکر شده در هریک از خروجی های الزامی ممکن است چندین طرح متفاوت از یک محصول را ارائه دهد، اما به هر حال با توجه به نیازمندی ها و امکانات و شرایط ما باید بتوانیم یک نمونه یا یک محصول از روی طرح های ارائه شده و با توجه به راهنمایی های موجود، استخراج نماییم.
طرح تکرار ) Iteration Plan ) : طرح های موجود برای پروژه در این فاز، در ابتدای فاز Elaboration تکرار ، کامل و بازبینی می شوند.
شمایی از محصول، یک طرح قابل قبول از محصول خروجی Product Acceptance Plan ) ) در هر مرحله از تکرار، محصول بهبود می یابد و احتمال دارد نیازمندی های جدید نیز کشف گردد.
حالت توسعه ) Development Case) : تطابق و توسعة RUP به وسیلة مستندات و بازنگری نمونه های خاص از یک پروژه ( Project – Specific Templates) : استفاده از نمونه های مستند شدة ویژه ای برای تکامل و توسعة محصول خروجی.
راهنماهای مدل ( Use Case ها) : در این قسمت خط مشی ها تعیین می شود.
ابزارها Tools)) : ابزارهایی که پروژه ما را پشتیبانی می کنند در این قسمت انتخای می شوند. در واقع باید در این فاز ابزارها نصب شوند.
لغتنامه Glossary)) : ما باید برای این که مفهوم عبارات به کار برده شده در پروژه ی مان قابل درک برای دیگران باشد از یک لغتنامه استفاده کنیم یعنی یک لغتنامه تهیه کنیم و در هر مرحله آن را بازنگری نماییم. این لغتنامه بایستی برای همه افراد قابل فهم باشد.
مدل Use Case به همراه Actor ها : مهمترین Use Case ها و چیزهایی که در پروژه ایفای نقش می کنند (Actorها ) در این مرحله شناسایی می شوند همچنین طرح کلی جریان ها و رویدادها برای Use Case ها بحرانی تر و حساس تر با جزئیات بیشتر مورد بررسی قرار می گیرند.
6-2-3 خروجی های اختیاری فاز Inception
مدل دامنه (Domain Model) : در این مرحله، نکته های کلیدی و مهم سیستم با همراه مفاهیم سیستم را ثبت و بازنگری می کنیم. آنگاه مفاهیم درون پروژه را دسته بندی می کنیم سپس ارتباط بین این مفاهیم را ذخیره می نماییم.
نمونه سازی (Prototype) : یک نمونه زمانی قابل قبول است که بتواند دو قسمت Vision و Business Case را پشتیبانی کند و با آنها تطابق داشته باشد و ریسکها و خطرات پروژه را نیز شناسایی کند.
3-3 فاز Elaboration
-3 فاز ساخت (Construction)
هدف از فاز Construction ، پالایش نیازمندی هایی که هنوز باقی مانده اند و توضیح بیشتر در رابطه با آنها می باشد. همچنین اساس و مبنای سیستم در خط مشی معماری باید در این فاز تعیین و مشخص گردد به عبارت دیگر فاز Construction فرآیندی را تولید می کند که تاکید بر روی این مسئله دارد که مدیریت منابع و کنترل عملیات به نحوی باشد که هزینه ها، زمان و کیفیت بهینه باشد.
در این برداشت، مدیریت باید به نحوی باشد که بتوان ویژگی های معقولی را که در فاز Inception ، Elaboration توسعه یافته اند را بتوان با محصولاتی که از دو از بعدی یعنی Construction و Transition بدست می آیند جایگزین نمود و گسترش داد.
1-4-3 ذهنیت مقدماتی از فاز Construction
کاهش هزینه های توسعه به وسیله بهینه سازی منابع و پرهیز از اجزای نالازم (قسمت های غیر ضروری) و دوباره کاری.
رسیدن به کیفیت کافی (as Rapiblyas practiocal)
دستیابی به نسخه های مفید (آلفا، بتا و نسخه های تست شده)
کامل کردن، تحلیل ، طراحی و توسعه ، آزمایش و تست همه نیازمندی های مفید و لازم
تکرار و توسعه (افزایش توسعه) : این کار سبب به وجود آمدن محصول کامل برای فاز Transition می شود. در واقع این هدف مستلزم تشریح تماس Use Caseها و نیازمندی هایی که ممکن است هنوز باقی مانده باشند و همچنین محقق ساختن طراحی، کامل کردن پیاده سازی و تست نرم افزار می باشد.
دستیابی یا رسیدن به درجه ای از توازی کاری در تصمیم های توسعه، حتی در پروژه های کوچکتر نیز این توازی کاری موجود می باشد. در واقع کامپوننت هایی موجودند که می توان آنها را مستقل از دیگران در نظر گرفت وتوسعه داد. به این وسیله تیم های مختلف یک توازی طبیعی را به وجود می آورند. این موازی کار کردن می تواند به اندازه کافی به فعالیت های توسعه ما سرعت ببخشد اما از طرف دیگر پیچیدگی های مدیریت منابع و هماهنگ سازی جریان کاری را افزایش می دهد.
2-3-4 فعالیت های ضروری در فاز Construction
مدیریت منابع، کنترلا و بهینه سازی فرایندها
کامل کردن توسعه کامپوننت ها و تست کردن و آزمودن برای تعریف بهتر ارزیابی معیارها (یعنی بتوان معیارها را بهتر ارزیابی نمود.)
ارزیابی محصولات خروجی در مقابل معیارهای قابل قبول برای دیدگاهمان
3-4-3 نکات مهم در فاز Construction
Initial Operational Capability : در این قسمت محصول آماده است تا به تیم Transition منتقل شود. در این سمت همه فعالیت ها توسعه داده شده اند و در صورت آماده شدن آزمایش آلفا نیز صورت گرفته است. اضافه کردن یک راهنمای کاربری نیز به نرم افزار صورت گرفته است. همچنین توضیحی در مورد خروجی رایج و یا محصول آزاد شده در این قسمت موجود است.
4-4-3 معیار ارزیابی
این قسمت شامل سوالات زیر می شود :
آیا محصولات خارج شده از این فاز ثابت هستند و به اندازه کافی برای توسعه و گسترش و ارائه برای استفاده کاربران کامل شده اند.
آیا همه افراد ذینفع برای انتقال محصول به کاربران آماده هستند.
آیا برآورد هزینه منابع طبیعی و موجود و حقیقی در مقابل طرح ها هنوز قابل قبول می باشد.
فاز Transition ممکن است به وسیله یکی از موارد ذکر شده (خروجی ها) به تعویق بیفتد و این زمانی است که یک پروژه در رسیدن به این نکات مهم با شکست مواجه گردد. یعنی محصول فاز Transition ممکن است به تعویق و یا به تأخیر بیفتد در صورتی که ما در این نکات (مهم) با شکست مواجه شویم.
5-4-3 خروجی های الزامی فاز Construction
سیستم : سیستم قابل اجرایی که برای تست بتا آماده باشد.
طرح توسعه (Deployment Plan) : نسخه مقدماتی توسعه داده شده و بازبینی می گردد و تعیین هدف و خط مشی می شود.
مشخصات فروشنده
نام و نام خانوادگی : علیرضا دهقان
شماره تماس : 09120592515 - 02634305707
ایمیل :iranshahrsaz@yahoo.com
سایت :urbanshop.ir