У софтверском инжењерству, методологија за развој софтвера (позната и као методологија за развој система, развој софтверског животног циклуса, процес развоја софтвера, софтверски процес) је развој софтверског рада у различитим фазама (или фазе) који садржи активности са намерама за боље планирање и управљање. Често се сматра подскупом система развоја животног циклуса. Методологија може укључити пре-дефинисање конкретних резултата и артефаката који су створени и завршени од стране пројектног тима за развој или одржавање апликације.Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008).
Уобичајене методологије укључују водопад модел, израду прототипова, итеративни и постепен развој, спирални развој, брз развој апликација, екстремно програмирање и разне врсте агилне методологије. Неки људи сматрају да животни циклус "модела" је општији термин за категорију методологије и "процеса" развоја софтвера а конкретнији назив се односи на конкретан процес по избору одређене организације. На пример, постоје многи специфични процеси развоја софтвера који се уклапају у спирални животни век модела.
У пракси thumb|420x420px|Три основна приступа која развојног оквира методологије софтвера. Мноштво тих оквира је еволуирало током година, сваки са својим признатим предностима и слабостима. Развојни оквири методологије софтвера није нужно погодан за употребу од стране свих пројеката. Сваки од расположивих методологија оквира су најбољи одговори за специфичне врсте пројеката, на основу различитих техника, организација, пројеката и тимова разматрања.
Организације за развој софтвера спроведе процес методологије да олакша процес развоја. Понекад, извођачи радова могу да захтевају методологију запослених, пример је америчка одбрамбена индустрија, која захтева оцену на основу процеса модела за добијање уговора. Међународни стандард за описивање начина одабира, спровођење и праћење животног циклуса за софтвер је ISO/IEC 12207.
Вишедеценијски циљ је био да пронађу понављање, предвидљиви процеси који побољшавају продуктивност и квалитет. Неки покушавају да систематизују или формализују наизглед весели задатак за дизајнирање софтвера. Други примењују технике управљања пројектима у дизајнирању софтвера. Без ефикасног управљања пројектима, софтверски пројекти могли би лако бити касно испоручени или преко буџета. Уз велики број софтверских пројеката не испуњавају њихова очекивања по питању функционалности, трошкова, или о роковима испоруке,јер ефикасно управљање пројектом изгледа да недостаје.
Организације могу створити групу софтверског инжењерства, што је кључна тачка за побољшање процеса. Састоји се од ресорних практичара који имају различите вештине, група је центар заједничког напора свих у организацији, која се бави побољшањем софтверског инжењерства.
Посебно развојни тим може да пристане на програмско окружење детаља, као што је интегрисано развојно окружење које се користи, и један или више доминантних парадигми програмирања, правила програмирања стила или избор специфичних софтверских библиотека или софтверских оквира. Ови детаљи углавном нису диктирани избором модела или општом методологијом.
Историја Развој методологије софтвера (такође познат као СДМ) није настао до 1960. године. Према Elliott (2004) развој животног циклуса система (СДЛЦ) може се сматрати да је најстарија формализована методологија оквира за изградњу информационих система. Основна идеја СДЛЦ је била "да настави развој информационих система на организован и методичан начин, захтевајући сваку фазу животног циклуса - од настанка идеје до испоруке финалног система - да буде обављан строго и редом. примењујући контекст оквира. Главни циљ ове методологије оквира у 1960. био је "да се развије велики обим функционалних пословних система у ери великих пословних конгломерата. Информациони системи активности врти се око тешке обраде података и бројне рутине".
Методологије, процеси, и оквири у распону од специфичних рестриктивних корака који се могу директно користити од стране организације у дан у дан рада, до флексибилних оквирима које организација користи да генерише прилагођени скуп корака прилагођених потребама конкретног пројекта или групе. У неким случајевима "спонзор" или "Одржавање" организација дистрибуира званични скуп докумената који описују процес. Специфични примери укључују: 1970 Структурирано програмирање од 1969. године Cap Gemini SDM, пореклом из ПАНДАТЕ, први енглески превод је објављен 1974. СДМ стоји за систем методологије за израду 1980 Структурна системска анализа и метода дизајна (ССАДМ) од 1980. па надаље Information Requirement Analysis/Soft systems methodology 1990 Објектно оријентисано програмирање (ООП) развијено у раним 1960-им, и постало доминантан приступ програмирању током средине 1990-их Брз развој апликација(РАД) од 1991.
Методе развоја динамичког система, од 1994 Скрам, од 1995 Team software process, од 1998 Rational Unified Process (RUP), одржава га IBM од 1998 Екстремно програмирање, од 1999. године
2000 Agile Unified Process (AUP) одржава се од 2005. од стране Scott Ambler
Приступи Неколико развојних софтверских приступа се користи од настанка информационе технологије, у две главне категорије. Типичан приступ или комбинација приступа је изабрано од стране менаџмента или развојног тима.
"Традиционалне" методологије, као што је водопад који имају различите фазе се понекад називају развојем животног циклуса софтвера (СДЛЦ), мада овај термин такође може да се користи уопштено и да се односи на било коју методологију. А "животни циклус" приступ са одвојеним фазама је у супротности са Агиле приступима који дефинишу процес понављања, али где пројектовање, изградња и распоређивање различитих делова може доћи истовремено.
Развој водопад модела thumb|Активности у процесу развоја софтвера представљени у водопад моделу. Постоји неколико других модела који представљају овај процес. Водопад модел је секвенцијални приступ развоју, у којем се види како развој тече надоле (као водопад) кроз неколико фаза, типично: Анализа резултата услова у захтевима спецификације софтвера Софтверски дизајн Имплементација Тестирање Интеграција, ако постоји више подсистема Распоређивање (или инсталација) Одржавање Први формални опис метода се често наводи као чланка објављеном од стране Winston W. RoyceWasserfallmodell > Entstehungskontext , Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. 1970. године иако Royce није користио термин "Водопад" у овом чланку. Основни принципи су: Пројекат је подељен на узастопне фазе, са неким преклапањима између фаза.
Нагласак је на планирању, временским распоредом, роковима, буџетом и реализацијом читавог система у једном тренутку.
Строга контрола се одржава током трајања пројекта путем обимне писане документације, формалних прегледа и одобрења / искључења од стране корисника и информационе технологије управљања која је настала крајем већине фаза пре почетка следеће фазе.
Водопад модел је традиционални инжењерски приступ примењен на софтверско инжењерство. Строг приступ водопаду обесхрабрује преглед и проверу било какве фазе након што је завршена. Ова "нефлексибилност" у чистом водопад моделу је био извор критика од стране присталица других "флексибилних" модела. То је велики блам за владине пројекте неколико великих радова преко буџета, током времена и понекад не да испуни захтеве услед великог Дизајн напред приступа. Осим када је уговором потребно, водопад модел је углавном замењен флексибилнијом и развијенијом методологијом за развој софтвера. Погледајте критике водопад модела.
Водопад модел се такође често учи са мнемоником Плес у мраку сваког понедељка, представља анализу, дизајн, имплементацију, тестирање, документацију и извођење и одржавање.
Прототипови Софтвер прототипа, је развојни приступ активности током развоја софтвера, креирање прототипа, односно непотпуне верзије софтвера се развијају.
Основни принципи су: Несамосталана, комплетна методологија развоја, већ је приступ да издржи одабране делове веће, традиционално развојне методологије (тј постепени, спирални, или брз развој апликација (РАД)).
Покушаји да се смањи потенцијални ризик пројекта разбијањем пројекта на мање сегменте и пружање више једноставних промена током процеса развоја.
Корисник је укључен током развојног процеса, што повећава вероватноћу прихватања корисника коначне реализације.
Малог обима макете система су развијене итеративним процесом модификације све док прототип еволуира у сусрет захтевима корисника.
Док већина прототипова је развијено са очекивањем да ће бити одбачени, могуће је у неким случајевима да еволуира од прототипа на рад система.
Основно разумевање основног пословног проблема неопходно је да се избегне решавање проблема
Постепени развој Различите методе су прихватљиве за комбиновање линеарних и итеративних методологија развоја система, са примарним циљем сваког да се смањи потенцијални ризик пројекта разбијањем пројекат на мање сегменте и пружање више једноставности током процеса развоја.
Основни принципи су Низ мини водопада се изводе, где су све фазе водопада завршене за мали део система, пре него што пређете на следећи прираст, или Укупни захтеви су дефинисани пре него што наставите да еволуирате, развој појединих корака мини-водопада у систему, или Првобитни концепт софтвера, анализа захтева и дизајн архитектуре и система језгра су дефинисани преко водопада, а затим итеративном израдом прототипова, који кулминирају у инсталирању коначног прототипа, радног система.
Итеративни и постепени развој Итератни развој прописује изградњу која је у почетку мала, али увек веће порције софтверског пројекта да се помогне свима онима који су укључени да открију важне теме рано пред проблемима или неисправне претпоставке које могу довести до катастрофе.
Спирални развој thumb|400x400px|Спирални модел (Boehm, 1988) Године 1988, Barry Boehm је објавио развој система софтвера као "спирални модел", који комбинује неке кључне аспекте водопад модела и брзу израду прототипова методологије, у настојању да се комбинују предности од врха ка дну и одоздо према горе концепата. Она је дала нагласак у кључној области које су запостављене од стране других методологија: намерно итеративном ризичном анализом, посебно погодном за велики број комплексних система.
Основни принципи су: Фокус је на процени ризика и смањењу ризика пројекта разбијањем пројекта на мање сегменте и пружање доста једноставне промене током процеса развоја, као и пружање прилике да оцене ризика вагају разматрање пројекта током животног циклуса.
"Сваки циклус укључује прогресију истом секвенцом корака, за сваки део производа и за сваки његов ниво израде, из укупног концепта-оф-операције документа доле на кодирање сваког индивидуалног програма."Barry Boehm (1996., "A Spiral Model of Software Development and Enhancement". Сваки пут око спирале прелази четири основна квадраната: (1) одређују циљеве, алтернативе, и ограничења у итерацији; (2) процењују алтернативе; идентификација и решавање ризика; (3) развој и верификација испоруке из итерације; и (4) планира следећу итерацију.Richard H. Thayer, Barry W. Boehm (1986). Почните сваки циклус са идентификацијом актера и њиховим "добитним условима", и на крају сваког циклуса са прегледима и посвећености.Barry W. Boehm (2000).
Брзи развој апликација thumb|Модел брзог развоја апликација Брз развој апликација (РАД) је методологија развоја софтвера, која фаворизује итеративни развој и брзу изградњу прототипова уместо велике количине уп-фронт планирања."Планирање" развоја софтвера користећи РАД је прошарано писање самог софтвера. Недостатак унапред планирања генерално омогућава софтверу да буде написан много брже, и олакшава да се промени захтеве.