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

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

نرم افزار را میتوان برای اهداف متنوعی توسعه داد، که سه مورد از متداول ترین ها عبارت اند از براوردن نیازهایی خاص برای یک مشتری/تجارت خاص (نرم افزار مخصوص)، براوردن یک نیاز درک شده برای مجموعه ای از کاربران بالقوه (نرم افزار منبع باز و تجاری)، یا برای مصرف شخصی (مثلاً یک دانشمند ممکن است نرم افزاری برای خودکارسازی یک کار معمولی بنویسد). توسعه نرم افزار جاسازی شده، یعنی توسعه دادن نرم افزار جاسازشده، که مثلاً برای کنترل محصولات مصرفی استفاده می شود، نیازمند یکپارچه سازی فرایند توسعه نرم افزار با توسعه محصول فیزیکیِ کنترل شده باشد. نرم افزار سیستم، بر اپلیکیشن ها و خودِ فرایند برنامه نویسی تاکید میکند و اغلب جداگانه توسعه میابد.

نیاز به کنترل کیفیتِ بهتر برای پروسه توسعه نرم افزار منجر به ظهور رشته مهندسی نرم افزار شده است، که هدف آن کاربرد روش سیستماتیکِ الگوی مهندسی در پروسه توسعه نرم افزار است.

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

اصول شناسی ها

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

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

• تحلیل پروژه
• تحقیق در مورد بازار
• جمع آوری ملزومات برای راه حل تجاری پیشنهادی
• درست کردن یک نقشه یا طرح برای راه حل نرم افزار-بنیان
• پیاده سازی (کدنویسی) نرم افزار
• آزمایش نرم افزار
• گسترش
• نگهداری و رفع باگ

این مراحل بطور دسته جمعی اغلب چرخه حیات توسعه نرم افزار یا SDLC نامیده میشوند. روش های مختلف توسعه نرم افزار ممکن است این مراحل را به ترتیب های مختلفی انجام دهند، یا زمان بیشتر یا کمتری را برای مراحل مختلف صرف کنند. سطح جزییات مستندسازیِ تولید شده نیز در هر مرحله از توسعه نرم افزار ممکن است متغیر باشد. همچنین ممکن است این مراحل به ترتیب اجرا شوند (یک روش “آبشار”-بنیان)، یا ممکن است در تکرارها یا چرخه های مختلف تجدید شوند (یک روش “شدید” تر).  روش شدیدتر معمولاً زمان کمتری را صرف طرح ریزی و مستندسازی، و زمان بیشتری را صرف کدنویسی و توسعه آزمایش های خودکار میکند. روش های “شدید” تر همچنین آزمایش پیوسته را در سراسر چرخه حیات، و نیز یک محصول کارا (یا بدون باگ) را در تمام اوقات ترقی میدهند. روش های ساختارمندتر یا “آبشار”-بنیان سعی در ارزیابی اکثر ریسک ها و توسعه یک نقشه دقیق برای نرم افزار، پیش از شروع پیاده سازی (کدنویسی) دارند، و از تغییرات بزرگ در طرح و بازنویسی کد در مراحل بعدی برنامه ریزی چرخه حیاتِ توسعه نرم افزار اجتناب میکنند.

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

فعالیت های توسعه نرم افزار

شناسایی نیاز

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

در کتاب” مناظره های بزرگ نرم افزاری” آلن ام. دیویس در فصل “ملزومات” و زیرفصل “تکه گم شده توسعه نرم افزار” بیان میکند:

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

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

برنامه ریزی توسعه نرم افزاری

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

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

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

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

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

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

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

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

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

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

آموزش نرم افزار و پشتیبانی مهم است، زیرا نرم افزار تنها زمانی اثربخش است که به درستی استفاده شود.

نگهداری و تقویت نرم افزار جهت رفع ملزومات یا نواقصی که جدیداً کشف میشوند، میتواند زمان و زحمت زیادی بگیرد، زیرا ملزوماتِ از قلم افتاده ممکن است باعث تحمیل بازطراحی نرم افزار شوند.

