فرآیند تولید نرم‌افزار

فرآیند تولید نرم افزار که با عنوان «چرخه حیات تولید نرم افزار» نیز شناخته می‌شود، ساختاری است که روی توسعه و تولید محصولات نرم افزاری اعمال می‌شود. عبارتهای مشابهی چون «چرخه حیات نرم افزار» و «فرآیند نرم افزار» در این رابطه استفاده می‌شود. مدلهای گوناگونی نظیر فرآیندهای(خاص) وجود دارند که هر کدام خط مشی مختص(آن فرآیندها) برای انجام کارها و فعالیت‌های متنوع در طول فرآیندها را مشخص می‌کنند. برخی عنوان می‌کنند که «طرح(مدل) چرخه حیات» یک عبارت بسیار عمومی است و «فرآیند تولید نرم افزار» خیلی عبارت اختصاصی تری است. برای مثال خیلی از فرآیندهای تولید نرم افزار ویژه‌ای هستند که خود زیر مجموعه چرخه حیات حلزونی به شمار می‌روند.

برنامه ریزی (امکان سنجی)[ویرایش]

از مهمترین کارها در تولید نرم افزار استخراج نیازمندیها یا تحلیل نیازمندیهای آن سیستم است. مشتریان عمومی معمولا تصور مفهومی، انتزاهی و مبهمی از نتیجه نهایی خواسته هایشان دارند و نمی‌دانند به درستی نرم افزار مورد نظرشان چه کاری باید آنجا بدهد. در این مرحله نیازمندیهای ناتمام، پیچیده و مبهم، و حتی متضاد توسط مهندسان نرم افزار ماهر و مجرب شناسایی می‌شوند.در این برهه تکه نرم افزارهای آماده و تجربه شده وفعال ممکن است برای پایین آوردن ریسک(ومشکلات) نیازمندیها کمک می کنند. اول نیازمندیهای عمومی از کاربران جمع آوری می شد، و دامنه توسعه و تولید نرم افزار که باید تولید شود شناسایی و تحلیل می شود، و مستندات بصورت شفاف نوشته می شود.معمولا به این مستند، مستنددامنه یا محدوده سیستم اطلاق می شود.

برخی قابلیت ها ممکن است در ابتدای پروژه به خاطر مسائل مالی یا نیازمندیهای غیر شفاف و نامشخص خارج از محدوده پروژه باشند.اگر تولید و توسعه نرم افزار برون سپاری شود(به شرکت های خارجی محول شود)، این مستندات به عنوان مستندات قانونی و حقوقی در نظر گرفته می شود بنابراین در صورت اتفاق هرگونه دعوای حقوقی یا ابهام در مورد تعهدات داده شده به کاربر، این مسائل قابل شفاف سازی خواهد بود.

پیاده سازی، آزمایش و تست و مستند سازی[ویرایش]

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

تست و آزمون نرم افزار بخش لاینفک و مهم از فرآیند تولید نرم افزار است . این قسمت از فرآیند ها کمک می کند تا مشکلات سیستم بصورت سریع شناسایی شوند.

مستند سازی در تمام مراحل پروژه همچون : طراحی داخلی نرم افزار برای تعیین اهداف سیستم، نگهداری آینده و ارتقاء و بهبودی سیستم هرچند پروژه پایان یافته باشد انجام می شود.همچنین ممکن است این مستند سازی شامل نوشتن ساختار تکه های برنامه ظاهربرنامه کاربردی داخلی و خارجی هم باشند.این مطلب خیلی مهم است که همه چیز پروژه مستند سازی شود.

استقرار و نگهداری سیستم[ویرایش]

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

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

نگهداری و ارتقاء نرم افزاری برای پوشش، مسائل پوشش داده نشده یا نیازمندیهای جدیدممکن است مدت خیلی زیادی حتی بیشتر از زمان اولیه تولید نرم افزار، زمان بگیرد. این مرحله ممکن است نیاز باشد تا کد های برنامه نویسی جدیدی که در طراحی اصلی برنامه نیز دیده نشده اضافه شود تا مسائل و مشکلات دیده نشده حل شوند یا ممکن است کاربر درخواست عملیات اصلی دیگری بکند و برنامه نویسی های جدیدی برای برآورده کردن نیازهای جدید انجام گیرد.اگر هزینه کار فاز نگهداری از ۲۵ درصد هزینه فاز قبلی (پیاده سازی)بیشتر باشد، این احتمال وجود دارد که کیفیت کلی فاز قبلی خیلی ضعیف بوده باشد.در این صورت مدیران پروژه باید گزینه ی ایجاد مجدد سیستم (یا بخشی از سیستم) را قبل از اینکه هزینه های نگهداری غیر قابل کنترل شود را مطرح کنند.

مدلهای تولید نرم افزار[ویرایش]

مدل آبشاری[ویرایش]

مدل آبشار فرآیند ها را به گونه ای نشان می دهد، که کجا تولید کنندگان نرم افزار(برنامه نویسان) فازهای زیر را به ترتیب انجام دهند:

1. شناسایی نیازمندیها (تحلیل نیازها- امکان سنجی)

2. طراحی نرم افزار

3. ایجاد و یکپارچه سازی

4. تست (یا تایید سیستم)

5. استقرار(یا نصب سیستم)

6. نگهداری سیستم

در سختگیرانه ترین حالت آبشاری، بعد از اینکه هر فاز کاملا پایان پذیرفت، به مرحله بعدی می رویم. بازبینی که اجازه ایجاد تغییرات در سیستم را بدهد( که ممکن است شامل تغییرات فرآیندهای کنترل رسمی باشد) فقط قبل از رفتن به مرحله بعد امکان پذیر است .همچنین بازبینی ممکن است جهت اطمینان از پایان قطعی این فاز (مرحله) بکار گرفته شود . فازی که معیارهای تکمیل آن کامل شده، معمولا با عنوان دروازه اطلاق می شود که نشان می دهد پروژه از فاز فعلی به فاز بعدی منتقل شده است .مدل آبشاری از بازبینی و تجدید نظر فازهای قبلی که کامل شده اند، ممانعت به عمل می آورد.این عدم انعطاف پذیری در مدل آبشاری محض، دست مایه انتقاد، پشتیبانی کنندگان مدلهای انعطاف پذیر است .

