Se2 2 System Development Lifecycle

‫مهندسی نرم افزار ‪2‬‬ ‫چرخه تولید نرم افزار‬ ‫محسن کامیار‬ ‫دانشگاه فردوسی مشهد‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫روند تولید نرم افزار (‪)Software Process‬‬ ‫‪‬‬

‫‪‬‬

‫یک قالب کاری برای انجام فعالیت های لزم‬ ‫تا رسیدن به یک نرم افزار مفید‬

‫مهندسی نرم افزار (‪Software‬‬ ‫‪)Enginnering‬‬ ‫‪‬‬

‫‪‬‬

‫تکنولوژی های مورد استفاده برای پیش رفتن‬ ‫در مسیر یک روند تولید نرم افزاری‬ ‫شامل‪ :‬سیاست گذاری کیفیت‪ ،‬روند تولید‪،‬‬ ‫روش ها و ابزارها‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫تعریف مهندسی نرم افزار (‪)Fritz Bauer‬‬ ‫‪‬‬

‫‪‬‬

‫شامل ایجاد و به کارگیری مفاهیم مهندسی‬ ‫برای به دست آوردن یک نرم افزار تجاری‬ ‫قابل اطمینان و کارا برروی امکانات سخت‬ ‫افزاری موجود می باشد‪.‬‬

‫مهندسی نرم افزار یک تکنولوژی لیه ای‬ ‫به شکل زیر است‪.‬‬ ‫ابزارها‬ ‫روش ها‬ ‫فرآیند ها‬ ‫سیاست های کیفیتی‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫‪‬‬

‫هر فرآیند شامل تعدادی محدوده کلیدی‬ ‫فرآیند (‪ )K eyP rocessArea‬می باشد که‬ ‫تعیین کننده محصولت (مدل ها‪،‬‬ ‫مستندات‪ ،‬داده ها‪ ،‬گزارش ها‪ ،‬فرم ها و‬ ‫‪ ،)...‬نقاط مرزی (‪ ،)Mile Stones‬کیفیت‬ ‫قابل دسترس و مدیریت تغییرات می‬ ‫باشد‪.‬‬ ‫ابزارها ممکن است در قسمت های‬ ‫مختلفی مورد استفاده قرار گیرند‪.‬‬

‫چرخه تولید نرم افزار‬ :CASE ‫بعضی از انواع ابزارهای‬ BPM JBPM BEA Aqua Logic IBM Web Sphere

  

Model Analyzer Rational Suit





)MDA )Model Driven Architectures Open Blue Lab









‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫‪‬‬

‫در یک روند مهندسی هدف تحلیل‪،‬‬ ‫طراحی‪ ،‬ساخت‪ ،‬درستی یابی و مدیریت‬ ‫موجودیت های تکنولوژیک می باشد‪.‬‬ ‫بنابراین به طور کلی می توان این سؤال‬ ‫ها را اساسی دانست؟‬ ‫‪‬‬ ‫‪‬‬

‫‪‬‬

‫مسئله چیست؟‬ ‫خصوصیت مهم مورد استفاده برای حل‬ ‫مسئله چیست؟‬ ‫روند عملی نمودن راه حل چگونه است؟‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫چطور باید محصول ساخته شود؟‬ ‫با چه روندی می توان خطاهای موجود در‬ ‫طراحی و ساخت را کشف نمود؟‬ ‫روند پشتیبانی از محصول برای ایجاد تغییرات‬ ‫جهت افزایش کارایی‪ ،‬نیازهای جدید و ‪...‬‬ ‫چگونه باید باشد؟‬

‫سه فاز اصلی را می توان برای مهندسی‬ ‫نرم افزار در نظر گرفت‬ ‫‪‬‬

‫فاز تعریف‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬ ‫‪‬‬

‫‪‬‬

‫فاز توسعه‬ ‫فاز پشتیبانی‬

‫در فاز معرفی شناخت های زیر فراهم می‬ ‫گردند‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬

‫چه اطلعاتی باید پردازش شوند‬ ‫چه کارکردها و کارایی مد نظر می باشد‬ ‫چه واسط کاربری باید طراحی گردد‬ ‫چه محدودیت های طراحی موجود است‬ ‫معیار درستی یابی سیستم چیست‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫فاز توسعه به این فعالیت ها می پردازد‬ ‫‪‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪‬‬

