| توسعه نرم‌افزار |
| --- |
| فعالیت‌های اصلیدر مهندسی نرم‌افزار
* فرایند
* نیازمندی‌ها
* طراحی
* ساخت
* آزمون
* اشکال‌زدایی
* استقرار
* نگهداری
 |
| پارادایم‌ها و مدل‌ها
* چابک
* Cleanroom
* افزایشی
* پروتوتایپ
* مدل مارپیچی
* آبشاری
 |
| متدولوژی‌ها و چارچوب‌ها
* دواپس
* DSDM
* FDD
* IID
* Kanban
* Lean SD
* MDD
* MSF
* PSP
* توسعه سریع نرم‌افزارRAD
* SAFe
* Scrum
* SEMAT
* TSP
* RUP
* مدل وی
* XP
 |
| رشته‌های مورد حمایت
* رشته‌های مورد حمایت
مدیریت پیکربندی
* مستندسازی
* تضمین کیفیت (SQA)
* مدیریت پروژه
* تجربه کاربری
 |
| کاربردهای عملی
* توسعه آزمون محور
* BDD
* CCO
* CI
* CD
* DDD
* PP
* Stand-up
* TDD
 |
| ابزار
* کامپایلر
* اشکال‌زدا
* رخ‌نمانگار
* GUI designer
* مقایسه ابزارهای زبان مدل‌سازی یکپارچه
* محیط توسعه یکپارچه
* Build automation
* Release automation
* Infrastructure as Code
* آزمون
 |
| استانداردها و بدنه‌های دانش
* CMMI
* IEEE standards
* ایزو ۹۰۰۰
* ISO/IEC standards
* SWEBOK
* پم‌باک
* BABOK
 |
| واژه‌نامه‌ها
* Artificial intelligence
* Computer science
* Electrical and electronics engineering
 |
| رئوس مطالب
* Outline of software development
 |
| * ن
* ب
* و
 |

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

الگو آر یو پی
الگو وی

فعالیت‌های تولید نرم‌افزار
--------------------------

### برنامه‌ریزی (امکان‌سنجی)

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

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

### پیاده‌سازی، آزمون و مستندسازی

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

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

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

### استقرار و نگهداری سامانه

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

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

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

الگوهای تولید نرم‌افزار
-----------------------

### الگو آبشاری

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

1. مشخصات مورد نیاز (تحلیل نیازمندی‌ها)
2. طراحی نرم‌افزار
3. پیاده‌سازی و یکپارچه سازی
4. تست نرم‌افزار (یا اعتبارسنجی)
5. گسترش نرم‌افزار (یا نصب)
6. نگهداری نرم‌افزار

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

### الگو ی مارپیچ (Spiral Model)

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

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

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

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

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

1. الگو مارپیچ تحلیل ریسک‌ها را تأکید می‌کند و بنابراین کاربران باید این تحلیل را قبول کنند و فکری برایش کنند (این مطالب را در نظر داشته باشند). این مسئله نیازمند اعتماد متقابل و همچنین تمایل به هزینه کردن برای رفع ایرادات، در هنگام تولید نرم‌افزار است و این دلیل استفاده شدن این الگو تولید نرم‌افزار پروژه‌های بزرگ است.
2. درصورتی‌که در هنگام پیاده‌سازی تحلیل ریسک‌ها تأثیر منفی روی سود پروژه زیاد باشد نبایستی از الگو مارپیچ استفاده گردد.
3. تولید و توسعه دهندگان نرم‌افزار به صورت فعال حواسشان به ریسک‌های قابل حل خواهد بود و به دقت آن‌ها را در الگو مارپیچ تحلیل می‌کنند.

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

### روش تکرارشونده و افزایشی

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

### روش توسعه سریع نرم‌افزار