مدل حلزونی[ویرایش]

خصوصیت کلیدی مدل حلزونی مدیریت ریسک در تمام مراحل چرخه تولید نرم افزار است . در سال ۱۹۸۸ میلادی بری بوهم به صورت رسمی مدل حلزونی فرآیند تولید نرم افزار را منتشر کرد، که ترکیبی از بعضی کلیدهای تایید شده متدولوژی مدل آبشاری و نمونه سازی سریع است، اما احساس می شود مدل ارائه شده تاکید در ناحیه های کلیدی(مدل آبشاری) را با متدهای دیگری همچون بررسی دقیق و تحلیل دائمی ریسک ها، سیستم های خاص مناسب برای سیستم های پیچیده و بزرگ، کوتاه تر کرده است .

مدل حلزونی این روش را با چهار نمودار که نشان دهند فعالیت های زیر است، به تصویر می کشد که فرآیند ها در چند مرحله تکرار انجام می شود :

1. تدوین و فرموله کردن برنامه ریزی برخوب است ای : شناسایی اهداف سیستم، قسمت های انتخاب شده جهت پیاده سازی برنامه، محدودیت های واضح و مشخص پروژه.

2. تحلیل ریسک و مشکلات سیستم : ارزیابی تحلیلی برنامه های انتخاب شده، جهت مشخص کردن چگونگی شناسایی و از بین بردن ریسک ها.

3. پیاده سازی پروژه : پیاده سازی تولید نرم افزار و تایید کارایی سیستم .

مدل حلزونی مبتنی بر ریسک، بر اختیارانتخاب گزینه ها و محدودیت ها در سفارشها برای پشتیبانی استفاده مجدد نرم افزار و اینکه کیفیت نرم افزار می تواند در ادغام اهداف ویژه در تولید نرم افزار کمک می کند، تاکید می کند.

به هر حال مدل حلزونی شرایط محدود کننده زیر را دارا می باشد :

1. مدل حلزونی تحلیل ریسک ها را تاکید می کند و بنابراین کاربران باید این تحلیل را قبول کنند و فکری برایش بکنند(این مطالب را در نظر داشته باشند ).این مسئله نیازمند اعتماد متقابل و همچنین تمایل به هزینه کردن برای رفع ایرادات، درهنگام تولید نرم افزار است . و این دلیل استفاده شدن این مدل تولید نرم افزار پروژه های بزرگ است .

2. درصورتیکه در هنگام پیاده سازی تحلیل ریسک ها تاثیر منفی روی سود پروژه زیاد باشد نبایستی از مدل حلزونی استفاده گردد.

3. تولید و توسعه دهندگان نرم افزار بصورت فعال حواسشان به ریسکهای قابل حل خواهد بود و به دقت آنهارا در مدل حلزونی تحلیل می کنند.

مرحله اول تدوین و فرموله کردن یک برنامه برای رسیدن به اهداف با این محدودیتها، و پس از آن تلاش برای پیدا کردن و حذف تمام خطرات بالقوه(ریسک های بالقوه)از طریق تجزیه و تحلیل دقیق و در صورت لزوم، با ساخت نمونه اولیه است.اگر برخی ریسکها قابل حل نبودند در این صورت مشتریان باید تصمیم بگیرند که آیا می خواهند انجام پروژه را خاتمه دهند یا از ریسک های مورد نظر چشم پوشی کنند و به هر ترتیب ادامه دهند. در نهایت، نتایج ارزیابی شده و طراحی مرحله بعدی آغاز می شود.

روش تکراری و افزایشی[ویرایش]

روشی تکراری تولید نرم افزار اجازه ی ایجاد که پروژه در ابتدا از بخشهای کوچک شروع شود و به مرور زمان سیستم رشد کند تا کمک کند در این درگیری مشکلات مهم پیدا شوند قبل از اینکه فرضیات اشتباه باعث خراب شدن سیستم شوند. مدل تکرار فرآیند ها بوسیله تولید کنندگان نرم افزارهای تجاری انتخاب و استفاده می شود چون این مدل اجازه می دهد تا نیازهای کاربرانی که در زمان طراحی دقیقا نمی دانند چگونه نیازمندیهایشان از سیستم را معرفی کنند بصورت بالقوه برآورده شود.

روش تولید و توسعه چابک[ویرایش]

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

مدلهای متنوعی از فرآیند چابک برای تولید نرم افزار استفاه می شود:

مدل ایکس پی (روش خیلی سریع)[ویرایش]

در مدل تولید نرم افزار برنامه نویسی خیلی سریع (ایکس پی) در فازهای خیلی کوچک (یا مداوم) انجام و با فرآیندهای دسته ای قدیمی تر تطبیق داده می شوند.فاز اول(که عمدا کامل نشده ) در طول مراحل ممکن است به جای اینکه ماهها و سالها در مدل آبشاری طول بکشد تا کامل شود، یک روز یا یک هفته وقت بگیرد.ابتدا یک تست خودکار برای ایجاد اهداف اساسی تولید نرم افزار نوشته می شود.سپس برنامه نویسی انجام می گیرد(توسط دوبرنامه نویس) که وقتی تمام تست ها را پشت سر گذاشته و دیگر هیچ تستی مورد نیازی به فکر برنامه نویسان نرسد کامل می شود.کار طراحی و معماری سیستم بعد از اینکه نه تستی وجود دارد و نه برنامه نویسی شده انجام می شود(خودشان را نشان میدهد). طراحی توسط برنامه نویسان انجام می شود.(فقط مشخصات نهایی و ترکیب طراحی و کد در تمام فرآیندها در روش چابک مشترک هستند)عملیات اصلی ناقص سیستم برای کاربران( برخی از کاربران) نصب یا نمایش داده می شوند (توسط حداقل یکی از افراد تیم تولید کنندگان و برنامه نویسان ).دراینجاتمام عوامل پروژه دوباره شروع به نوشتن تست برای قسمت های مهم سیستم خواهند کرد.