زیرموضوعات

مدل چشم انداز

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

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

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

جدول TEAF برای چشم اندازها و زاویه ها

فرایند تجاری و مدل سازی داده ها

نمایش گرافیکی وضعیت حاضرِ اطلاعات، ابزاری بسیار اثربخش برای نمایش اطلاعات به هردوی کاربران و توسه دهنگان سیستم است.

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

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

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

مثالی از تعامل پردازش تجاری و مدل های داده

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

مهندسی نرم افزار به کمک کامپیوتر Computer-aided software engineering (CASE) ، در رشته مهندسی نرم افزار، کاربرد علمی مجموعه ای از ابزار و روش های نرم افزاری جهت توسعه نرم افزار است که منجر به  تولید محصولات نرم افزاری کیفیت بالا، بی نقص و قابل نگهداری میشود. این عبارت همچنین به روش هایی برای توسعه سیستم های اطلاعاتی همراه با ابزار خودکاری که در پروسه توسعه نرم افزار قابل استفاده هستند اشاره میکند. عبارت مهندسی نرم افزار به کمک کامپیوتر (CASE)، میتواند همچنین به نرم افزار مورد استفاده جهت توسعه خودکار نرم افزار سیستم ها، یعنی کد کامپیوتری، اشاره کند. عملکردهای CASE شامل آنالیز، طراحی و برنامه نویسی است. ابزار CASE روش های طراحی، مستندسازی و تولید کد کامپیوتری ساختارمند را در زبان برنامه نویسی مطلوب، خودکار سازی میکند.

دو ایده کلیدی مهندسیِ نرم افزار سیستم به کمک کامپیوتر (CASE)، عبارت اند از:

•  پرورش کمک کامپیوتری در فرایندهای توسعه نرم افزار و نگهدری نرم افزار، و
• یک روش مهندسی در توسعه و نگهداری نرم افزار.

ابزار معمول CASE جهت مدیریت پیکربندی، مدل سازی داده، تبدیل مدل، بازسازی کد و تولید منبع کد حاضر هستند.

محیط توسعه یکپارچه (Integrated development environment)

یک محیط توسعه یکپارچه (IDE) که به عنوان محیط طراحی یکپارچه یا محیط اشکال زدایی یکپارچه  نیز شناخته میشود اپلیکیشی نرم افزاری است که امکاناتی جامع برای برنامه نویسان کامپیوتر جهت توسعه نرم افزار فراهم میکند. معمولاً یک IDE از اجزای زیر تشکیل میشود:

• ویرایشگر منبع کد،
• کامپایلر یا مفسر،
• ابزار خودکارسازی سازه، و
• (معمولاً) اشکال زُدا (دیباگر).

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

زیرنویس تصویر: آنجوتا، یک IDE سی و سی++ برای محیط GNOME.

زبان مدل سازی

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

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

