Test
(صفحه‌ای جدید حاوی 'test page by Omid پرونده:Example.jpg' ایجاد کرد) |
|||
| (۳ ویرایش میانی توسط یک کاربر نشان داده نشده‌است) | |||
| سطر ۱: | سطر ۱: | ||
| − | + | == فعالیت‌های تولید نرم افزار == | |
| + | === برنامه ریزی (امکان سنجی) === | ||
| + | از مهمترین کارها در تولید نرم افزار استخراج نیازمندیها یا تحلیل نیازمندیهای آن سیستم است. مشتریان عمومی معمولا تصور مفهومی، انتزاهی و مبهمی از نتیجه نهایی خواسته هایشان دارند و نمی‌دانند به درستی نرم افزار مورد نظرشان چه کاری باید آنجا بدهد. در این مرحله نیازمندیهای ناتمام، پیچیده و مبهم، و حتی متضاد توسط مهندسان نرم افزار ماهر و مجرب شناسایی می‌شوند.در این برهه تکه نرم افزارهای آماده و تجربه شده وفعال ممکن است برای پایین آوردن ریسک(ومشکلات) نیازمندیها کمک می کنند. | ||
| + | اول نیازمندیهای عمومی از کاربران جمع آوری می شد، و دامنه توسعه و تولید نرم افزار که باید تولید شود شناسایی و تحلیل می شود، و مستندات بصورت شفاف نوشته می شود.معمولا به این مستند، مستنددامنه یا محدوده سیستم اطلاق می شود. | ||
| + | برخی قابلیت ها ممکن است در ابتدای پروژه به خاطر مسائل مالی یا نیازمندیهای غیر شفاف و نامشخص خارج از محدوده پروژه باشند.اگر تولید و توسعه نرم افزار برون سپاری شود(به شرکت های خارجی محول شود)، این مستندات به عنوان مستندات قانونی و حقوقی در نظر گرفته می شود بنابراین در صورت اتفاق هرگونه دعوای حقوقی یا ابهام در مورد تعهدات داده شده به کاربر، این مسائل قابل شفاف سازی خواهد بود. | ||
| − | + | === پیاده سازی، آزمایش و تست و مستند سازی === | |
| + | پیاده سازی آن قسمت از فرآیند تولید نرم افزار به شمار می رود که مهندسان نرم افزار در دنیای واقعی تمام کد های پروژه را می نویسند و به قول معروف برنامه نویسی می کنند. | ||
| + | |||
| + | تست و آزمون نرم افزار بخش لاینفک و مهم از فرآیند تولید نرم افزار است . این قسمت از فرآیند ها کمک می کند تا مشکلات سیستم بصورت سریع شناسایی شوند. | ||
| + | |||
| + | مستند سازی در تمام مراحل پروژه همچون : طراحی داخلی نرم افزار برای تعیین اهداف سیستم، نگهداری آینده و ارتقاء و بهبودی سیستم هرچند پروژه پایان یافته باشد انجام می شود.همچنین ممکن است این مستند سازی شامل نوشتن ساختار تکه های برنامه ظاهربرنامه کاربردی داخلی و خارجی هم باشند.این مطلب خیلی مهم است که همه چیز پروژه مستند سازی شود. | ||
| + | |||
| + | === استقرار و نگهداری سیستم === | ||
| + | استقرار و تحویل سیستم پس از اینکه تست مناسب و درخوری را گذراند و برای انتشار، فروش یا هرنوع توزیع برای محیط کار نهایی تایید شد انجام خواهد شد. | ||
| + | |||
| + | آموزش نرم افزار و پشتیبانی خیلی مهم است و خیلی از تولید کنندگان و توسعه دهندگان نرم افزارها اهمیت آن را درک نمی کنند.مهم نیست که چقدر زمان و برنامه ریزی توسط تیم تولید و توسعه نرم افزار برای ایجاد نرم افزار مصرف کرده اند اگر در آخر کار کاربری در سازمان نباشد تا آن نرم افزار را استفاده کند.مردم معمولا در برابر تغییرات مقاومت نشان می دهند و از ماجراجویی در محیط ناآشنا اجتناب می کنند، برای همین در فاز استقرار، این خیلی مهم است کلاسهای آموزشی برای کاربران جدید نرم افزار گذاشته شود. | ||
| + | |||
| + | نگهداری و ارتقاء نرم افزاری برای پوشش، مسائل پوشش داده نشده یا نیازمندیهای جدیدممکن است مدت خیلی زیادی حتی بیشتر از زمان اولیه تولید نرم افزار، زمان بگیرد. این مرحله ممکن است نیاز باشد تا کد های برنامه نویسی جدیدی که در طراحی اصلی برنامه نیز دیده نشده اضافه شود تا مسائل و مشکلات دیده نشده حل شوند یا ممکن است کاربر درخواست عملیات اصلی دیگری بکند و برنامه نویسی های جدیدی برای برآورده کردن نیازهای جدید انجام گیرد.اگر هزینه کار فاز نگهداری از ۲۵ درصد هزینه فاز قبلی (پیاده سازی)بیشتر باشد، این احتمال وجود دارد که کیفیت کلی فاز قبلی خیلی ضعیف بوده باشد.در این صورت مدیران پروژه باید گزینه ی ایجاد مجدد سیستم (یا بخشی از سیستم) را قبل از اینکه هزینه های نگهداری غیر قابل کنترل شود را مطرح کنند. | ||
| + | |||
| + | |||
| + | == مدلهای تولید نرم افزار == | ||
| + | === مدل آبشاری === | ||
| + | مدل آبشار فرآیند ها را به گونه ای نشان می دهد، که کجا تولید کنندگان نرم افزار(برنامه نویسان) فازهای زیر را به ترتیب انجام دهند: | ||
| + | # شناسایی نیازمندیها (تحلیل نیازها- امکان سنجی) | ||
| + | # طراحی نرم افزار | ||
| + | # ایجاد و یکپارچه سازی | ||
| + | # تست (یا تایید سیستم) | ||
| + | # استقرار(یا نصب سیستم) | ||
| + | # نگهداری سیستم | ||
| + | |||
| + | در سختگیرانه ترین حالت آبشاری، بعد از اینکه هر فاز کاملا پایان پذیرفت، به مرحله بعدی می رویم. بازبینی که اجازه ایجاد تغییرات در سیستم را بدهد( که ممکن است شامل تغییرات فرآیندهای کنترل رسمی باشد) فقط قبل از رفتن به مرحله بعد امکان پذیر است .همچنین بازبینی ممکن است جهت اطمینان از پایان قطعی این فاز (مرحله) بکار گرفته شود . فازی که معیارهای تکمیل آن کامل شده، معمولا با عنوان دروازه اطلاق می شود که نشان می دهد پروژه از فاز فعلی به فاز بعدی منتقل شده است .مدل آبشاری از بازبینی و تجدید نظر فازهای قبلی که کامل شده اند، ممانعت به عمل می آورد.این عدم انعطاف پذیری در مدل آبشاری محض، دست مایه انتقاد، پشتیبانی کنندگان مدلهای انعطاف پذیر است . | ||
| + | |||
| + | === مدل حلزونی === | ||
| + | خصوصیت کلیدی مدل حلزونی مدیریت ریسک در تمام مراحل چرخه تولید نرم افزار است . در سال ۱۹۸۸ میلادی بری بوهم به صورت رسمی مدل حلزونی فرآیند تولید نرم افزار را منتشر کرد، که ترکیبی از بعضی کلیدهای تایید شده متدولوژی مدل آبشاری و نمونه سازی سریع است، اما احساس می شود مدل ارائه شده تاکید در ناحیه های کلیدی(مدل آبشاری) را با متدهای دیگری همچون بررسی دقیق و تحلیل دائمی ریسک ها، سیستم های خاص مناسب برای سیستم های پیچیده و بزرگ، کوتاه تر کرده است . | ||
| + | |||
| + | مدل حلزونی این روش را با چهار نمودار که نشان دهند فعالیت های زیر است، به تصویر می کشد که فرآیند ها در چند مرحله تکرار انجام می شود : | ||
| + | # تدوین و فرموله کردن برنامه ریزی برخوب است ای : شناسایی اهداف سیستم، قسمت های انتخاب شده جهت پیاده سازی برنامه، محدودیت های واضح و مشخص پروژه. | ||
| + | # تحلیل ریسک و مشکلات سیستم : ارزیابی تحلیلی برنامه های انتخاب شده، جهت مشخص کردن چگونگی شناسایی و از بین بردن ریسک ها. | ||
| + | # پیاده سازی پروژه : پیاده سازی تولید نرم افزار و تایید کارایی سیستم . | ||
| + | |||
| + | مدل حلزونی مبتنی بر ریسک، بر اختیارانتخاب گزینه ها و محدودیت ها در سفارشها برای پشتیبانی استفاده مجدد نرم افزار و اینکه کیفیت نرم افزار می تواند در ادغام اهداف ویژه در تولید نرم افزار کمک می کند، تاکید می کند. | ||
| + | |||
| + | به هر حال مدل حلزونی شرایط محدود کننده زیر را دارا می باشد : | ||
| + | # مدل حلزونی تحلیل ریسک ها را تاکید می کند و بنابراین کاربران باید این تحلیل را قبول کنند و فکری برایش بکنند(این مطالب را در نظر داشته باشند ).این مسئله نیازمند اعتماد متقابل و همچنین تمایل به هزینه کردن برای رفع ایرادات، درهنگام تولید نرم افزار است . و این دلیل استفاده شدن این مدل تولید نرم افزار پروژه های بزرگ است . | ||
| + | # درصورتیکه در هنگام پیاده سازی تحلیل ریسک ها تاثیر منفی روی سود پروژه زیاد باشد نبایستی از مدل حلزونی استفاده گردد. | ||
| + | # تولید و توسعه دهندگان نرم افزار بصورت فعال حواسشان به ریسکهای قابل حل خواهد بود و به دقت آنهارا در مدل حلزونی تحلیل می کنند. | ||
| + | |||
| + | مرحله اول تدوین و فرموله کردن یک برنامه برای رسیدن به اهداف با این محدودیتها، و پس از آن تلاش برای پیدا کردن و حذف تمام خطرات بالقوه(ریسک های بالقوه)از طریق تجزیه و تحلیل دقیق و در صورت لزوم، با ساخت نمونه اولیه است.اگر برخی ریسکها قابل حل نبودند در این صورت مشتریان باید تصمیم بگیرند که آیا می خواهند انجام پروژه را خاتمه دهند یا از ریسک های مورد نظر چشم پوشی کنند و به هر ترتیب ادامه دهند. در نهایت، نتایج ارزیابی شده و طراحی مرحله بعدی آغاز می شود. | ||
| + | |||
| + | === روش تکراری و افزایشی === | ||
| + | روشی تکراری تولید نرم افزار اجازه ی ایجاد که پروژه در ابتدا از بخشهای کوچک شروع شود و به مرور زمان سیستم رشد کند تا کمک کند در این درگیری مشکلات مهم پیدا شوند قبل از اینکه فرضیات اشتباه باعث خراب شدن سیستم شوند. مدل تکرار فرآیند ها بوسیله تولید کنندگان نرم افزارهای تجاری انتخاب و استفاده می شود چون این مدل اجازه می دهد تا نیازهای کاربرانی که در زمان طراحی دقیقا نمی دانند چگونه نیازمندیهایشان از سیستم را معرفی کنند بصورت بالقوه برآورده شود. | ||
| + | |||
| + | === روش تولید و توسعه چابک === | ||
| + | روش مدل چابک تولید نرم افزار روش تکراری را بعنوان پایه کار استفاده می کند اما طرفداری نظریه سبکتر و مردم گرایی بیشتر از روش سنتی است .مدل چابک از بازخوردها به جای برنامه ریزی بعنوان مکانیزم اصلی کنترل پروژه استفاه می کند.بازخورد ها بوسیله تست و آزمونهای مرتب و انتشار نرم افزارهای در حال تکامل تولید می شوند. | ||
| + | |||
| + | مدلهای متنوعی از فرآیند چابک برای تولید نرم افزار استفاه می شود: | ||
| + | ==== مدل ایکس پی (روش خیلی سریع) ==== | ||
| + | در مدل تولید نرم افزار برنامه نویسی خیلی سریع (ایکس پی) در فازهای خیلی کوچک (یا مداوم) انجام و با فرآیندهای دسته ای قدیمی تر تطبیق داده می شوند.فاز اول(که عمدا کامل نشده ) در طول مراحل ممکن است به جای اینکه ماهها و سالها در مدل آبشاری طول بکشد تا کامل شود، یک روز یا یک هفته وقت بگیرد.ابتدا یک تست خودکار برای ایجاد اهداف اساسی تولید نرم افزار نوشته می شود.سپس برنامه نویسی انجام می گیرد(توسط دوبرنامه نویس) که وقتی تمام تست ها را پشت سر گذاشته و دیگر هیچ تستی مورد نیازی به فکر برنامه نویسان نرسد کامل می شود.کار طراحی و معماری سیستم بعد از اینکه نه تستی وجود دارد و نه برنامه نویسی شده انجام می شود(خودشان را نشان میدهد). | ||
| + | طراحی توسط برنامه نویسان انجام می شود.(فقط مشخصات نهایی و ترکیب طراحی و کد در تمام فرآیندها در روش چابک مشترک هستند)عملیات اصلی ناقص سیستم برای کاربران( برخی از کاربران) نصب یا نمایش داده می شوند (توسط حداقل یکی از افراد تیم تولید کنندگان و برنامه نویسان ).دراینجاتمام عوامل پروژه دوباره شروع به نوشتن تست برای قسمت های مهم سیستم خواهند کرد. | ||
| + | |||
| + | ==== مدل اسکرام ==== | ||
| + | اسکرام یک روش تکراری افزایشی برای مدیریت پروژه است که معمولا در مدل تولید نرم افزار چابک به عنوان نوعی مهندسی نرم افزار دیده می شود. | ||
| + | با اینکه روش اسکرام در واقع برای مدیریت محصولات تولیدو توسعه پروژه های پیشنهاد شده بود، استفاده آن در مدیریت پروژه های تولید نرم افزار متمرکز شد و همچنین امکان دارد جهت مدیریت تیم نگهداری نرم افزار یا مدیریت پروژه های یا برنامه های عمومی مدیریت خط مشی ها استفاده شود. | ||
| + | |||
| + | == مدلهای بهبود سازی == | ||
| + | === مدل سی ام ام آی (CMMI) مدل تکامل قابلیت یکپارچه سازی === | ||
| + | مدل تکامل قابلیت یکپارچه سازی یا مدل سی ام ام آی (CMMI) یکی از مدلهای پیشنهادی و تکنیک های پیشتاز است . ارزیابی سازمان های مستقل و رتبه بندی در مورد کیفیت چگونگی تعریف فرآیندهای آن سازمانها را دنبال می کند، نه بر کیفیت خود فرآیندها یا نرم افزار تهیه شده است. مدل CMMI جایگزین CMM شده است. | ||
| + | |||
| + | === ایزو ۹۰۰۰ === | ||
| + | ایزو ۹۰۰۰ یک استاندارد رسمی سازماندهی فرآینده ساخت محصولات و روشی برای مدیریت و نظارت پیشرفت کارهاست .در اصل این استاندارد برای بخش تولید وساخت(صنعتی) ایجاد شد.ایزو ۹۰۰۰ همچنین برای فرآیند تولید نرم افزار نیز به خوبی استفاده شده.مانند مدل CMMI مدرک ایزو ۹۰۰۰ هیچ تضمینی راجع به کیفیت نتایج نهایی ندارد و فقط فرآیندهای کاری را فرموله و قالب استاندارد رسمی می دهد. | ||
| + | |||
| + | === ایزو ۱۵۵۰۴ === | ||
| + | ایزو ۱۵۵۰۴، که با عنوان فرآیند تشخیص و تعیین بهبود قابلیت نرم افزار (S.P.I.C.E)نیز شناخته می شود، "چارچوبی برای ارزیابی فرآیندهای نرم افزار " است.این استاندارد تنظیمات قالب روشنی برای مقایسه فرآیند ها به شمار می رود . S.P.I.C.E خیلی شبیه CMMI استفاده می شود.فرآیند های این مدل برای مدیریت، کنترل، راهنمایی و نظارت تولید نرم افزار است . این مدل جهت سنجش سازماندهی تولید و توسعه یا تیم پروژه بصورت واقعی در طول مدت تولید نرم افزار استفاده می شود. تجزیه و تحلیل این اطلاعات برای شناسایی نقاط صعف و حرکت به سمت بهبودی پروژه استفاه می شود.همچنین برای تشخیص نقاط قوت پروژه که می تواند برای سازمان یا تیم پروژه ادامه پیدا کند یا برای امور مشترک یکپارچه شود. | ||
نسخهٔ کنونی تا ۲۳ اکتبر ۲۰۱۱، ساعت ۰۹:۱۰
محتویات |
[ویرایش] فعالیت‌های تولید نرم افزار
[ویرایش] برنامه ریزی (امکان سنجی)
از مهمترین کارها در تولید نرم افزار استخراج نیازمندیها یا تحلیل نیازمندیهای آن سیستم است. مشتریان عمومی معمولا تصور مفهومی، انتزاهی و مبهمی از نتیجه نهایی خواسته هایشان دارند و نمی‌دانند به درستی نرم افزار مورد نظرشان چه کاری باید آنجا بدهد. در این مرحله نیازمندیهای ناتمام، پیچیده و مبهم، و حتی متضاد توسط مهندسان نرم افزار ماهر و مجرب شناسایی می‌شوند.در این برهه تکه نرم افزارهای آماده و تجربه شده وفعال ممکن است برای پایین آوردن ریسک(ومشکلات) نیازمندیها کمک می کنند. اول نیازمندیهای عمومی از کاربران جمع آوری می شد، و دامنه توسعه و تولید نرم افزار که باید تولید شود شناسایی و تحلیل می شود، و مستندات بصورت شفاف نوشته می شود.معمولا به این مستند، مستنددامنه یا محدوده سیستم اطلاق می شود.
برخی قابلیت ها ممکن است در ابتدای پروژه به خاطر مسائل مالی یا نیازمندیهای غیر شفاف و نامشخص خارج از محدوده پروژه باشند.اگر تولید و توسعه نرم افزار برون سپاری شود(به شرکت های خارجی محول شود)، این مستندات به عنوان مستندات قانونی و حقوقی در نظر گرفته می شود بنابراین در صورت اتفاق هرگونه دعوای حقوقی یا ابهام در مورد تعهدات داده شده به کاربر، این مسائل قابل شفاف سازی خواهد بود.
[ویرایش] پیاده سازی، آزمایش و تست و مستند سازی
پیاده سازی آن قسمت از فرآیند تولید نرم افزار به شمار می رود که مهندسان نرم افزار در دنیای واقعی تمام کد های پروژه را می نویسند و به قول معروف برنامه نویسی می کنند.
تست و آزمون نرم افزار بخش لاینفک و مهم از فرآیند تولید نرم افزار است . این قسمت از فرآیند ها کمک می کند تا مشکلات سیستم بصورت سریع شناسایی شوند.
مستند سازی در تمام مراحل پروژه همچون : طراحی داخلی نرم افزار برای تعیین اهداف سیستم، نگهداری آینده و ارتقاء و بهبودی سیستم هرچند پروژه پایان یافته باشد انجام می شود.همچنین ممکن است این مستند سازی شامل نوشتن ساختار تکه های برنامه ظاهربرنامه کاربردی داخلی و خارجی هم باشند.این مطلب خیلی مهم است که همه چیز پروژه مستند سازی شود.
[ویرایش] استقرار و نگهداری سیستم
استقرار و تحویل سیستم پس از اینکه تست مناسب و درخوری را گذراند و برای انتشار، فروش یا هرنوع توزیع برای محیط کار نهایی تایید شد انجام خواهد شد.
آموزش نرم افزار و پشتیبانی خیلی مهم است و خیلی از تولید کنندگان و توسعه دهندگان نرم افزارها اهمیت آن را درک نمی کنند.مهم نیست که چقدر زمان و برنامه ریزی توسط تیم تولید و توسعه نرم افزار برای ایجاد نرم افزار مصرف کرده اند اگر در آخر کار کاربری در سازمان نباشد تا آن نرم افزار را استفاده کند.مردم معمولا در برابر تغییرات مقاومت نشان می دهند و از ماجراجویی در محیط ناآشنا اجتناب می کنند، برای همین در فاز استقرار، این خیلی مهم است کلاسهای آموزشی برای کاربران جدید نرم افزار گذاشته شود.
نگهداری و ارتقاء نرم افزاری برای پوشش، مسائل پوشش داده نشده یا نیازمندیهای جدیدممکن است مدت خیلی زیادی حتی بیشتر از زمان اولیه تولید نرم افزار، زمان بگیرد. این مرحله ممکن است نیاز باشد تا کد های برنامه نویسی جدیدی که در طراحی اصلی برنامه نیز دیده نشده اضافه شود تا مسائل و مشکلات دیده نشده حل شوند یا ممکن است کاربر درخواست عملیات اصلی دیگری بکند و برنامه نویسی های جدیدی برای برآورده کردن نیازهای جدید انجام گیرد.اگر هزینه کار فاز نگهداری از ۲۵ درصد هزینه فاز قبلی (پیاده سازی)بیشتر باشد، این احتمال وجود دارد که کیفیت کلی فاز قبلی خیلی ضعیف بوده باشد.در این صورت مدیران پروژه باید گزینه ی ایجاد مجدد سیستم (یا بخشی از سیستم) را قبل از اینکه هزینه های نگهداری غیر قابل کنترل شود را مطرح کنند.
[ویرایش] مدلهای تولید نرم افزار
[ویرایش] مدل آبشاری
مدل آبشار فرآیند ها را به گونه ای نشان می دهد، که کجا تولید کنندگان نرم افزار(برنامه نویسان) فازهای زیر را به ترتیب انجام دهند:
- شناسایی نیازمندیها (تحلیل نیازها- امکان سنجی)
- طراحی نرم افزار
- ایجاد و یکپارچه سازی
- تست (یا تایید سیستم)
- استقرار(یا نصب سیستم)
- نگهداری سیستم
در سختگیرانه ترین حالت آبشاری، بعد از اینکه هر فاز کاملا پایان پذیرفت، به مرحله بعدی می رویم. بازبینی که اجازه ایجاد تغییرات در سیستم را بدهد( که ممکن است شامل تغییرات فرآیندهای کنترل رسمی باشد) فقط قبل از رفتن به مرحله بعد امکان پذیر است .همچنین بازبینی ممکن است جهت اطمینان از پایان قطعی این فاز (مرحله) بکار گرفته شود . فازی که معیارهای تکمیل آن کامل شده، معمولا با عنوان دروازه اطلاق می شود که نشان می دهد پروژه از فاز فعلی به فاز بعدی منتقل شده است .مدل آبشاری از بازبینی و تجدید نظر فازهای قبلی که کامل شده اند، ممانعت به عمل می آورد.این عدم انعطاف پذیری در مدل آبشاری محض، دست مایه انتقاد، پشتیبانی کنندگان مدلهای انعطاف پذیر است .
[ویرایش] مدل حلزونی
خصوصیت کلیدی مدل حلزونی مدیریت ریسک در تمام مراحل چرخه تولید نرم افزار است . در سال ۱۹۸۸ میلادی بری بوهم به صورت رسمی مدل حلزونی فرآیند تولید نرم افزار را منتشر کرد، که ترکیبی از بعضی کلیدهای تایید شده متدولوژی مدل آبشاری و نمونه سازی سریع است، اما احساس می شود مدل ارائه شده تاکید در ناحیه های کلیدی(مدل آبشاری) را با متدهای دیگری همچون بررسی دقیق و تحلیل دائمی ریسک ها، سیستم های خاص مناسب برای سیستم های پیچیده و بزرگ، کوتاه تر کرده است .
مدل حلزونی این روش را با چهار نمودار که نشان دهند فعالیت های زیر است، به تصویر می کشد که فرآیند ها در چند مرحله تکرار انجام می شود :
- تدوین و فرموله کردن برنامه ریزی برخوب است ای : شناسایی اهداف سیستم، قسمت های انتخاب شده جهت پیاده سازی برنامه، محدودیت های واضح و مشخص پروژه.
- تحلیل ریسک و مشکلات سیستم : ارزیابی تحلیلی برنامه های انتخاب شده، جهت مشخص کردن چگونگی شناسایی و از بین بردن ریسک ها.
- پیاده سازی پروژه : پیاده سازی تولید نرم افزار و تایید کارایی سیستم .
مدل حلزونی مبتنی بر ریسک، بر اختیارانتخاب گزینه ها و محدودیت ها در سفارشها برای پشتیبانی استفاده مجدد نرم افزار و اینکه کیفیت نرم افزار می تواند در ادغام اهداف ویژه در تولید نرم افزار کمک می کند، تاکید می کند.
به هر حال مدل حلزونی شرایط محدود کننده زیر را دارا می باشد :
- مدل حلزونی تحلیل ریسک ها را تاکید می کند و بنابراین کاربران باید این تحلیل را قبول کنند و فکری برایش بکنند(این مطالب را در نظر داشته باشند ).این مسئله نیازمند اعتماد متقابل و همچنین تمایل به هزینه کردن برای رفع ایرادات، درهنگام تولید نرم افزار است . و این دلیل استفاده شدن این مدل تولید نرم افزار پروژه های بزرگ است .
- درصورتیکه در هنگام پیاده سازی تحلیل ریسک ها تاثیر منفی روی سود پروژه زیاد باشد نبایستی از مدل حلزونی استفاده گردد.
- تولید و توسعه دهندگان نرم افزار بصورت فعال حواسشان به ریسکهای قابل حل خواهد بود و به دقت آنهارا در مدل حلزونی تحلیل می کنند.
مرحله اول تدوین و فرموله کردن یک برنامه برای رسیدن به اهداف با این محدودیتها، و پس از آن تلاش برای پیدا کردن و حذف تمام خطرات بالقوه(ریسک های بالقوه)از طریق تجزیه و تحلیل دقیق و در صورت لزوم، با ساخت نمونه اولیه است.اگر برخی ریسکها قابل حل نبودند در این صورت مشتریان باید تصمیم بگیرند که آیا می خواهند انجام پروژه را خاتمه دهند یا از ریسک های مورد نظر چشم پوشی کنند و به هر ترتیب ادامه دهند. در نهایت، نتایج ارزیابی شده و طراحی مرحله بعدی آغاز می شود.
[ویرایش] روش تکراری و افزایشی
روشی تکراری تولید نرم افزار اجازه ی ایجاد که پروژه در ابتدا از بخشهای کوچک شروع شود و به مرور زمان سیستم رشد کند تا کمک کند در این درگیری مشکلات مهم پیدا شوند قبل از اینکه فرضیات اشتباه باعث خراب شدن سیستم شوند. مدل تکرار فرآیند ها بوسیله تولید کنندگان نرم افزارهای تجاری انتخاب و استفاده می شود چون این مدل اجازه می دهد تا نیازهای کاربرانی که در زمان طراحی دقیقا نمی دانند چگونه نیازمندیهایشان از سیستم را معرفی کنند بصورت بالقوه برآورده شود.
[ویرایش] روش تولید و توسعه چابک
روش مدل چابک تولید نرم افزار روش تکراری را بعنوان پایه کار استفاده می کند اما طرفداری نظریه سبکتر و مردم گرایی بیشتر از روش سنتی است .مدل چابک از بازخوردها به جای برنامه ریزی بعنوان مکانیزم اصلی کنترل پروژه استفاه می کند.بازخورد ها بوسیله تست و آزمونهای مرتب و انتشار نرم افزارهای در حال تکامل تولید می شوند.
مدلهای متنوعی از فرآیند چابک برای تولید نرم افزار استفاه می شود:
[ویرایش] مدل ایکس پی (روش خیلی سریع)
در مدل تولید نرم افزار برنامه نویسی خیلی سریع (ایکس پی) در فازهای خیلی کوچک (یا مداوم) انجام و با فرآیندهای دسته ای قدیمی تر تطبیق داده می شوند.فاز اول(که عمدا کامل نشده ) در طول مراحل ممکن است به جای اینکه ماهها و سالها در مدل آبشاری طول بکشد تا کامل شود، یک روز یا یک هفته وقت بگیرد.ابتدا یک تست خودکار برای ایجاد اهداف اساسی تولید نرم افزار نوشته می شود.سپس برنامه نویسی انجام می گیرد(توسط دوبرنامه نویس) که وقتی تمام تست ها را پشت سر گذاشته و دیگر هیچ تستی مورد نیازی به فکر برنامه نویسان نرسد کامل می شود.کار طراحی و معماری سیستم بعد از اینکه نه تستی وجود دارد و نه برنامه نویسی شده انجام می شود(خودشان را نشان میدهد). طراحی توسط برنامه نویسان انجام می شود.(فقط مشخصات نهایی و ترکیب طراحی و کد در تمام فرآیندها در روش چابک مشترک هستند)عملیات اصلی ناقص سیستم برای کاربران( برخی از کاربران) نصب یا نمایش داده می شوند (توسط حداقل یکی از افراد تیم تولید کنندگان و برنامه نویسان ).دراینجاتمام عوامل پروژه دوباره شروع به نوشتن تست برای قسمت های مهم سیستم خواهند کرد.
[ویرایش] مدل اسکرام
اسکرام یک روش تکراری افزایشی برای مدیریت پروژه است که معمولا در مدل تولید نرم افزار چابک به عنوان نوعی مهندسی نرم افزار دیده می شود. با اینکه روش اسکرام در واقع برای مدیریت محصولات تولیدو توسعه پروژه های پیشنهاد شده بود، استفاده آن در مدیریت پروژه های تولید نرم افزار متمرکز شد و همچنین امکان دارد جهت مدیریت تیم نگهداری نرم افزار یا مدیریت پروژه های یا برنامه های عمومی مدیریت خط مشی ها استفاده شود.
[ویرایش] مدلهای بهبود سازی
[ویرایش] مدل سی ام ام آی (CMMI) مدل تکامل قابلیت یکپارچه سازی
مدل تکامل قابلیت یکپارچه سازی یا مدل سی ام ام آی (CMMI) یکی از مدلهای پیشنهادی و تکنیک های پیشتاز است . ارزیابی سازمان های مستقل و رتبه بندی در مورد کیفیت چگونگی تعریف فرآیندهای آن سازمانها را دنبال می کند، نه بر کیفیت خود فرآیندها یا نرم افزار تهیه شده است. مدل CMMI جایگزین CMM شده است.
[ویرایش] ایزو ۹۰۰۰
ایزو ۹۰۰۰ یک استاندارد رسمی سازماندهی فرآینده ساخت محصولات و روشی برای مدیریت و نظارت پیشرفت کارهاست .در اصل این استاندارد برای بخش تولید وساخت(صنعتی) ایجاد شد.ایزو ۹۰۰۰ همچنین برای فرآیند تولید نرم افزار نیز به خوبی استفاده شده.مانند مدل CMMI مدرک ایزو ۹۰۰۰ هیچ تضمینی راجع به کیفیت نتایج نهایی ندارد و فقط فرآیندهای کاری را فرموله و قالب استاندارد رسمی می دهد.
[ویرایش] ایزو ۱۵۵۰۴
ایزو ۱۵۵۰۴، که با عنوان فرآیند تشخیص و تعیین بهبود قابلیت نرم افزار (S.P.I.C.E)نیز شناخته می شود، "چارچوبی برای ارزیابی فرآیندهای نرم افزار " است.این استاندارد تنظیمات قالب روشنی برای مقایسه فرآیند ها به شمار می رود . S.P.I.C.E خیلی شبیه CMMI استفاده می شود.فرآیند های این مدل برای مدیریت، کنترل، راهنمایی و نظارت تولید نرم افزار است . این مدل جهت سنجش سازماندهی تولید و توسعه یا تیم پروژه بصورت واقعی در طول مدت تولید نرم افزار استفاده می شود. تجزیه و تحلیل این اطلاعات برای شناسایی نقاط صعف و حرکت به سمت بهبودی پروژه استفاه می شود.همچنین برای تشخیص نقاط قوت پروژه که می تواند برای سازمان یا تیم پروژه ادامه پیدا کند یا برای امور مشترک یکپارچه شود.