مدل اسکرام[ویرایش]

نوشتار اصلی: اسکرام

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

مدلهای بهبود سازی[ویرایش]

مدل سی ام ام آی (CMMI) مدل تکامل قابلیت یکپارچه سازی[ویرایش]

مدل تکامل قابلیت یکپارچه سازی یا مدل سی ام ام آی (CMMI) یکی از مدلهای پیشنهادی و تکنیک های پیشتاز است . ارزیابی سازمان های مستقل و رتبه بندی در مورد کیفیت چگونگی تعریف فرآیندهای آن سازمانها را دنبال می کند، نه بر کیفیت خود فرآیندها یا نرم افزار تهیه شده است. مدل CMMI جایگزین CMM شده است.

ایزو ۹۰۰۰[ویرایش]

ایزو ۹۰۰۰ یک استاندارد رسمی سازماندهی فرآینده ساخت محصولات و روشی برای مدیریت و نظارت پیشرفت کارهاست .در اصل این استاندارد برای بخش تولید وساخت(صنعتی) ایجاد شد.ایزو ۹۰۰۰ همچنین برای فرآیند تولید نرم افزار نیز به خوبی استفاده شده.مانند مدل CMMI مدرک ایزو ۹۰۰۰ هیچ تضمینی راجع به کیفیت نتایج نهایی ندارد و فقط فرآیندهای کاری را فرموله و قالب استاندارد رسمی می دهد.

ایزو ۱۵۵۰۴[ویرایش]

ایزو ۱۵۵۰۴، که با عنوان فرآیند تشخیص و تعیین بهبود قابلیت نرم افزار (S.P.I.C.E)نیز شناخته می شود، "چارچوبی برای ارزیابی فرآیندهای نرم افزار " است.این استاندارد تنظیمات قالب روشنی برای مقایسه فرآیند ها به شمار می رود . S.P.I.C.E خیلی شبیه CMMI استفاده می شود.فرآیند های این مدل برای مدیریت، کنترل، راهنمایی و نظارت تولید نرم افزار است . این مدل جهت سنجش سازماندهی تولید و توسعه یا تیم پروژه بصورت واقعی در طول مدت تولید نرم افزار استفاده می شود. تجزیه و تحلیل این اطلاعات برای شناسایی نقاط صعف و حرکت به سمت بهبودی پروژه استفاه می شود.همچنین برای تشخیص نقاط قوت پروژه که می تواند برای سازمان یا تیم پروژه ادامه پیدا کند یا برای امور مشترک یکپارچه شود.

در مقاله زیر به تعدادی از مهمترین قواعد کلی امنیت در زمینه تولید نرم افزار اشاره می گردد. به طور کلی در تولید یک نرم افزار باید علاوه بر مواردی همچون کاربرد ، کارایی ، قابلیت نگهداری و تجربه کاربری توجه ویژه ای را در حوزه امنیت لحاظ کرد. در نظر داشته باشید تاکید و برنامه ریزی شفاف در مورد امنیت نرم افزار می تواند هزینه ها و زمان پیاده سازی پروژه را بشدت تحت تاثیر قرار دهد .

اصل اول : Defense in Depth – هیچگاه به یک لایه امنیتی در نرم افزار خود اطمینان نکنید . در واقع برنامه شما باید آخرین لایه و واسط بین یک حمله کننده (هکر) و سیستم های پشتیبان مانند دیتابیس باشد. از این رو صرفا به یک لایه امنیتی در نرم افزار خود اکتفا نکنید و از انواع راه های ممکن برای تامین امنیت استفاده نمایید.

اصل دوم : Never Trust Input – هیچگاه به ورودی های ارائه شده توسط کاربر اطمینان نکنید . هر قسمت جداگانه از ورودی باید Validate (معتبر سازی) و تصحیح (Correct) شود و سپس مقادیر ورودی پردازش شوند . پردازش مقادیر ورودی بدون معتبر سازی آنها می توانند خطرات جبران ناپذیری بویژه در برنامه های تحت وب را در برداشته باشد.

اصل سوم : Fall Gracefully – ترکیبی از اصول توسعه نرم افزار ، تست رویداد های غیرمترقبه ، تست داده های غیر منتظره ، تصادفی و اشتباه در ترکیب با طراحی قدرتمند نرم افزار ، ساخت یک کد امن را تضمین می کند.

اصل چهارم : Watch for Attack – حتی اگر خطاها را در سیستم تان را به خوبی مدیریت کرده باشید ، بدون برخورداری از یک سیستم قدرتمند Logging نمی توانید از حملات صورت گرفته (موفق و ناموفق) بر ضد سیستمتان آگاه شوید. ارائه یک سیستم Logging می تواند شما را در تهیه نسخه بعدی نرم افزارتان و کشف خطاهای احتمالی یاری دهد.

اصل پنجم : Use Least Privilege – هیچگاه از اکانت Administrator در توسعه و برنامه نویسی سیستم هایتان استفاده نکنید. استفاده از اکانت Administrator در دسترسی به فایل ها و یا اتصال به بانک اطلاعاتی در برنامه ها می تواند بسیاری از مشکلات پیش روی یک برنامه نویس را حل و مرتفع نماید اما باید در نظر داشته باشید که با نفوذ به برنامه ، هکر توانایی دسترسی به تمامی قسمت ها و زیر ساخت های سیستم را خواهد داشت . از این رو چناچه در برخی از قسمت های برنامه نیاز به دسترسی خاصی به منابع سیستمی (فرضا پوشه ویندوز) بود می توانید از یک نام کاربری جداگانه و محدود صرفا برای دسترسی به این قسمت در برنامه خود استفاده نمایید

لحاظ امنیت در چرخه تولید نرم افزار