• نمادگذاری مدل سازی پروسه تجاری(BPMN، و XML از BPML) مثالی از یک زبان مدل سازی پروسه ای است.
• EXPRESS و EXPRESS-G (ISO 10303-11 ) یک زبان مدل سازی داده چند منظوره با استاندارد بین المللی است.
• زبان مدل سازی تشکیلات گسترش یافته (EEML) معمولاً برای مدل سازی پروسه تجاری در چند لایه استفاده میشود.
• فلوچارت، نمایشی ترسیمی از یک الگوریتم یا فرایند قدم به قدم است،
• مفاهیم مدل سازی اساسی (FMC) زبان مدل سازی برای سیستم های نرم فزار-متمرکز.
• IDEF خانواده ای از زبان های مدل سازی است، که مهمترین آن ها شامل IDEF0 برای مدل سازی تابعی، IDEF1X برای مدل سازی اطلاعات، و IDEF5 برای مدل سازی آنتولوژی ها است.
• LePUS3 یک زبان توصیف طراحی بصری شئ گرا و یک زبان تصریحات سوری است که عمدتاً برای مدل سازی برنامه های شئ گرای بزرگ (جاوا، سی ++، سی #) و الگوهای طراحی مناسب است.
• زبان توصیف و تصریح (SDL) یک زبان تصریح است که هدف آن توصیف و تصریح بدون ابهام رفتار رایانش توزیع یافته واکنشی است.
• زبان مدل سازی یکپارچه (UML) یک زبان مدل سازی چندمنظوره است که به استانداردی صنعتی برای تصریح سیستم های نرم افزار-متمرکز تبدیل شده است. UML 2.0، نسخه فعلی، سیزده تکنیک دیاگرامی متفاوت را پشتیبانی میکند و پشتیبانی ابزاری گسترده ای دارد.

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

پارادایم برنامه نویسی

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

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

همانطور که گروه های مختلف در مهندسی نرم افزار متدلوژی های مختلفی را توصیه میکنند، زبان های برنامه نویسی متفاوت، پارادایم های برنامه نویسی مختلفی را توصیه میکنند. برخی زبان ها به گونه ای طراحی شده اند که یک پارادیم را پشتیبانی کنند (اسمالتاک برنامه نویسی شئ گرا را پشتیبانی میکند، هسکل برنامه نویسی تابعی را پشتیبانی میکند)، در حالیکه سایر زبان های برنامه نویسی چند پارادایم را پشتیبانی میکنند (مثل آبچکت پاسکال، سی++، سی#، ویژوال بیسیک، کامن لیسپ، اسکیم، پایتون، روبی و اُز).

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

مثال هایی از پارادایم های سطح بالا عبارت اند از:

• توسعه نرم افزار وجه-گرا (Aspect-oriented software development)
• مدل سازی مختص دامنه (Domain-specific modeling)
• مهندسی مدل-رانده (Model-driven engineering)
• متدلوژی های برنامه نویسی شئ گرا (Object-oriented programming methodologies)
  • طرح شئ گرای گرادی بوچ (OOD)، که به عنوان طراحی و تحلیل شئ گرا (OOAD) هم شناخته میشود. مدل بوچ دارای شش دیاگرام است: کلاس، شئ، انتقال وضع، تعامل، مدول و پروسه.
• مهندسی نرم افزار جستجو-بنیان (Search-based software engineering)
• مدل سازی سرویس-گرا (Service-oriented modeling)
• برنامه نویسی ساختارمند (Structured programming)
• طراحی بالا-پایین و چپ-راست (Top-down and bottom-up design)
  • برنامه نویسی بالا-پایین (Top-down programming) : تکامل یافته در دهه 1970 توسط پژوهشگر IBM هارلان میلس (و نیکلاس ویرث) در برنامه نویسی ساختارمند توسعه یافته.

استفاده مجدد از راه حل ها

• چارچوب نرم افزاری (software framework ) ، یک طرح یا پیاده سازیِ باز-استفاده پذیر برای یک سیستم یا زیرسیستم نرم افزاری است.
• مولفه های موجود (مهندسی نرم افزار مولفه-بنیان) را میتوان استفاده مجدد و مونتاژ نمود تا اپلیکیشنی بزرگتر شکل گیرد.
• API (رابط برنامه نویسی کاربردی، سرویس وب) مجموعه ای از “تعاریف، پروتکل ها و ابزار زیر-روال برای ساخت نرم افزار کاربردی” وضع میکند که در سازه های آتی میتوان از آن استفاده کرد.
• مستندسازی منبع باز، به واسطه کتابخانه هایی از قبیل GitHub، کدهای رایگانی برای استفاده مجدد و پیاده سازی در اپلیکیشن ها و طرح های جدید در اختیار توسعه دهنگاه نرم افزار قرار میدهد.