‫ساختار نگهداری داده ها‬ ‫ساختار پیاده سازی یک کارکرد باید چگونه‬ ‫باشد‬ ‫چگونه می توان نیازهای واسط کاربر را تبدیل‬ ‫به جزئیات فنی نمود‬ ‫چطور طراحی به یک زبان برنامه نویسی‬ ‫تبدیل شود‬ ‫روند آزمایش و درستی یابی چگونه است‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫مسائل مطرح در فاز پشتیبانی‬ ‫‪‬‬

‫‪‬‬

‫انجام تغییرات جهت کارایی بهتر‬

‫این تغییرات در دسته های زیر خلصه می‬ ‫شوند‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

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

‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫‪‬‬

‫پیش گیری‪ :‬اصطلحا مهندسی دوباره نیز گفته‬ ‫می شود (‪ )reengineering‬و به عنوان یک‬ ‫نمونه پیشرفته در مهندسی دوباره نیازهای‬ ‫کسب و کار(‪ )Business‬می توان به ‪ERP‬‬ ‫اشاره نمود‪.‬‬

‫علوه بر این فازهای اساسی تعدادی‬ ‫فعالیت های پوششی نیز در هر پروژه‬ ‫موجود است‬ ‫‪‬‬ ‫‪‬‬

‫کنترل و پیگیری پروژه‬ ‫بازبینی های منظم و رسمی تکنولوژی های‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬

‫مدیریت پیکربندی محصول‬ ‫تولید مستندات‬ ‫مدیریت استفاده مجدد‬ ‫اندازه گیری‬ ‫مدیریت ریسک‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫می توان یک چرخه را به شکل کلی زیر‬ ‫مستقل از‬ ‫بیان نمود‪:‬‬ ‫قالب کاری کلی چرخه‬

‫نوع پروژه‬

‫فعالیت های قالب‬ ‫کاری‬ ‫مجموعه وظایف‬ ‫وظای‬ ‫نقاط مرزی‪ ،‬تحویل‬ ‫ف‬ ‫دادنی ها‬ ‫نقاط اصلی برای تضمین کیفیت‬ ‫محصول‬

‫فعالیت های پوششی‬

‫وابسته به‬ ‫پروژه‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫بر اساس طراحی چرخه می توان یک‬ ‫نمره به مجموعه استفاده کننده از آن‬ ‫چرخه تخصیص داد که نشانه کیفیت‬ ‫محصولت تولیدی می باشد‪ .‬این سطوح را‬ ‫مدل بلوغ توانایی ها (‪C apabilityMaturity‬‬ ‫‪ )Model‬می گوییم‪.‬‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫در حالت کلی می توان یک چرخه تولید‬ ‫نرم افزار را مانند یک فراکتال دانست‪L.( .‬‬ ‫‪)B. S. Raccoon‬‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫در این بخش انواع چرخه های تولید‬ ‫زیر را بررسی می کنیم‬ ‫‪‬‬

‫مدل های متوالی خطی (‪)Linear Sequential‬‬

‫‪‬‬

‫مدل های نمونه اولیه (‪)Prototyping‬‬

‫‪‬‬

‫مدل های تولید سریع کاربرد‬

‫‪‬‬

‫‪)Application Development‬‬ ‫مدل های روند تولید نرم افزار تکاملی‬ ‫(‪)Evolutionary Software Process‬‬

‫(‪Rapid‬‬

‫چرخه تولید نرم افزار‬ ‫‪‬‬

‫‪‬‬

‫مدل های توسعه مبتنی بر اجزاء‬ ‫‪)Based‬‬ ‫مدل های روش های رسمی (‪)Formal Method‬‬