سازمان‌ها و شرکت‌های تولیدکننده نرم‌افزار به منظور کشف بیش‌ترین تعداد مشکلات امنیتی نرم‌افزار تولید شده در یک پروژه باید ابزار پویش امنیت را در چرخه حیات تولید نرم‌افزار جای دهند.

سال‌ها است که برنامه‌های نرم‌افزاری نوشته می‌شوند و سال‌ها است که امنیت، کم و بیش، در آن‌ها لحاظ می‌شود؛ شاید حتی بدون آن که بسیاری از مشتریان از کیفیت و قابلیت اعتماد آن آگاهی کافی داشته باشند. با فراگیر شدن وب و نرم‌افزارهای کاربردی وب‌محور، هم‌چنین هوش‌مندانه‌تر شدن تهاجم‌ها و تقلب‌ها، امنیت نرم‌افزارها بیش از پیش اهمیت یافته است. این امر بدین معنی نیست که در نرم‌افزارهای غیر وب (که به نرم‌افزارهای رومیزی یا ویندوزی معروفند) امنیت حایز اهمیت نیست. کم‌رنگ‌تر بودن احساس نیاز به امنیت در نرم‌افزارهای رومیزی بیش‌تر از این رو است که اصولا میزان دسترسی به آن‌ها محدودتر از برنامه‌های وب‌محور است. به هر حال، امنیت نیازی است که در هر نوع نرم‌افزاری باید لحاظ شود و به نظر می‌رسد که تا کنون رویکردهایی که تزریق امنیت در نرم‌افزار را به مرحله پس از تولید وامی‌گذارند، چندان در این امر کارآمد نبوده‌اند. از این رو، مکتب نوینی در این وادی به وجود آمده است که اعمال تمهیدات امنیتی در نرم‌افزار را در سراسر چرخه تولید نرم‌افزار مناسب و مطلوب می‌داند.

مطالعات بی‌شمار و توصیه‌های تحلیل‌گران بیان‌گر اهمیت ارتقای امنیت نرم‌افزار در چرخه حیات تولید نرم‌افزار (Software Development Life Cycle - SDLC)، به جای کشف و رفع آن پس از تولید و توزیع گسترده است. شرکت‌های تولیدکننده نرم‌افزار برای کشف نقایص امنیتی در نرم‌افزار خود، به صورت مستقیم و غیرمستقیم هزینه می‌کنند. تخصیص منابع لازم برای رفع نقص و تهیه وصله‌های امنیتی و انتشار آن می‌تواند میلیون‌ها دلار هزینه در بر داشته باشد. به علاوه سوءاستفاده از یک نقص امنیتی در نرم‌افزاری که در سطح جهان گسترده شده می‌تواند به مجموعه شرکت‌هایی که از آن استفاده می‌کنند، میلیاردها دلار خسارت وارد کند. از سوی دیگر، تولیدکنندگان نرم‌افزار به دلیل وجود چنین نقیصه‌هایی در نرم‌افزارشان، به خاطر از دست دادن اعتبار، مخدوش شدن نام تجاری خود یا نبود چنین نقایصی در محصولات رقیبان نیز متضرر می‌شوند. تحقیقی که در سال 2005 توسط موسسه کارنگی - ملون (Carnegie-Melon) انجام شد، نشان داد که چنین شرکت‌هایی با کاهشی معادل 0/63% در ارزش سهام خود در NASDAQ مواجه بوده‌اند.

گرچه تحقیقی با این جزییات در مورد نرم‌افزارهای ابرسازمانی (enterprise) که توسط خود سازمان‌ها تولید یا برون‌سپاری (outsource) شده‌اند در دست نیست، ولی توافق همگانی بر این است که هر چه نقیصه‌های نرم‌افزار در مراحل آغازین تولید کشف و رفع شود، هزینه نهایی تولید کم‌تر خواهد بود. طبق تحقیق منتشر شده از سوی ب. بوهم و وی. باسیلی (B. Boehm and V. Basili) در IEEE Computer طول مدت رفع یک خطای نرم‌افزاری پس از نصب صد برابر زمانی است که خطا در مراحل اولیه تولید نرم‌افزار کشف و اصلاح شود. در مورد نقایص امنیتی این رقم بالاتر نیز خواهد بود، چرا که علاوه بر هزینه فوق، هزینه جبران خسارت ناشی از سوءاستفاده از این نقایص به منظور دزدی اطلاعات، خراب‌کاری و سایر حملات نیز بر دوش تولیدکننده سنگینی خواهد کرد.

امروزه ابزار تحلیل خودکار کد برنامه به گستردگی به عنوان ابزاری برای کشف ایرادهای امنیتی نرم‌افزار در مراحل اولیه تولید شناخته می‌شوند، چرا که امکان ارزیابی امنیتی یک قطعه‌برنامه را پیش از تکمیل به صورت یک برنامه کاربردی کامل فراهم می‌نمایند. بهترین ابزار در این رده، آن‌هایی هستند که هر آسیب‌پذیری کشف شده را با ارجاع به خط معینی از برنامه، میزان حساسیت و نحوه اصلاح آن مشخص می‌کنند. آزمون نفوذ (penetration test) نیز از جمله تست‌های مهم امنیتی است که اجرای آن در مراحل نهایی و بر روی نسخه تکمیل شده نرم‌افزار کاربردی قابل اجراست.

موانع لحاظ امنیت در چرخه تولید

از جمله مهم‌ترین موانع بر سر راه لحاظ نمودن امنیت در چرخه تولید نرم‌افزار، می‌توان به فاصله بین تولید نرم‌افزار و امنیت آن اشاره نمود. مجموعه مهارت‌های مورد نیاز به ندرت در یک فرد و حتی یک گروه جمع می‌شود و از نظر سازمانی نیز هم‌کوشی ذاتی اندکی در این زمینه وجود دارد. هدف اصلی، تولید کارکرد صحیح محصول و تحویل به موقع آن می‌باشد، در حالی که وظیفه تیم امنیت حذف آسیب‌پذیری‌ها و پیاده‌سازی کنترل‌های امنیتی در نرم‌افزار پس از تکمیل برنامه کاربردی است. به منظور کاهش موثر نقایص امنیتی در طول فرآیند تولید، نه تنها هم‌کاری بین این دو گروه، بلکه حمایت و تاکید مدیریت بر ارتقای امنیت نرم‌افزار حین تولید آن نیز ضروری می‌باشد.