روش توسعه سریع نرم‌افزار (RAD)
روش توسعه سریع نرم‌افزار (به انگلیسی: Rapid application development)(مخفف انگلیسی: *RAD*) روش تکراری را به عنوان پایه کار استفاده می‌کند اما طرفداری نظریه سبک‌تر و محبوبیت بیشتر از روش سنتی است. روش سریع از بازخوردها به جای برنامه‌ریزی به عنوان سازوکار اصلی کنترل پروژه استفاده می‌کند. بازخوردها به وسیلهٔ آزمون‌های مرتب و انتشار پیاپی در بازه‌های زمانی کوتاه نرم‌افزارهای در حال تکامل تولید می‌شوند.

روش‌های گوناگونی از فرایند سریع برای تولید نرم‌افزار استفاده می‌شود:

#### روش برنامه‌سازی مفرط

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

#### الگو اسکرام

مقالهٔ اصلی: اسکرام (توسعه نرم‌افزار)
فرایند اسکرام
اسکرام یک روش چابکِ تکرارشونده و افزایشی برای مدیریت پروژه است که معمولاً در الگوی تولید نرم‌افزار چابک به عنوان نوعی متدولوژی توسعه نرم‌افزار دیده می‌شود.

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

الگوهای بهبودسازی
-----------------

### الگوی تکامل قابلیت یکپارچه‌سازی (CMMI)

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

### ایزو ۹۰۰۰

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

### ایزو ۱۵۵۰۴

ایزو ۱۵۵۰۴ که با عنوان فرایند تشخیص و تعیین بهبود قابلیت نرم‌افزار (به انگلیسی: Software Process Improvement and Capability Determination)(مخفف انگلیسی: *SPICE*) نیز شناخته می‌شود، چارچوبی برای ارزیابی فرایندهای نرم‌افزار است. این استاندارد تنظیمات قالب روشنی برای مقایسه فرایندها به‌شمار می‌رود. SPICE خیلی شبیه CMMI استفاده می‌شود. فرایندهای این الگو برای مدیریت، کنترل، راهنمایی و نظارت تولید نرم‌افزار است. این الگو جهت سنجش سازماندهی تولید و توسعه یا تیم پروژه به صورت واقعی در طول مدت تولید نرم‌افزار استفاده می‌شود. تجزیه و تحلیل این اطلاعات برای شناسایی نقاط ضعف و حرکت به سمت بهبود پروژه استفاده می‌شود. همچنین برای تشخیص نقاط قوت پروژه که می‌تواند برای سازمان یا تیم پروژه ادامه پیدا کند یا برای امور مشترک یکپارچه شود.

جستارهای وابسته
---------------


|  |
| --- |
| 
روش‌های توسعه
* برنامه‌سازی مفرط
* آیکونیکس
* مدل وی
* اعتبار و درستی‌سنجی

مباحث مرتبط
* فهرست فلسفه‌های توسعه نرم‌افزار
* فرایند (رایانه)
* پارادایم برنامه‌نویسی
* پروژه

 |

پانویس
------

|  |  |
| --- | --- |
|  | در ویکی‌انبار پرونده‌هایی دربارهٔ فرایند توسعه نرم‌افزار موجود است. |



| * ن
* ب
* و
مهندسی نرم‌افزار |
| --- |
| حوزه‌ها | تحلیل نیازمندی‌ها •  تحلیل سامانه‌ها •  طراحی نرم‌افزار •  برنامه‌نویسی •  روش‌های صوری •  وارسی مدل •  تست نرم‌افزار •  توسعه نرم‌افزار •  گسترش نرم‌افزار •  نگهداری نرم‌افزار |
| مفاهیم | مدل‌سازی داده •  معماری سازمانی •  مشخصات کاربردی •  زبان مدل‌سازی •  پارادایم برنامه‌نویسی •  نرم‌افزار •  معماری نرم‌افزار •  فرایند توسعه نرم‌افزار •  فرایند تولید نرم‌افزار •  کیفیت نرم‌افزار •  تضمین کیفیت نرم‌افزار •  Software archaeology •  تحلیل ساختمند |
| گرایشات | مدل چابک •  مدل طراحی جنبه‌گرا •  شیءگرایی •  آنتولوژی •  سرویس‌گرایی •  چرخه حیات توسعه سیستم‌ها |
| مدل‌ها | 

