فرایند تولید نرم‌افزار
فرایند تولید نرم‌افزار که با عنوان «چرخه حیات تولید نرم‌افزار» نیز شناخته میشود، ساختاری است که روی توسعه و تولید محصولات نرم‌افزاری اعمال میشود. عبارتهای مشابهی چون «چرخه حیات نرم‌افزار» و «فرایند نرم‌افزار» در این رابطه استفاده میشود. مدلهای گوناگونی نظیر فرایندهای(خاص) وجود دارند که هر کدام خط مشی مختص(آن فرایندها) برای انجام کارها و فعالیت‌های متنوع در طول فرایندها را مشخص می‌کنند. برخی عنوان می‌کنند که «طرح(مدل) چرخه حیات» یک عبارت بسیار عمومی است و «فرایند تولید نرم‌افزار» خیلی عبارت اختصاصی تری است. برای مثال خیلی از فرایندهای تولید نرم‌افزار ویژه‌ای هستند که خود زیر مجموعه چرخه حیات حلزونی به شمار می‌روند.
فعالیت‌های تولید نرم‌افزار
برنامه ریزی (امکان سنجی)
از مهمترین کارها در تولید نرم‌افزار استخراج نیازمندیها یا تحلیل نیازمندیهای آن سیستم است. مشتریان عمومی معمولاً تصور مفهومی، انتزاعی و مبهمی از نتیجه نهایی خواسته هایشان دارند و نمی‌دانند به درستی نرم‌افزار مورد نظرشان چه کاری باید انجام بدهد. در این مرحله نیازمندیهای ناتمام، پیچیده و مبهم، و حتی متضاد توسط مهندسان نرم‌افزار ماهر و مجرب شناسایی می‌شوند.در این برهه تکه نرم‌افزارهای آماده و تجربه شده وفعال ممکن است برای پایین آوردن ریسک(ومشکلات) نیازمندیها کمک می کنند. اول نیازمندیهای عمومی از کاربران جمع آوری می شد، و دامنه توسعه و تولید نرم‌افزار که باید تولید شود شناسایی و تحلیل می شود، و مستندات بصورت شفاف نوشته می شود.معمولاً به این مستند، مستنددامنه یا محدوده سیستم اطلاق می شود.
برخی قابلیت ها ممکن است در ابتدای پروژه به خاطر مسائل مالی یا نیازمندیهای غیر شفاف و نامشخص خارج از محدوده پروژه باشند.اگر تولید و توسعه نرم‌افزار برون سپاری شود(به شرکت های خارجی محول شود)، این مستندات به عنوان مستندات قانونی و حقوقی در نظر گرفته می شود بنابراین در صورت اتفاق هرگونه دعوای حقوقی یا ابهام در مورد تعهدات داده شده به کاربر، این مسائل قابل شفاف سازی خواهد بود.
پیاده سازی، آزمایش و تست و مستند سازی
پیاده سازی آن قسمت از فرایند تولید نرم‌افزار به شمار می رود که مهندسان نرم‌افزار در دنیای واقعی تمام کد های پروژه را می نویسند و به قول معروف برنامه نویسی می کنند.
تست و آزمون نرم‌افزار بخش لاینفک و مهم از فرایند تولید نرم‌افزار است . این قسمت از فرایند ها کمک می کند تا مشکلات سیستم بصورت سریع شناسایی شوند.
مستند سازی در تمام مراحل پروژه همچون : طراحی داخلی نرم‌افزار برای تعیین اهداف سیستم، نگهداری آینده و ارتقاء و بهبودی سیستم هرچند پروژه پایان یافته باشد انجام می شود.همچنین ممکن است این مستند سازی شامل نوشتن ساختار تکه های برنامه ظاهربرنامه کاربردی داخلی و خارجی هم باشند.این مطلب خیلی مهم است که همه چیز پروژه مستند سازی شود.
استقرار و نگهداری سیستم
استقرار و تحویل سیستم پس از اینکه تست مناسب و درخوری را گذراند و برای انتشار، فروش یا هرنوع توزیع برای محیط کار نهایی تایید شد انجام خواهد شد.
آموزش نرم‌افزار و پشتیبانی خیلی مهم است و خیلی از تولید کنندگان و توسعه دهندگان نرم‌افزارها اهمیت آن را درک نمی‌کنند.مهم نیست که چقدر زمان و برنامه ریزی توسط تیم تولید و توسعه نرم‌افزار برای ایجاد نرم‌افزار مصرف کرده اند اگر در آخر کار کاربری در سازمان نباشد تا آن نرم‌افزار را استفاده کند.مردم معمولاً در برابر تغییرات مقاومت نشان می دهند و از ماجراجویی در محیط ناآشنا اجتناب می کنند، برای همین در فاز استقرار، این خیلی مهم است کلاسهای آموزشی برای کاربران جدید نرم‌افزار گذاشته شود.
نگهداری و ارتقاء نرم‌افزاری برای پوشش، مسائل پوشش داده نشده یا نیازمندیهای جدیدممکن است مدت خیلی زیادی حتی بیشتر از زمان اولیه تولید نرم‌افزار، زمان بگیرد. این مرحله ممکن است نیاز باشد تا کد های برنامه نویسی جدیدی که در طراحی اصلی برنامه نیز دیده نشده اضافه شود تا مسائل و مشکلات دیده نشده حل شوند یا ممکن است کاربر درخواست عملیات اصلی دیگری بکند و برنامه نویسی های جدیدی برای برآورده کردن نیازهای جدید انجام گیرد.اگر هزینه کار فاز نگهداری از ۲۵ درصد هزینه فاز قبلی (پیاده سازی)بیشتر باشد، این احتمال وجود دارد که کیفیت کلی فاز قبلی خیلی ضعیف بوده باشد.در این صورت مدیران پروژه باید گزینه ی ایجاد مجدد سیستم (یا بخشی از سیستم) را قبل از اینکه هزینه های نگهداری غیر قابل کنترل شود را مطرح کنند.
مدلهای تولید نرم‌افزار
مدل آبشاری
مدل آبشار فرایند ها را به گونه ای نشان می دهد، که کجا تولید کنندگان نرم‌افزار(برنامه نویسان) فازهای زیر را به ترتیب انجام دهند:
1. شناسایی نیازمندیها (تحلیل نیازها- امکان سنجی)
2. طراحی نرم‌افزار
3. ایجاد و یکپارچه سازی
4. تست (یا تایید سیستم)
5. استقرار(یا نصب سیستم)
6. نگهداری سیستم
در سختگیرانه ترین حالت آبشاری، بعد از اینکه هر فاز کاملاً پایان پذیرفت، به مرحله بعدی می رویم. بازبینی که اجازه ایجاد تغییرات در سیستم را بدهد( که ممکن است شامل تغییرات فرایندهای کنترل رسمی باشد) فقط قبل از رفتن به مرحله بعد امکان پذیر است .همچنین بازبینی ممکن است جهت اطمینان از پایان قطعی این فاز (مرحله) بکار گرفته شود . فازی که معیارهای تکمیل آن کامل شده، معمولاً با عنوان دروازه اطلاق می شود که نشان می دهد پروژه از فاز فعلی به فاز بعدی منتقل شده است .مدل آبشاری از بازبینی و تجدید نظر فازهای قبلی که کامل شده اند، ممانعت به عمل می آورد.این عدم انعطاف پذیری در مدل آبشاری محض، دست مایه انتقاد، پشتیبانی کنندگان مدلهای انعطاف پذیر است .
مدل حلزونی
خصوصیت کلیدی مدل حلزونی مدیریت ریسک در تمام مراحل چرخه تولید نرم‌افزار است . در سال ۱۹۸۸ میلادی بری بوهم به صورت رسمی مدل حلزونی فرایند تولید نرم‌افزار را منتشر کرد، که ترکیبی از بعضی کلیدهای تایید شده متدولوژی مدل آبشاری و نمونه سازی سریع است، اما احساس می شود مدل ارائه شده تاکید در ناحیه های کلیدی(مدل آبشاری) را با متدهای دیگری همچون بررسی دقیق و تحلیل دائمی ریسک ها، سیستم های خاص مناسب برای سیستم های پیچیده و بزرگ، کوتاه تر کرده است .
مدل حلزونی این روش را با چهار نمودار که نشان دهند فعالیت های زیر است، به تصویر می کشد که فرایند ها در چند مرحله تکرار انجام می شود :
1. تدوین و فرموله کردن برنامه ریزی خوب است برای : شناسایی اهداف سیستم، قسمت های انتخاب شده جهت پیاده سازی برنامه، محدودیت های واضح و مشخص پروژه.
2. تحلیل ریسک و مشکلات سیستم : ارزیابی تحلیلی برنامه های انتخاب شده، جهت مشخص کردن چگونگی شناسایی و از بین بردن ریسک ها.
3. پیاده سازی پروژه : پیاده سازی تولید نرم‌افزار و تایید کارایی سیستم .
مدل حلزونی مبتنی بر ریسک، بر اختیارانتخاب گزینه ها و محدودیت ها در سفارشها برای پشتیبانی استفاده مجدد نرم‌افزار و اینکه کیفیت نرم‌افزار می تواند در ادغام اهداف ویژه در تولید نرم‌افزار کمک می کند، تاکید می کند.
به هر حال مدل حلزونی شرایط محدود کننده زیر را دارا می باشد :
1. مدل حلزونی تحلیل ریسک ها را تاکید می کند و بنابراین کاربران باید این تحلیل را قبول کنند و فکری برایش بکنند(این مطالب را در نظر داشته باشند ).این مسئله نیازمند اعتماد متقابل و همچنین تمایل به هزینه کردن برای رفع ایرادات، درهنگام تولید نرم‌افزار است . و این دلیل استفاده شدن این مدل تولید نرم‌افزار پروژه های بزرگ است .
2. درصورتیکه در هنگام پیاده سازی تحلیل ریسک ها تاثیر منفی روی سود پروژه زیاد باشد نبایستی از مدل حلزونی استفاده گردد.
3. تولید و توسعه دهندگان نرم‌افزار بصورت فعال حواسشان به ریسکهای قابل حل خواهد بود و به دقت آنهارا در مدل حلزونی تحلیل می کنند.
مرحله اول تدوین و فرموله کردن یک برنامه برای رسیدن به اهداف با این محدودیتها، و پس از آن تلاش برای پیدا کردن و حذف تمام خطرات بالقوه(ریسک های بالقوه)از طریق تجزیه و تحلیل دقیق و در صورت لزوم، با ساخت نمونه اولیه است.اگر برخی ریسکها قابل حل نبودند در این صورت مشتریان باید تصمیم بگیرند که آیا می خواهند انجام پروژه را خاتمه دهند یا از ریسک های مورد نظر چشم پوشی کنند و به هر ترتیب ادامه دهند. در نهایت، نتایج ارزیابی شده و طراحی مرحله بعدی آغاز می شود. در حالت کلی یک مدل تکاملی است که به صورت مجموعه ای از نسخه های افزایشی توسعه میابد و همچنین در طی تکرار های اولیه ممکن است یک مدل کاغذی یا یک نمونه اولیه باشد ولی در طول تکرار های بعدی هر بار نسخه کاملتری از سیستم تولید میشود و این مدل به 3 تا 6 نواحی کاری تقسیم میشود
روش تکراری و افزایشی
روشی تکراری تولید نرم‌افزار اجازه ی ایجاد که پروژه در ابتدا از بخشهای کوچک شروع شود و به مرور زمان سیستم رشد کند تا کمک کند در این درگیری مشکلات مهم پیدا شوند قبل از اینکه فرضیات اشتباه باعث خراب شدن سیستم شوند. مدل تکرار فرایند ها بوسیله تولید کنندگان نرم‌افزارهای تجاری انتخاب و استفاده می شود چون این مدل اجازه می دهد تا نیازهای کاربرانی که در زمان طراحی دقیقاً نمی‌دانند چگونه نیازمندیهایشان از سیستم را معرفی کنند بصورت بالقوه برآورده شود.
روش تولید و توسعه چابک RAD => Rapid Application Development
روش مدل چابک تولید نرم‌افزار روش تکراری را بعنوان پایه کار استفاده می کند اما طرفداری نظریه سبکتر و محبوبیت بیشتر از روش سنتی است .مدل چابک از بازخوردها به جای برنامه ریزی بعنوان مکانیزم اصلی کنترل پروژه استفاده می کند.بازخورد ها بوسیله تست و آزمونهای مرتب و انتشار پیاپی و در بازه‌های کوتاه زمانی نرم‌افزارهای در حال تکامل تولید می شوند.
مدلهای متنوعی از فرایند چابک برای تولید نرم‌افزار استفاه می شود:
مدل ایکس پی (روش خیلی سریع)
در مدل تولید نرم‌افزار برنامه نویسی خیلی سریع (ایکس پی) در فازهای خیلی کوچک (یا مداوم) انجام و با فرایندهای دسته ای قدیمی تر تطبیق داده می شوند.فاز اول(که عمداً کامل نشده ) در طول مراحل ممکن است به جای اینکه ماهها و سالها در مدل آبشاری طول بکشد تا کامل شود، یک روز یا یک هفته وقت بگیرد.ابتدا یک تست خودکار برای ایجاد اهداف اساسی تولید نرم‌افزار نوشته می شود.سپس برنامه نویسی انجام می گیرد(توسط دوبرنامه نویس) که وقتی تمام تست ها را پشت سر گذاشته و دیگر هیچ تستی مورد نیازی به فکر برنامه نویسان نرسد کامل می شود.کار طراحی و معماری سیستم بعد از اینکه نه تستی وجود دارد و نه برنامه نویسی شده انجام می شود(خودشان را نشان میدهد). طراحی توسط برنامه نویسان انجام می شود.(فقط مشخصات نهایی و ترکیب طراحی و کد در تمام فرایندها در روش چابک مشترک هستند)عملیات اصلی ناقص سیستم برای کاربران( برخی از کاربران) نصب یا نمایش داده می شوند (توسط حداقل یکی از افراد تیم تولید کنندگان و برنامه نویسان ).دراینجاتمام عوامل پروژه دوباره شروع به نوشتن تست برای قسمت های مهم سیستم خواهند کرد.
مدل اسکرام SCRUM
نوشتار اصلی: اسکرام
اسکرام یک روش چابک، تکراری و افزایشی برای مدیریت پروژه است که معمولاً در مدل تولید نرم‌افزار چابک به عنوان نوعی متدولوژی توسعه نرم‌افزار دیده می شود.
با اینکه روش اسکرام در واقع برای مدیریت محصولات تولید و توسعه پروژه های پیشنهاد شده بود، استفاده آن در مدیریت پروژه های تولید نرم‌افزار متمرکز شد و همچنین امکان دارد جهت مدیریت تیم نگهداری نرم‌افزار یا مدیریت پروژه ها یا برنامه های عمومی مدیریت خط مشی ها استفاده شود.
برای اطلاعات بیشتر به کتاب «اصول و روش کاربردی اسکرام» نوشته کنی اس. روبین و ترجمه آقایان یوسف مهرداد بی بالان؛ شهاب الدین فرحبخش؛ علیرضا اسماعیلی مراجعه کنید.
مدلهای بهبود سازی
مدل سی ام ام آی (CMMI) مدل تکامل قابلیت یکپارچه سازی
مدل تکامل قابلیت یکپارچه سازی یا مدل سی ام ام آی (CMMI) یکی از مدلهای پیشنهادی و تکنیک های پیشتاز است . ارزیابی سازمان های مستقل و رتبه بندی در مورد کیفیت چگونگی تعریف فرایندهای آن سازمانها را دنبال می کند، نه بر کیفیت خود فرایندها یا نرم‌افزار تهیه شده است. مدل CMMI جایگزین CMM شده است.
ایزو ۹۰۰۰
ایزو ۹۰۰۰ یک استاندارد رسمی سازماندهی فراینده ساخت محصولات و روشی برای مدیریت و نظارت پیشرفت کارهاست .در اصل این استاندارد برای بخش تولید وساخت(صنعتی) ایجاد شد.ایزو ۹۰۰۰ همچنین برای فرایند تولید نرم‌افزار نیز به خوبی استفاده شده.مانند مدل CMMI مدرک ایزو ۹۰۰۰ هیچ تضمینی راجع به کیفیت نتایج نهایی ندارد و فقط فرایندهای کاری را فرموله و قالب استاندارد رسمی می دهد.
ایزو ۱۵۵۰۴
ایزو ۱۵۵۰۴، که با عنوان فرایند تشخیص و تعیین بهبود قابلیت نرم‌افزار (S.P.I.C.E)نیز شناخته می شود، "چارچوبی برای ارزیابی فرایندهای نرم‌افزار " است.این استاندارد تنظیمات قالب روشنی برای مقایسه فرایند ها به شمار می رود . S.P.I.C.E خیلی شبیه CMMI استفاده می شود.فرایند های این مدل برای مدیریت، کنترل، راهنمایی و نظارت تولید نرم‌افزار است . این مدل جهت سنجش سازماندهی تولید و توسعه یا تیم پروژه بصورت واقعی در طول مدت تولید نرم‌افزار استفاده می شود. تجزیه و تحلیل این اطلاعات برای شناسایی نقاط صعف و حرکت به سمت بهبودی پروژه استفاه می شود.همچنین برای تشخیص نقاط قوت پروژه که می تواند برای سازمان یا تیم پروژه ادامه پیدا کند یا برای امور مشترک یکپارچه شود.
با سپاس