علاوه بر موانع سازمانی، تردید در تغییر فرآیند تولید موجود نیز می‌تواند در پیاده‌سازی آزمون امنیت تاخیر ایجاد کند. با این حال، درک درستی از مزایایی که این امر برای کسب‌وکار دارد، می‌تواند مشوق مناسبی برای ترغیب افراد به انجام این کار باشد. در کنار این موانع مفهومی، درک نادرست از یک‌پارچه کردن تحلیل امنیتی در چرخه تولید نیز مساله‌ای است که باید بر آن فایق آمد.

تصور

برنامة زمانی تولید نرم‌افزار، حتی برای لحاظ كردن تمهيدات امنیتي نيز نمی‌تواند بیش‌تر از آن‌چه هست طولانی شود.

واقعیت

گرچه در مراحل اولیه ممکن است تاخیرهایی رخ دهد، به ‌خصوص از این جهت که افراد باید نظام جدید را فرا بگیرند. با این حال، این کارآمدترین روش برای کاهش مخاطره نرم‌افزار است و در نهایت، چنین فرآیندی، به دلیل اشاعه شیوه‌های مناسب تولید برنامه‌های ایمن در میان برنامه‌نویسان، زمان کل تولید را کاهش می‌دهد. تنها گزینه‌ای که سریع‌تر عمل می‌کند، این است که برای دست‌یابی به یک نرم‌افزار ایمن‌تر مطلقا کاری انجام ندهیم؛ گزینه‌ای که مطمئنا هیچ سازمانی در درازمدت استطاعت آن را نخواهد داشت.

تصور

با وجود انجام «مرور همتا»[1]دیگری نیازی به «مرور امنیتی» نیست.

واقعیت

مرور همتا نمی‌تواند جایگزینی برای مرور امنیتی باشد. مرور همتا عموما برای کشف خطاهای کارکردی انجام می‌گیرد. بنابراین، حتی با وجود مرور همتا بسیاری از آسیب‌پذیری‌های حساس امنیتی و خطاهای طراحی نادیده گرفته خواهد شد، مگر این که مرور همتا دقیقا برای کشف خطاهای امنیتی کد انجام شود و فردی که این امر را به عهده دارد از درکی عمیق نسبت به امنیت نرم‌افزار کاربردی برخوردار باشد. در بسیاری از مواقع، نیازمندی‌هایی که به بهترین وجه و بدون خطای کارکردی پیاده می‌شوند، می‌توانند منجر به بدترین خطرات امنیتی شوند.

مسئولیت‌های اصلی

حتی با گذشتن از موانع اولیه نیز بسیاری از سازمان‌ها در شناسایی و انتخاب روش و منابع مناسب جهت انجام تحلیل کد برنامه در چرخه تولید با مشکل مواجه می‌شوند. سه مدلی که در این مقاله تشریح می‌شوند، سناریوهایی را ارایه می‌کنند که عموما برای موفقیت در کاهش آسیب‌پذیری‌ها در چرخه تولید نرم‌افزار مورد استفاده قرار می‌گیرند. این مدل‌ها در تعیین معیارهایی برای ارزیابی هدف، منابع، موانع و در نهایت انتخاب بهترین رویکرد به سازمان یاری می‌رسانند.

هدف اصلی مقاله حاضر تشریح فرآیندی جدید برای مدل‌سازی تهدید نیست، بلکه بیش‌تر به مدون نمودن مدل‌های جریان کاری می‌پردازد که استفاده از ابزار پویش خودکار کد برنامه در فرآیند تولید نرم‌افزار را تسهیل می‌کنند. گرچه سازمان‌ها و فرآیندهای تولید نرم‌افزار هر یک مشخصات خاص خود را دارند، ولی مدل ارایه شده در این مقاله به مولفه‌های مشترکی می‌پردازد که باید بهبود یابند تا بتوان به آزمون موثری برای امنیت دست یافت.

در فهرست زیر اصلی‌ترین رويه‌هايي که باید توسط کارکنان و خبرگان پیاده‌سازیِ امنیت لحاظ گردد، ارایه شده است:

تعیین نیازمندی‌های امنیتی: مدیر یا فردی خبره در امر امنیت می‌بایست مصادیق آسیب‌پذیری و نحوه قضاوت در مورد حساسیت آن‌ها را بر اساس نیازهای کسب‌وکار معین نماید.

· پیکربندی تحلیل: تعاریف داخلی‌ای را که برای بومي‌سازی (customization) ابزار تحلیل کد برنامه بر اساس سیاست‌های کسب‌وکار مورد نیاز است، تعیین نمایید.

· پویش کد برنامه: از ابزار تحلیل کد برنامه برای وارسی برنامه کاربردی مورد نظر و تشخیص نقاط آسیب‌پذیر استفاده کنید.

· بررسی نتایج: افراد خبره در حوزه امنیت باید نتایج را، به منظور اولویت‌بندی اقدامات مورد نیاز برای رفع نقیصه امنیتی، بررسی نمایند.

· اصلاح نقیصه: با بازنویسی کد، حذف مولفه‌های مشکل‌ساز و افزودن مولفه‌های امنیتی، آسیب‌پذیری‌ها را برطرف کنید.

· وارسی اصلاحات: کد را مجددا پویش و اطمینان حاصل کنید که نقیصه‌هاي امنيتي با حفظ کارکرد برنامه حذف شده‌اند.

در تحلیل کد و کشف آسیب‌پذیری‌های امنیتی سه مدل عمومیت دارد که عبارت است از «مستقل»، «توزیع شده» و «متمرکز». در بخش‌های بعدی به تشریح این سه مدل می‌پردازیم.