|  |  |
| --- | --- |
| مدل‌های توسعه | مدل چابک •  آریوپی  •  اسکرام •  مدل مارپیچی •  مدل آبشاری •  برنامه‌سازی مفرط •  مدل وی •  مدل تکراری و افزایشی •  پیش‌نمونه |
| مدل‌های دیگر | Automotive SPICE •  مدل بلوغ قابلیت یکپارچه •  مدل داده •  مدل تابع •  مدل اطلاعات •  فرامدل •  مدل شیءگرایی •  مدل‌سازی سیستم‌ها •  مدل نما |
| زبان‌های مدل سازی | IDEF •  زبان مدل‌سازی یکپارچه |

 |
| مهندساننرم‌افزار سرشناس | 
* ویکتور باسیلی
* کنت بک
* گریدی بوچ
* فردریک بروکز
* Barry Boehm
* وارد کانینگهام
* تام دی ماکرو
* ادسخر دیکسترا
* مارتین فولر
* تونی هور
* واتس هامفری
* مایکل ای. جکسون
* ایوار جاکوبسون
* Stephen J. Mellor
* برترند میر
* دیوید پارناس
* وینستون واکر رویس
* جیمز رامبا
* نیکلاوس ویرت
* Edward Yourdon
* Mohamed Fayad

 |
| حوزه‌های مرتبط | 
* علوم رایانه
* مهندسی کامپیوتر
* مدیریت پروژه
* مدیریت ریسک
* مهندسی سامانه‌ها

 |
|  •  رده  •  انبار |

| * ن
* ب
* و
علوم رایانه |
| --- |
| Note: This template roughly follows the 2012 ACM Computing Classification System. |
| سخت‌افزار | 
* برد مدار چاپی
* دستگاه جانبی
* مدار مجتمع
* یکپارچه‌سازی کلان‌مقیاس
* سامانه روی یک تراشه
* رایانش سبز
* خودکارسازی طراحی الکترونیکی
* شتاب‌دهنده سخت‌افزاری

 |
| سازمانسامانه‌های رایانه | 
* معماری رایانه
* سامانه نهفته
* رایانش بی‌درنگ
* اطمینان‌پذیری

 |
| شبکه رایانه‌ای | 
* معماری شبکه
* پروتکل ارتباطات
* سخت‌افزار شبکه
* برنامه‌ریز شبکه
* کارایی شبکه رایانه‌ای
* سرویس شبکه‌ای

 |
| سازمان نرم‌افزار | 
* مفسر
* میان‌افزار
* ماشین مجازی
* سیستم‌عامل
* کیفیت نرم‌افزار

 |
| نظریه زبان‌های برنامه‌نویسیو ابزار توسعه نرم‌افزار | 
* الگو برنامه‌نویسی
* زبان برنامه‌نویسی
* کامپایلر
* زبان خاص دامنه
* زبان مدل‌سازی
* چارچوب نرم‌افزاری
* محیط یکپارچه توسعه نرم‌افزار
* مدیریت پیکربندی نرم‌افزار
* کتابخانه (رایانه)
* مخزن نرم‌افزاری

 |
| توسعه نرم‌افزار | 
* فرایند توسعه نرم‌افزار
* تحلیل نیازمندی‌ها
* طراحی نرم‌افزار
* ساخت نرم‌افزار
* استقرار نرم‌افزار
* تعمیر و نگهداری نرم‌افزار
* تیم برنامه‌نویسی
* نرم‌افزار متن‌باز
* برنامه‌نویسی
* آزمون نرم‌افزار

 |
| نظریه محاسبات | 
* مدل محاسبه
* زبان صوری
* نظریه اتوماتا
* نظریه رایانش‌پذیری
* نظریه پیچیدگی محاسباتی
* منطق در علوم کامپیوتر
* معنی‌شناسی (علوم رایانه)

 |