‫(‪Component‬‬

‫مدل های متوالی خطی‬ ‫‪‬‬

‫در این دسته از مدل ها که به چرخه عمر‬ ‫کلسیک (‪ )Classic Life Cycle‬و یا مدل‬ ‫آبشاری (‪ )Water Fall Model‬نیز مشهورند‬ ‫فعالیت های اصلی زیر را داریم‪:‬‬ ‫‪‬‬

‫تحلیل نیازهای نرم افزاری‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬

‫حوزه داده ای مرتبط‬ ‫کارکردهای مورد نیاز‬ ‫کارایی مورد نیاز‬ ‫واسط کاربر مورد نیاز‬

‫مدل های متوالی خطی‬ ‫‪‬‬

‫طراحی‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬

‫‪‬‬ ‫‪‬‬

‫ساختار داده ها‬ ‫معماری نرم افزار‬ ‫طراحی واسط کاربر‬ ‫جزئیات اجرای یک کارکرد‬

‫تولید کد‬ ‫آزمایش‬ ‫‪‬‬

‫جزئیات منطق‬

‫مدل های متوالی خطی‬ ‫‪‬‬

‫‪‬‬

‫پشتیبانی‬ ‫‪‬‬

‫‪‬‬

‫جزئیات کارکردی‬ ‫ممکن است هر کدام از دسته فعالیت های‬ ‫پیشین را برروی یک قسمت از محصول‬ ‫اعمال نماید‬

‫این مدل پرکاربردترین روند مورد استفاده‬ ‫توسط تیم های تولید نرم افزار می باشد‬

‫مدل های متوالی خطی‬ ‫‪‬‬

‫با این وجود مشکلتی در این روش موجود‬ ‫است‪:‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫بعضی از پروژه های واقعی دارای ماهیت‬ ‫ترتیبی نیستند‪ .‬تغییرات در نیازهای سیستم‬ ‫باعث تداخل در عملکرد تیم تولید خواهد شد‪.‬‬ ‫مشتری نمی تواند در ابتدای کار تمام نیازهای‬ ‫خود را منعکس نماید‬ ‫مشتری باید صبر زیادی داشته باشد تا‬ ‫محصول را در آخرین مرحله مشاهده نماید‪.‬‬ ‫ممکن است مشکلت جدی در محصول وجود‬

‫مدل های نمونه اولیه‬ ‫‪‬‬

‫نمونه های موارد استفاده را می توان به‬ ‫صورت زیر داشت‪:‬‬ ‫‪‬‬ ‫‪‬‬

‫‪‬‬

‫مشتری اهداف کلی خود را می شناسد‬ ‫تیم تولید در مورد کارایی یک الگوریتم‬ ‫اطمینان ندارد‬ ‫در جاهایی که احتیاج به ارتباط نزدیک بین‬ ‫نیازهای مشتری‬ ‫انسان وجود دارد‬ ‫سیستم و ساخت‬ ‫تست توسط مشتری‬

‫مدل های نمونه اولیه‬ ‫‪‬‬

‫مشکلت موجود در این روش را می توان‬ ‫در موارد زیر خلصه نمود‬ ‫‪‬‬

‫‪‬‬

‫مشتری چون نسخه های نسبتا سریعی را از‬ ‫محصول می بیند متوجه کیفیت محصول‬ ‫نیست و ممکن است پس از مدتی موجه شود‬ ‫که باید کل نرم افزار از نو نوشته شود تا‬ ‫نیازهای کیفیتی برآورده شوند‬ ‫چون تولید به سرعت صورت می گیرد ممکن‬ ‫است سازگاری با نسخه خاصی از سیستم‬ ‫عامل داشته باشد‪.‬‬

‫مدل های تولید سریع کاربرد‬ ‫‪‬‬

‫این مدل در اصل ترکیبی از دو روش‬ ‫ترتیبی و مبتنی بر اجزاء می باشد‪.‬‬ ‫‪‬‬

‫‪‬‬

‫در صورت وجود شناخت کافی در مورد‬ ‫مشخصات و اجزاء سیستم قابل استفاده‬ ‫خواهد بود‪.‬‬ ‫عمدتا برای تولید سیستم های اطلعاتی در‬ ‫بازه های زمانی ‪ 60‬تا ‪ 90‬روزه مورد استفاده‬ ‫قرار می گیرد‪.‬‬

‫مدل های تولید سریع کاربرد‬ ‫‪‬‬

‫گام های اصلی در هر جزء شامل موارد‬ ‫زیر می باشد‪:‬‬ ‫‪‬‬

‫مدل کردن کسب و کار‬ ‫‪‬‬

‫‪‬‬

‫مدل کردن داده ها‬ ‫‪‬‬

‫‪‬‬ ‫‪‬‬

‫گردش اطلعات در بین بخش های مختلف کسب‬ ‫و کار‬ ‫تشخیص اشیاء داده ای مورد استفاده‬

‫مدل کردن فرآیندها‬ ‫تولید کاربرد‬ ‫‪‬‬

‫عمدتا از کدهای آماده برای تولید زیر سیستم ها‬

‫مدل های تولید سریع کاربرد‬ ‫‪‬‬

‫آزمایش و تحویل محصول‬ ‫‪‬‬

‫‪‬‬

‫با تست هر زیر سیستم هزینه تست کامل کاهش‬ ‫می یابد‬

‫اگر بتوان یک پروژه بزرگ را چنان بخش‬ ‫بندی نمود که هر بخش حداکثر در ‪ 3‬ماه‬ ‫قابل پیاده سازی باشد آنگاه ‪ RAD‬بهترین‬ ‫گزینه است‪.‬‬

‫مدل های تولید سریع کاربرد‬ ‫‪‬‬

‫نمایی از مدل های تولید سریع کاربرد‬

‫آزمایش و‬ ‫تحویل‬ ‫محصول‬

‫تولید‬ ‫کاربرد‬

‫مدل‬ ‫کردن‬ ‫فرآیندها‬

‫مدل‬ ‫کردن‬ ‫داده ها‬

‫آزمایش و‬ ‫تحویل‬ ‫محصول‬

‫گروه سوم‬ ‫مدل‬ ‫کردن‬ ‫کسب و‬ ‫کار‬

‫تولید‬ ‫کاربرد‬

‫مدل‬ ‫کردن‬ ‫فرآیندها‬

‫آزمایش و‬ ‫تحویل‬ ‫محصول‬

‫گروه دوم‬ ‫مدل‬ ‫کردن‬ ‫کسب و‬ ‫مدل‬ ‫کار‬ ‫کردن‬ ‫داده ها‬

‫مدل کردن‬ ‫کسب و‬ ‫کار‬ ‫مدل کردن‬ ‫داده ها‬

‫مدل کردن‬ ‫فرآیندها‬ ‫تولید‬ ‫کاربرد‬

‫گروه اول‬

‫مدل های تولید سریع کاربرد‬ ‫‪‬‬

‫مشکلت عمده این روش را می توان به‬ ‫شرح زیر ذکر نمود‪:‬‬ ‫‪‬‬

‫‪‬‬

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

‫مدل های تولید سریع کاربرد‬ ‫‪‬‬

‫‪‬‬

‫همه کاربردها برای ‪ RAD‬مناسب نیستند‪،‬‬ ‫سیستم بایدکامل قسمت یندی شده باشد‬ ‫‪ RAD‬برای کاربردهایی که از نظر تکنولوژی‬ ‫دارای ریسک بالیی هستند قابل استفاده نمی‬ ‫باشد‪.‬‬

‫مدل های روند تولید نرم افزار‬ ‫تکاملی‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫یک نرم افزار با توجه به وابستگی که به‬ ‫نیازهای انسانی دارد باید مدام در حال‬ ‫تغییر باشد‪ .‬شاید بهترین راه ارتباط دائم با‬ ‫مشتری برای برآورده کردن نیازهای وی‬ ‫باشد‬ ‫اما حدودی که در یک پروژه برروی زمان و‬ ‫هزینه وجود دارد اجازه چنین کاری را نمی‬ ‫دهد‬ ‫بهترین راه ارائه روندی است که در آن این‬

‫مدل های روند تولید نرم افزار‬ ‫تکاملی‬ ‫‪‬‬

‫‪‬‬

‫حتی در روند نمونه اولیه نیز مسئله تکامل‬ ‫نیازها و تغییر آن ها دیده نشده است‪ ،‬بلکه‬ ‫تنها نمایی از شناخت انجام شده نمایش‬ ‫داده می شود تا تنها صحت شناخت انجام‬ ‫شده تأیید شود‪.‬‬ ‫همه روشهای تکاملی مبتنی بر تعدادی‬ ‫تکرار می باشند که در تمام این تکرارها‬ ‫همه گام های اساسی تولید حضور دارند و‬ ‫تنها سهم آن ها در هر تکرار متفاوت‬

‫مدل های روند تولید نرم افزار‬ ‫تکاملی‬ ‫‪‬‬

‫این مدل ها را می توان در دسته های زیر‬ ‫بررسی نمود‪:‬‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬

‫مدل‬ ‫مدل‬ ‫مدل‬ ‫مدل‬

‫افزایشی‬ ‫حلزونی‬ ‫حلزونی برد – برد‬ ‫توسعه همزمان‬

‫مدل افزایشی‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫در این روش در هر تکرار یک روند خطی‬ ‫متوالی مورد استفاده قرار می گیرد‬ ‫نتیجه تکرار اول را می توان محصول‬ ‫هسته ای اصلی دانست که مهم ترین‬ ‫کارکردها را پوشش می دهد‪.‬‬ ‫در پایان شناخت و تحلیل هر گام برنامه‬ ‫ریزی برای کارکردهایی که باید در تکرار‬ ‫بعدی تحویل شوند صورت می گیرد‪.‬‬

‫مدل افزایشی‬ ‫‪‬‬

‫نمای کلی از این روش را می توان به‬ ‫صورت زیر دید‪:‬‬

‫مدل افزایشی‬ ‫‪‬‬

‫‪‬‬

‫تفاوت اصلی با روند نمونه اولیه را می‬ ‫توان در این دانست که در این روند در‬ ‫پایان هر تکرار یک محصول قابل استفاده‬ ‫داریم و نه یک نما از محصول نهایی‬ ‫این مدل از دو جنبه مناسب می باشد‪:‬‬ ‫‪‬‬

‫در صورتی که در ابتدای پروژه نیروی انسانی‬ ‫کافی در دسترس نباشد و یا اطلعی از تعداد‬ ‫نیروی انسانی مورد نیاز نداشته باشیم‪ ،‬پس‬ ‫از تهیه نسخه اولیه در صورت نیاز نیروهای‬ ‫جدید جذب می گردند‬

‫مدل افزایشی‬ ‫‪‬‬

‫می توان ریسک ها را مدیریت نمود‪ .‬به عنوان‬ ‫مثال یک قطعه سخت افزاری مورد نیاز در‬ ‫یکی از بخش ها ممکن است آماده نباشد‪ .‬با‬ ‫انتقال آن به تکرارهای آخر این ریسک‬ ‫مدیریت بهتری می شود‪.‬‬

‫مدل حلزونی‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫این روند مهم ترین گزینه برای تولید سریع‬ ‫کاربردها در قالب چندین نسخه می باشد‬ ‫در این روند در تکرارهای اولیه محصول در‬ ‫حد مدل های داده و ‪ ...‬می باشد اما در‬ ‫گام های پایانی می توان به سمت‬ ‫محصولت واقعی تر حرکت نمود‪.‬‬ ‫در این روند هر تکرار دارای تعدادی ناحیه‬ ‫به نام نواحی وظایف است‪ .‬این ناحیه ها‬ ‫بین ‪ 3‬تا ‪ 6‬عدد می باشند‪.‬‬

‫مدل حلزونی‬ ‫‪‬‬

‫‪‬‬

‫هر ناحیه شامل تعدادی وظایف کاری می‬ ‫باشد‪ .‬این وظایف می توانند شامل فعالیت‬ ‫های پوششی که پیش از این صحبت‬ ‫کردیم نیز باشند‪.‬‬ ‫ناحیه های وظایف شامل موارد زیر می‬ ‫باشند‬ ‫‪‬‬

‫‪‬‬

‫ارتباط با مشتری‪ :‬طرح ریزی روند مناسب‬ ‫ارتباط با مشتری و انجام ارتباط جهت کسب‬ ‫اطلعات‬

‫مدل حلزونی‬ ‫‪‬‬

‫‪‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫تحلیل ریسک‪ :‬استخراج ریسک ها تکنیکی و‬ ‫مدیریتی‬ ‫مهندسی‪ :‬تهیه نمایی از کاربرد‬ ‫ساخت و تحویل‪ :‬تولید‪ ،‬تست‪ ،‬نصب و‬ ‫پشتیبانی کاربران‬ ‫برآورد مشتری‪ :‬دریافت بازخوردهای کاربران‬ ‫در مورد تولیدات صورت گرفته‬

‫مدل حلزونی در اصل یک پیاده سازی از‬ ‫مدل خطی در یک قالب کاری تکاملی می‬ ‫باشد‬

‫مدل حلزونی‬ ‫‪‬‬

‫نمای کلی‬ ‫‪Communicatio‬‬ ‫‪n‬‬

‫مدل حلزونی‬ ‫‪‬‬

‫نکات قابل توجه در مورد وظایف کاری‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫هر وظیفه را می توان به عنوان یک پروژه در‬ ‫حین پروژه کلی دید که در مرحله ای آغاز و‬ ‫در مرحله ای به پایان می رسد‬ ‫ممکن است در بازه های زمانی چند تا از این‬ ‫پروژه ها با هم فعال باشند‬

‫موفقیت این مدل با توجه به استفاده از آن‬ ‫در پروژه های بسیار بزرگ کامل وابسته به‬ ‫تجربه در تعیین ریسک ها می باشد‪.‬‬

‫مدل حلزونی برد – برد‬ ‫‪‬‬

‫‪‬‬

‫در شرایط ایده آل (مشتری به درستی‬ ‫تمام نیاز ها را منتقل کرده است و تیم‬ ‫پیاده سازی این نیاز ها را به درستی درک‬ ‫کرده است) مدل حلزونی بسیار خوب‬ ‫عمل خواهد کرد‪.‬‬ ‫اما این شرایط ایده آل عمدتا پیش نمی‬ ‫آیند و برای دستیابی به اطلعات کامل باید‬ ‫به داشتن بخشی تحت عنوان ارتباط با‬ ‫مشتری آن را در طول هر تکرار پخش‬

‫مدل حلزونی برد‪-‬برد‬ ‫‪‬‬

‫این فعالیت ها را می توان در موارد زیر‬ ‫خلصه نمود‪:‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫تعیین کننده افراد کلیدی (‪:)Stakeholder‬‬ ‫افرادی که بیشترین اهمیت را به کارکردهای‬ ‫مورد نظر در آن مرحله می دهند‬ ‫تعیین معیارهای افراد کلیدی برای سنجش‬ ‫موفقیت یا شکست در آن تکرار‬ ‫تطبیق معیارهای سنجش موفقیت با معیارها و‬ ‫محدودیت های تیم تولید با همکاری فرد‬ ‫کلیدی‬

‫مدل حلزونی برد‪-‬برد‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪‬‬

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

‫مدل حلزونی برد‪-‬برد‬ ‫‪‬‬

‫علوه بر اینها سه نقطه مرزی برای تعیین‬ ‫پیشرفت درست روند تولید در هر تکرار‬ ‫وجود دارد‬ ‫‪‬‬

‫‪‬‬

‫اهداف چرخه زندگی (‪L ifeCycle‬‬ ‫‪ :)Objectives‬اهداف هر فعالیت اصلی در‬ ‫چرخه تولید را تعیین می نماید‪ .‬مانند اهداف و‬ ‫کارکردهای اصلی از تولید این سیستم‬ ‫ساختار چرخه زندگی (‪L ifeCycle‬‬ ‫‪ :)Architecture‬اهدافی که در طول روند تولید‬ ‫باید در هر مرحله به دست آیند‪ .‬به عنوان‬

‫مدل حلزونی برد‪-‬برد‬ ‫‪‬‬

‫‪‬‬

‫قابلیت عملیاتی اولیه (‪I nitialOperational‬‬ ‫‪ :)Capability‬اهدافی که باید در طول استقرار‬ ‫مورد بررسی قرار گیرند‪ .‬از جمله نیروهای‬ ‫مورد نیاز جهت همکاری‪ ،‬آماده سازی سایت‬ ‫کامپیوتری و ‪...‬‬

‫این نقاط مرزی به تعیین پایان موفقیت‬ ‫آمیز یک تکرار کمک شایانی می نمایند‪.‬‬

‫مدل توسعه همزمان‬ ‫‪‬‬

‫‪‬‬

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

‫مدل توسعه همزمان‬ ‫‪‬‬

‫‪‬‬

‫شاید راه حل بهتر برای کنترل چنین‬ ‫فعالیت هایی وجود یک شمای کلی از‬ ‫ارتباط بین فرآیندها باشد تا بتوان کنترل‬ ‫بهتری برروی اجرای آن ها داشت‬ ‫راه حلی که تا کنون در این زمینه مطرح‬ ‫شده است طراحی نمودارهای حالت برای‬ ‫هر فعالیت است‪ .‬ورود به این نمودار‬ ‫حالت با رخ دادن یک رویداد صورت می‬ ‫گیرد‪.‬‬

‫مدل توسعه همزمان‬ ‫‪‬‬

‫به عنوان نمونه‬ ‫نمودار مقابل را می‬ ‫توان برای فعالیت‬ ‫تحلیل در نظر‬ ‫گرفت‪:‬‬

‫مدل توسعه همزمان‬ ‫‪‬‬

‫‪‬‬

‫به عنوان مثال فرض کنید که در زمان‬ ‫طراحی به یک تناقض در تحلیل برخورد‬ ‫می کنیم‪ .‬چنین تناقضی ما را به حالت‬ ‫‪ done‬از نمودار حالت وارد می کند و از‬ ‫آنجا باید وارد حالت ‪Awaiting Changes‬‬ ‫شویم‪.‬‬ ‫در این مدل‪ ،‬فعالیت ها از دو دیدگاه‬ ‫مختلف نگریسته می شوند‪:‬‬ ‫‪‬‬

‫دیدگاه سیستمی‪ :‬طراحی‪ ،‬یکپارچه سازی و‬

‫مدل های توسعه مبتنی بر اجزاء‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫تکنولوژی های شیءگرا نمونه بسیار مهمی‬ ‫در زمینه طراحی مبتنی بر اجزاء محسوب‬ ‫می گردند‪.‬‬ ‫این مدل در اصل یک نمونه از روندهای‬ ‫تکاملی محسوب می شود‪ .‬اما اصول‬ ‫تکرارهای خود را بر اساس اجزاء اصلی‬ ‫سیستم معرفی می نماید‪.‬‬ ‫این مدل به علت تأکید برروی استفاده‬ ‫مجدد از اجزاء توانسته است چرخه تولید‬ ‫را تا ‪ 70‬درصد و هزینه کلی را تا ‪ 84‬درصد‬

‫مدل های توسعه مبتنی بر اجزاء‬ ‫‪‬‬

‫نمای کلی از روند مبتنی بر اجزاء‬

‫مدل های توسعه مبتنی بر اجزاء‬ ‫‪‬‬

‫‪‬‬

‫‪Unified software development process‬‬ ‫یک نمونه از روندهای مبتنی بر اجزاء است‬ ‫که وارد صنعت شده و از زبان ‪Unified‬‬ ‫‪ Modeling Language‬برای بیان‬ ‫ساختارهای مورد نیاز جهت پیشبرد روند‬ ‫تولید استفاده می نماید‪.‬‬ ‫یک نمونه تجاری از این روند ‪Rational‬‬ ‫‪ Unified Process‬می باشد که نرم‬ ‫افزارهای کمکی زیادی برای این روند تولید‬

‫مدل های روش های رسمی‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫در این دسته از روندها یک زبان ریاضی‬ ‫برای بیان مشخصات نرم افزار مورد‬ ‫استفاده قرار می گیرد و از این طریق می‬ ‫توان ابهام ها‪ ،‬تناقض ها و ‪ ...‬را با استفاده‬ ‫از یک تحلیل ریاضی به دست آورد‪.‬‬ ‫یکی از پرکاربردترین روش های طراحی‬ ‫شده بر پایه این دسته از روندها را می‬ ‫توان ‪Cleanroom Software Engineering‬‬ ‫دانست‪.‬‬ ‫مهم ترین زبان در بیان مشخصات سیستم‬