1- مدل مستقل

از زمانی که تحلیل کد مطرح شده است، «مدل مستقل»، بیش‌تر از دیگر مدل‌ها مورد توجه قرار گرفته است. در این مدل تمام برنامه‌نویسان مسئول تحلیل برنامه برای کشف، تعیین حساسیت، انجام اصلاحات لازم و اطمینان از رفع آسیب‌پذیری‌ها می‌باشند. بسته به سازمان و نیازمندی‌های برنامه کاربردی، اقدامات امنیتی عموما در فواصل زمانی معینی، توسط شخص برنامه‌نویس و پیش از الحاق فایل‌های تغییریافته به کد اصلی برنامه، انجام می‌شوند. در حالت ایده‌آل، تحلیل کد باید بر روی کل برنامه اعمال شود، به طوری که اطمینان حاصل گردد که پویش نقیصه‌های مولفه‌ای خاص در بافت کل سیستم انجام می‌شود. البته اگر حجم کد برنامه زیاد باشد، این امر می‌تواند بسیار زمان‌گیر باشد.

نحوه کارکرد

این مدل الزاما باید به عنوان بخشی از چرخه تولید نرم‌افزار مورد استفاده قرار گیرد. در این مدل، برنامه‌نویسان باید دانشی کافی از امنیت داشته باشند، به طوری که نه تنها نقیصه‌های امنیتی را بیابند، بلکه بتوانند آن‌ها را اولویت‌بندی نموده، مناسب‌ترین راه رفع آن‌ها را تشخیص داده، نسبت به رفع و تست نهایی آن‌ها نیز اقدام کنند. در این گام، مدیریت باید رهنمودهای کلی لازم در این زمینه را برای ایجاد امکان تصمیم‌گیری توسط برنامه‌نویسان فراهم نماید به عنوان مثال، نحوه تعیین حساسیت یک آسیب‌پذیری در رابط کاربری یک وب‌سایت در مقایسه با نقایصی که در پایگاه داده پیدا می‌شوند، بايد اولويت‌بندي گردد. در صورتی که سیاست‌های امنیتی از سوی مرکزی واحد صادر نشوند، تصمیم در مورد مصداق، حساسیت و نحوه رفع هر آسیب‌پذیری به شخص برنامه‌نویس واگذاشته می‌شود، كه طبعا خطرات خاص خود را خواهد داشت.

جریان کار

مدیر:

· تعریف نیازمندی‌های امنیتی

برنامه‌نویس:

· وارسی کد

· افزودن یا تغییر کارکرد

· تنظیم پویشگر

· وارسی نتایج

· انجام اقدامات اصلاحی

· انجام مجدد پویش

· افزودن کد به برنامه اصلی

مدیر:

· مرور پیشرفت کار

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

موارد مناسب برای استفاده

سازمان‌هایی با تیم‌ها و پروژه‌های کوچک بیش‌ترین بهره را از مدل مستقل می‌برند. در این موارد به سادگی می‌توان آموزش‌ها و راهنمایی‌های لازم برای نتیجه‌بخشی تلاش‌های برنامه‌نویسان در جهت تامین امنیت برنامه را فراهم نمود. گرچه ردگیری میزان پیشرفت کار در این مدل دشوار است، ولی از برنامه‌نویسان انتظار می‌رود که از تلاش‌های خود درس بگیرند و آن را در برنامه‌های آتی به کار ببرند. با توجه به سرمایه‌گذاری اندک مورد نیاز در این مدل، به نظر بهترین روش برای سازمان‌های کوچک مي‌باشد. مدل مستقل، برای شرکت‌هایی که به امر یک‌پارچه ساختن سیستم‌های نوشته شده می‌پردازند و در این کار به تیم کوچکی از برنامه‌نویسان نیاز دارند نیز می‌تواند کارساز باشد.

برای سازمان‌هایی که مهارت کافی در زمینه امنیت ندارند، می‌توان گونه دیگری از این مدل را استفاده کرد، به طوری که یک نفر یا گروه کوچکی را مسئول یادگیری و آموزش امنیت به دیگران نمود. در این رویکرد، افراد مسئول برای دیگر برنامه‌نویسان نقش مربی را ایفا و به آنان در کشف و رفع نقایص امنیتی کمک می‌کنند.

موارد نامناسب برای استفاده

مدل مستقل قابلیت مقیاس‌پذیری (scalability) فراتر از گروه‌ها یا برنامه‌های کاربردی کوچکي را که در آن هر برنامه‌نویسی مسئول امنیت کد خود می‌باشد پوشش نمي‌دهد. بسیاری از سازمان‌های بزرگ نمی‌توانند به تک‌تک برنامه‌نویسان خود، در یادگیری، درک و رعایت نکات ایمنی، هم‌چنین در اخذ تصمیم‌های امنیتی مهم، اعتماد کنند. حتی اگر بتوانند به این درجه از اعتماد نیز برسند، نبود کنترل و فرآیندهای متمرکز و پویش کل کد برنامه، به انجام دوباره‌کاری برنامه‌نویسان بر روی یک آسیب‌پذیری واحد منجر می‌شود. این مدل هم‌چنین در ایجاد و اعمال سیاست‌های امنیتی بین گروه‌های کاری بزرگ با مشکل روبه‌رو است. بدون استانداردهای قابل اندازه‌گیری که در سراسر سازمان تعریف شده باشد (مانند میزان استفاده از رمزنگاری یا چگونگی اعتبارسنجی ورودی) بهترین رویه‌های استاندارد به روش‌هایی تبدیل می‌شوند که هر برنامه‌نویس یا مرورکننده کد برنامه بنا به سلیقه خود عمل می‌کند. این امر به ناسازگاری و در بیش‌تر مواقع به امنیت ضعیف منجر می‌گردد.

شیوه‌های برتر

· به منظور اطمینان از حذف آسیب‌پذیری‌های کشف شده، بدون لطمه زدن به کارکرد سیستم، «مرور امنیتی کد» را بین تمام برنامه‌نویسان اشاعه دهید.