| الگوریتمها | 
* الگوریتم
* تحلیل الگوریتم‌ها
* کارایی الگوریتمی
* الگوریتم‌های تصادفی
* هندسه محاسباتی

 |
| ریاضیاترایانه | 
* ریاضیات گسسته
* احتمالات
* آمار
* نرم‌افزار ریاضی
* نظریه اطلاعات
* آنالیز ریاضی
* آنالیز عددی

 |
| سامانه اطلاعاتی | 
* پایگاه داده
* ذخیره‌سازی داده رایانه
* سامانه اطلاعات سازمانی
* نرم‌افزار اجتماعی
* سامانه اطلاعات جغرافیایی
* سامانه پشتیبانی تصمیم
* کنترل فرایند
* پایگاه داده چند رسانه‌ای
* داده‌کاوی
* کتابخانه دیجیتال
* سکوی رایانش
* بازاریابی اینترنتی
* وب جهان‌گستر
* بازیابی اطلاعات
* مستندسازی فنی

 |
| امنیت رایانه | 
* رمزنگاری
* روش‌های صوری
* خدمات امنیتی
* سامانه تشخیص نفوذ
* خرابی سخت‌افزار
* امنیت شبکه
* امنیت اطلاعات
* امنیت برنامه

 |
| تعامل انسان و رایانه | 
* طراحی تعاملی
* رایانش اجتماعی
* رایانش فراگیر
* مصورسازی
* دسترس‌پذیری رایانه
* واسط‌های کاربر
* رایانش پوشیدنی

 |
| همروندی | 
* رایانش همزمان
* رایانش موازی
* رایانش توزیع‌شده
* چندریسمانی
* چندپردازشی

 |
| هوش مصنوعی | 
* پردازش زبان‌های طبیعی
* بازنمود دانش
* بینایی رایانه‌ای
* برنامه‌ریزی خودکار
* بهینه‌سازی
* نظریه کنترل
* فلسفه هوش مصنوعی
* هوش مصنوعی توزیع شده
* استدلال خودکار
* زبان‌شناسی رایانشی
* یادگیری ماشینی

 |
| یادگیری ماشین | 
* یادگیری با نظارت
* یادگیری بی‌نظارت
* یادگیری تقویتی
* یادگیری چند-وظیفه‌ای
* روش اعتبارسنجی متقابل

 |
| گرافیک رایانه‌ای | 
* پویانمایی رایانه‌ای
* رندرینگ (گرافیک رایانه‌ای)
* روتوش
* واحد پردازش گرافیکی
* واقعیت ترکیبی
* واقعیت مجازی
* فشرده‌سازی تصویر
* مدلسازی جامد

 |
| رایانشکاربردی | 
* تجارت الکترونیک
* نرم‌افزار سازمانی
* ریاضیات محاسباتی
* فیزیک محاسباتی
* شیمی محاسباتی
* زیست‌شناسی محاسباتی
* علوم اجتماعی محاسباتی
* مهندسی و علم محاسبه
* انفورماتیک پزشکی
* هنر دیجیتال
* نشر الکترونیک
* جنگ مجازی
* رأی‌گیری الکترونیکی
* بازی ویدئویی
* واژه‌پرداز
* تحقیق در عملیات
* فناوری آموزشی
* سامانه مدیریت اسناد

 |
| توجه: بنا بر سامانه رده‌بندی رایانش ای‌سی‌ام علم رایانه همچنین می‌تواند به موضوع‌ها یا زمینه‌های گوناگون تقسیم شود.
* **کتاب:علوم رایانه**
* **رده:علوم رایانه**
* **طرح کلی علوم رایانه**
* **ویکی‌پدیا:ویکی‌پروژه علوم رایانه**
* **ویکی‌انبار**
 |

| * ن
* ب
* و
ادسخر دیکسترا |
| --- |
| ادسخر دیکسترا | 
* *A Primer of ALGOL 60 Programming* (book)
* *Structured Programming* (book)
* *A Discipline of Programming* (book)
* *A Method of Programming* (book)
* *Predicate Calculus and Program Semantics* (book)
* *Selected Writings on Computing: A Personal Perspective* (book)
* ادسخر دیکسترا
* ادسخر دیکسترا
* *A Note on Two Problems in Connexion with Graphs*
* *Cooperating Sequential Processes*
* *Solution of a Problem in Concurrent Programming Control*
* *The Structure of the 'THE'-Multiprogramming System*
* *Goto*
* *Notes on Structured Programming*
* *The Humble Programmer*
* *Programming Considered as a Human Activity*
* *How Do We Tell Truths That Might Hurt?*
* *On the Role of Scientific Thought*
* *Self-stabilizing Systems in Spite of Distributed Control*
* *On the Cruelty of Really Teaching Computer Science*

 |
| علوم رایانه | 
* علوم نظری رایانه
* مهندسی نرم‌افزار
* علوم سامانه‌ها
* الگوریتم
* رایانش همزمان
* رایانش توزیع‌شده
* روش‌های صوری
* فرایند توسعه نرم‌افزار
* نظریه زبان‌های برنامه‌نویسی
* طراحی نرم‌افزار and توسعه نرم‌افزار
* معماری نرم‌افزار
* فلسفه علوم رایانه

 |
| ادسخر دیکسترا | 

|  |  |
| --- | --- |
| ادسخر دیکسترا | 
* الگول ۶۰ implementation
* پشته فراخوانی
* هم‌روندی
* رایانش همزمان
* Cooperating sequential processes
* بخش بحرانی
* بن‌بست (علوم رایانه) (بن‌بست (علوم رایانه))
* مسئله غذا خوردن فیلسوف‌ها
* Dutch national flag problem
* تاب‌آوری خطا
* برنامه‌نویسی ساخت‌یافته
* Guarded Command Language
* لایه انتزاع in معماری نرم‌افزار
* لایه انتزاع
* ریسه (رایانه)
* انحصار متقابل (قفل (رایانه))
* مسئله تولیدکننده-مصرف‌کننده (مسئله تولیدکننده-مصرف‌کننده)
* خط تولید نرم افزار
* Predicate transformer semantics
* همگام‌سازی (علوم رایانه)
* Self-stabilizing distributed system
* نشان‌بر
* تفکیک دغدغه‌ها
* مسئله آرایشگر خواب‌آلود
* Software crisis
* تحلیل ساختمند
* برنامه‌نویسی ساخت‌یافته
* THE multiprogramming system
* Unbounded nondeterminism
* Weakest precondition calculus

 |
| ادسخر دیکسترا | 
* الگوریتم بانکدار
* الگوریتم دکسترا
* الگوریتم پریم (الگوریتم پریم)
* الگوریتم دایکسترا – شولتن
* الگوریتم دکر (generalization)
* مرتب‌سازی روان
* الگوریتم محوطه تعویض خط
* Tri-color marking algorithm
* رایانش همزمان
* Distributed algorithms
* الگوریتم‌های جلوگیری از بن‌بست
* انحصار متقابل
* Self-stabilizing algorithms

 |

 |
| Related people | 
* Shlomi Dolev
* پر برینچ هنسن
* تونی هور
* اوله-یوهان دال
* لزلی لمپورت
* دیوید پارناس
* Adriaan van Wijngaarden
* نیکلاوس ویرت

 |
| Other topics | 
* Dijkstra Prize (Edsger W. Dijkstra Prize in Distributed Computing)
* Centrum Wiskunde & Informatica
* E.W. Dijkstra Archive (دانشگاه تگزاس در آستین)
* List of pioneers in computer science
* List of important publications in computer science
* List of important publications in theoretical computer science
* List of important publications in concurrent, parallel, and distributed computing
* International Symposium on Stabilization, Safety, and Security of Distributed Systems

 |
| 
* **Wikiquote**

 |