· یک برنامه‌نویس آشنا به امنیت را شناسایی کرده یا آموزش دهید، تا به منظور کمک به دیگر برنامه‌نویسان گروه، در تحلیل، بررسی اولیه و انجام مرور امنیتی نقش مربی را ایفا نماید.

مجموعه‌ای از نیازمندی‌های قابل اندازه‌گیری و قابل اعمال را به برای جهت دادن به عملیات امنیتی تعریف کنید.

- مدل توزیع‌شده

مانند مدل مستقل در مدل توزیع‌شده نیز مسئولیت اصلی لحاظ امنیت درون کد به عهده برنامه‌نویسان است؛ با این تفاوت که پویش آسیب‌پذیری‌ها در محلی متمرکز و بر روی کل برنامه کاربردی انجام می‌گیرد. عموما این کار توسط گروه تضمین کیفیت انجام می‌شود، که به نوبه خود امکان ادغام این مدل در ساختار تولید نرم‌افزار موجود را فراهم می‌سازد. زمان‌بندی و تناوب ارزیابی را می‌توان به منظور تطابق با نیازمندی‌های تست کنترل کرد، به طوری که فرآیندهایی را که در گستره‌ای از روش‌های چابک (agile) تا مدل آبشاری قرار می‌گیرند شامل شود.

نحوه کارکرد

تحلیل امنیت را می‌توان به عنوان یک نیازمندی تضمین کیفیت و در آغاز مرحله مربوطه یا پس از آن و به عنوان بخشی از تست پذیرش انجام داد. تیم تضمین کیفیت تحلیل کد را بر اساس نیازمندی‌های متمرکز انجام می‌دهد، تمام کد برنامه را پویش می‌کند و نتیجه را به گروه برنامه‌نویسی برمی‌گرداند. هر برنامه‌نویسی مسئول بازنگری کد، کشف آسیب‌پذیری‌های حساس و رفع آن‌ها است. در این مدل، تیم برنامه‌نویسی باید از دانش کافی نسبت به امنیت برخوردار باشد و تیم تضمین کیفیت صرفا پویش کد برنامه، عودت نتایج به گروه تولید و وظایف مربوط به پیکربندی تحلیل و زمان‌بندی انجام کار را به عهده می‌گیرد.

جریان کار

مدیر:

¤ تعریف نیازمندی‌های امنیتی

تیم تضمین کیفیت:

¤ پیکربندی پویش‌گر کد

¤ هماهنگ کردن کد در هر مرحله

¤ پویش کد در هر مرحله

¤ بازخورد نتایج به تیم تولید

برنامه‌نویس:

¤ وارسی نتایج

¤ انجام اقدامات اصلاحی

¤ افزودن کد به برنامه اصلی

مدیر:

¤ مرور پیش‌رفت کار و نتایج پویش

مدل توزیع شده

بسته به ابعاد برنامه کاربردی و تعداد نقص‌های امنیتی کشف شده در اولین پویش کد، احتمالا آزمون امنیت به چند بار تکرار نیاز خواهد داشت، تا از صحت رفع اشکالات با حفظ کارکرد برنامه اطمینان حاصل شود. تست مجدد برنامه حین ساخت آن از این جهت حایز اهمیت است که ممکن است در تولید بخش‌های جدید یا یک‌پارچه نمودن آن‌ها آسیب‌پذیری‌هایی به وجود آید که پیش‌تر نمود نیافته بودند. افزایش ارزیابی امنیتی برنامه در این مدل، به طور چشم‌گیری به ارتقای کیفیت برنامه و کشف نقص‌ها در مراحل اولیه ساخت کمک می‌کند. البته برای تحقق زمان‌بندی پروژه باید تعادل لازم را رعایت کرد. یکی از مزایای عمده مدل توزیع‌شده امکان رسیدن به چنین تعادلی است؛ چرا که انجام اصلاحات نسبت به مدل مستقل راحت‌تر انجام می‌پذیرد. هم‌چنین در این مدل از برخی امور تکراری، مانند پیکربندی نرم‌افزار پویش‌گر توسط هر برنامه‌نویس در مدل مستقل، اجتناب می‌شود.

موارد مناسب برای استفاده

تیم‌هایی با اندازه متوسطی که از یک فرآیند تولید نرم‌افزار مدون استفاده می‌کنند، بهترین کاندید برای به‌کارگیری این مدل هستند. به دلیل افزایش احتمال کشف و رفع خطا با افزایش تناوب تست، این مدل در فرآیندهای «چابک» تولید نرم‌افزار نیز به طور موثری کارسازند. گرچه یک فرآیند آبشاری امکانات کم‌تری در این زمینه فراهم می‌کند، با این وجود، این گونه فرآیندها نیز به دلیل افزایش ارزش ارزیابی متناسب با افزایش حوزه تحت بررسی، از مزایای این مدل بهره می‌برند.

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

موارد نامناسب برای استفاده

مدل توزیع‌شده برای برنامه‌های پیچیده و تیم‌های بزرگ و چرخه تولید نرم‌افزاری که بر اساس کارکرد یا مولفه‌های نرم‌افزاری (Component) استوار نشده باشد، مناسب نیست. اشکال اساسی این مدل در اولویت‌بندی مسئولیت برنامه‌نویسان است (همان طور که این امر در مورد مدل مستقل نیز صدق می‌کند) و به دلیل نبود دانش کافی در زمینه امنیت و اطلاع از معماری کامل نرم‌افزار بین برنامه‌نویسان باعث دوباره‌کاری می‌شود. اگر آسیب‌پذیری‌های عمده در مرحله اولویت‌بندی به‌درستی شناسایی نشوند یا چند برنامه‌نویس بر روی مولفه واحدی کار کنند، نمی‌توان میزان کاهش بهره‌وری را با تلاش برای بهبود امنیت کد جبران کرد.

شیوه‌های برتر

· پویش کد را در مراحل اولیه چرخه تولید نرم‌افزار آغاز کنید و تناوب و تداوم را در زمان‌بندی ارزیابی حفظ نمایید.

· ایمن کردن کد یک مولفه کاملا مشخص را به برنامه‌نویس معینی واگذار کنید، به طوری که دوباره‌کاری به حداقل ممکن برسد.

· عضوی از تیم تولید را به عنوان مربی انتخاب کنید که با مسایل امنیت نرم‌افزار آشنایی داشته باشد، به طوری که راهنمایی برنامه‌نویسان را در تحلیل و الویت‌بندی نقص‌ها به عهده بگیرد.

3- مدل متمرکز

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

نحوه کارکرد

جریان کار

مدیر:

¤ تعریف نیازمندی‌های امنیتی

تیم تحلیل امنیت:

¤ پیکربندی پویش‌گر کد

¤ دریافت کد از تیم تولید

¤ پویش کل برنامه

¤ وارسی و اولویت‌بندی نتایج

¤ واگذاری نقص امنیتی به افراد

برنامه‌نویس:

¤ انجام اقدامات اصلاحی

¤ افزودن کد به برنامه اصلی

مدیر:

¤ مرور پیش‌رفت کار و نتایج پویش

¤ مرور نتیجه وارسی و اقدامات اصلاحی

مدل متمرکز

بر خلاف دو مدل دیگر، که از برنامه‌نویسان انتظار می‌رود در امنیت مهارت داشته باشند، مدل متمرکز اجازه می‌دهد عملیات تامین امنیت در گروهی متخصص امنیت و آسیب‌پذیری‌های نرم‌افزار متمرکز شود. تیم تحلیل امنیت، تمام کد برنامه را با استفاده از دانش و فناوری تمرکزیافته در تیم پویش می‌کند؛ خواه این گروه درون چرخه تولید باشد یا بیرون آن. داده‌های خام ایجاد شده در این مرحله نیز توسط همین تیم وارسی می‌شوند، به طوری که اطلاعاتی که برای تیم تولید تهیه می‌شود از نظر اولویت‌بندی آسیب‌پذیری‌ها بر اساس حساسیت‌شان، کاملا پخته باشد. این تیم، به دلیل برخورداری از درک و آشنایی درست‌تری نسبت به مشکلات تجاری مدیریت مخاطره، گزینه بهتری برای پیکربندی تحلیل کد هستند.

در حالت ایده‌آل تخصیص فعالیت اصلاح آسیب‌پذیری‌ها باید از طریق یک سیستم ردگیری نقص‌ها (Defect Tracking System - DTS) انجام شود. چنین سیستمی برای تیم تحلیل کد امکان نظارت بر فعالیتِ رفع عیب توسط تیم تولید را فراهم می‌کند. در این بین، گروه تولید نیز می‌تواند بر ارتقای کد خود تمرکز کند، چه از نظر افزودن ویژگی‌های کارکردی جدید، چه با رفع نقایص امنیتی. در این مدل تیم نظارت بر امنیت نه تنها گروه تولید را در نحوه اصلاح معایب راهنمایی می‌کند، بلکه روش اصلاح را نیز با سیاست امنیتی سازمان هماهنگ می‌سازد. به عنوان مثال، فرض کنید که تیم تحلیل امنیت یک آسیب‌پذیری «تزریق SQL» در روال پردازش شماره کارت اعتباری از یک سیستم پرداخت الکترونیکی کشف می‌کند. روش اصلاح می‌تواند استفاده از یک رویه پایگاه داده (Stored procedure)، استفاده از SQL پارامتردار یا به‌کارگیری یک روال موجود در سازمان باشد. یک تیم تحلیل امنیت متمرکز می‌تواند روش مناسب را بر اساس سیاست سازمان معین و برای انجام به تیم تولید ارایه کند. در این صورت، از تصمیم‌گیری انفرادی و سلیقه‌ای افراد تیم تولید پیش‌گیری خواهد شد.

موارد مناسب برای استفاده

مزیت عمده مدل متمرکز در انعطاف‌پذیری آن در یک‌پارچه شدن می‌باشد؛ چه با چرخه حیات تولید نرم‌افزار و به عنوان ابزاری مکمل برای تیم داخلی نظارت بر امنیت و چه به صورت خارجی و به عنوان ابزاری در دست تیم امنیت یا تیم مرور کد. گرچه این مدل می‌تواند مستقل از یک فرآیند رسمی تولید نرم‌افزار عمل کند، ولی اثربخشی آن در نبود یک ساختار تعریف‌شده کاهش می‌یابد. متمرکز کردن پیکربندی، تحلیل و اولویت‌بندی مدیریت استفاده از این مدل را بسیار آسان می‌کند و این قابلیت را نیز دارد که بتواند با بزرگ شدن پروژه و تیم تولید به‌سهولت گسترش یابد.

با توجه به این که در این مدل از چندین سناریوی محتمل (مانند تولید، نظارت داخلی و مرور خارجی کد) می‌توان استفاده نمود، بنابراین مدل‌های تحویل کد متفاوتی نیز مورد نیاز می‌باشد. اتصال به نرم‌افزار کنترل کد، در صورتی که تیم تحلیل در چرخه تولید نرم‌افزار استقرار یافته باشد، عملکرد خوبی ارایه می‌دهد ولی برای مرور خارجی کد، به دست‌رسی از راه دور یا ارسال کد بر روی یک رسانه قابل حمل (مانند سی‌دی یا یواس‌بی) مورد نیاز خواهد بود.

موارد

فرآیند تولید نرم‌افزار

مطالب مشابه :

پروژه تجزیه و تحلیل سیستم زائر سرا

سناریو نویسی

فرآیند تولید نرم‌افزار

نکات مهم مهندسی نرم افزار استاد مژده داروگر

تجزیه وتحلیل آژانس هواپیمایی

4 سناریو برای شکار پهپاد آمریکایی + عکس

تفاوت سناریوی اقلیمی و سناریوی انتشار

منطق فازی

آموزش مبتنی بر سیستم