У софтверском инжењерству, методологија за развој софтвера (позната и као методологија за развој система, развој софтверског животног циклуса, процес развоја софтвера, софтверски процес) је развој софтверског рада у различитим фазама (или фазе) који садржи активности са намерама за боље планирање и управљање. Често се сматра подскупом система развоја животног циклуса. Методологија може укључити пре-дефинисање конкретних резултата и артефаката који су створени и завршени од стране пројектног тима за развој или одржавање апликације.[1]
Уобичајене методологије укључују водопад модел, израду прототипова, итеративни и постепен развој, спирални развој, брз развој апликација, екстремно програмирање и разне врсте агилане методологије. Неки људи сматрају да животни циклус "модела" је општији термин за категорију методологије и "процеса" развоја софтвера а конкретнији назив се односи на конкретан процес по избору одређене организације. На пример, постоје многи специфични процеси развоја софтвера који се уклапају у спирални животни век модела.
Мноштво тих оквира је еволуирало током година, сваки са својим признатим предностима и слабостима. Развојни оквири методологије софтвера није нужно погодан за употребу од стране свих пројеката. Сваки од расположивих методологија оквира су најбољи одговари за специфичне врсте пројеката, на основу различитих техника, организација, пројеката и тимова разматрања.[1]
Организације за развој софтвера спроведе процес методологије да олакша процес развоја. Понекад, извођачи радова могу да захтевају методологију запослених, пример је америчка одбрамбена индустрија, која захтева оцену на основу процеса модела за добијање уговора. Међународни стандард за описивање начина одабира, спровођење и праћење животног циклуса за софтвер је ISO/IEC 12207.
Вишедеценијски циљ је био да пронађу понављање, предвидљиви процеси који побољшавају продуктивност и квалитет. Неки покушавају да систематизују или формализују наизглед весели задатак за дизајнирање софтвера. Други примењују технике управљања пројектима у дизајнирању софтвера. Без ефикасног управљања пројектима, софтверски пројекти могли би лако бити касно испоручени или преко буџета. Уз велики број софтверских пројеката не испуњавају њихова очекивања по питању функционалности, трошкова, или о роковима испоруке,јер ефикасно управљање пројектом изгледа да недостаје.
Организације могу створити групу софтверског инжењерства, што је кључна тачка за побољшање процеса. Састоји се од ресорних практичара који имају различите вештине, група је центар заједничког напора свих у организацији, која се бави побољшањем софтверског инжењерства.
Посебно развојни тим може да пристане на програмско окружење детаља, као што је интегрисано развојно окружење које се користи, и један или више доминантних парадигми програмирања, правила програмирања стила или избор специфичних софтверских библиотека или софтверских оквира. Ови детаљи углавном нису диктирани избором модела или општом методологијом.
Развој методологије софтвера (такође познат као СДМ) није настао до 1960. године. Према Elliott (2004) развој животног циклуса система (СДЛЦ) може се сматрати да је најстарија формализована методологија оквира за изградњу информационих система. Основна идеја СДЛЦ је била "да настави развој информационих система на организован и методичан начин, захтевајући сваку фазу животног циклуса - од настанка идеје до испоруке финалног система - да буде обављан строго и редом[2] примењујући контекст оквира. Главни циљ ове методологије оквира у 1960. био је "да се развије велики обим функционалних пословних система у ери великих пословних конгломерата. Информациони системи активности врти се око тешке обраде података и бројне рутине".[2]
Методологије, процеси, и оквири у распону од специфичних рестриктивних корака који се могу директно користити од стране организације у дан у дан рада, до флексибилних оквирима које организација користи да генерише прилагођени скуп корака прилагођених потребама конкретног пројекта или групе. У неким случајевима "спонзор" или "Одржавање" организација дистрибуира званични скуп докумената који описују процес. Специфични примери укључују:
- 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
Неколико развојних софтверских приступа се користи од настанка информационе технологије, у две главне категорије. Типичан приступ или комбинација приступа је изабрано од стране менаџмента или развојног тима.
"Традиционалне" методологије, као што је водопад који имају различите фазе се понекад називају развојем животног циклуса софтвера (СДЛЦ), мада овај термин такође може да се користи уопштено и да се односи на било коју методологију. А "животни циклус" приступ са одвојеним фазама је у супротности са Агиле приступима који дефинишу процес понављања, али где пројектовање, изградња и распоређивање различитих делова може доћи истовремено.
Развој водопад модела
Водопад модел је секвенцијални приступ развоју, у којем се види како развој тече надоле (као водопад) кроз неколико фаза, типично:
- Анализа резултата услова у захтевима спецификације софтвера
- Софтверски дизајн
- Имплементација
- Тестирање
- Интеграција, ако постоји више подсистема
- Распоређивање (или инсталација)
- Одржавање
Први формални опис метода се често наводи као чланка објављеном од стране Winston W. Royce[3] 1970. године иако Royce није користио термин "Водопад" у овом чланку. Основни принципи су:[1]
- Пројекат је подељен на узастопне фазе, са неким преклапањима између фаза.
- Нагласак је на планирању, временским распоредом, роковима, буџетим и реализацијом читавог система у једном тренутку.
- Строга контрола се одржава током трајања пројекта путем обимне писане документације, формалних прегледа и одобрења / искључења од стране корисника и информационе технологије управљања која је настала крајем већине фаза пре почетка следеће фазе.
Водопад модел је традиционални инжењерски приступ примењен на софтверско инжењерство. Строг приступ водопаду обесхрабрује преглед и проверу било какве фазе након што је завршена. Ова "нефлексибилност" у чистом водопад моделу је био извор критика од стране присталица других "флексибилних" модела. То је велики блам за владине пројекте неколико великих радова преко буџета, током времена и понекад не да испуни захтеве услед великог Дизајн напред приступа. Осим када је уговором потребно, водопад модел је углавном замењен флексибилнијом и развијенијом методологијом за развој софтвера. Погледајте критике водопад модела.
Водопад модел се такође често учи са мнемоником Плес у мраку сваког понедељка, представља анализу, дизајн, имплементацију, тестирање, документацију и извођење и одржавање.
Прототипови
Софтвер прототипа, је развојни приступ активности током развоја софтвера, креирање прототипа, односно непотпуне верзије софтвера се развијају.
Основни принципи су:[1]
- Несамосталана, комплетна методологија развоја, већ је приступ да издржи одабране делове веће, традиционално развојне методологије (тј постепени, спирални, или брз развој апликација (РАД)).
- Покушаји да се смањи потенцијални ризик пројекта разбијањем пројекта на мање сегменте и пружање више једноставних промена током процеса развоја.
- Корисник је укључен током развојног процеса, што повећава вероватноћу прихватања корисника коначне реализације.
- Малог обима макете система су развијене итеративним процесом модификације све док прототип еволуира у сусрет захтевима корисника.
- Док већина прототипова је развијено са очекивањем да ће бити одбачени, могуће је у неким случајевима да еволуира од прототипа на рад система.
- Основно разумевање основног пословног проблема неопходно је да се избегне решавање проблема
Постепени развој
Различите методе су прихватљиве за комбиновање линеарних и итеративних методологија развоја система, са примарним циљем сваког да се смањи потенцијални ризик пројекта разбијањем пројекат на мање сегменте и пружање више једноставности током процеса развоја.
Основни принципи су[1]
- Низ мини водопада се изводе, где су све фазе водопада завршене за мали део система, пре него што пређете на следећи прираст, или
- Укупни захтеви су дефинисани пре него што наставите да еволуирате, развој појединих корака мини-водопада у систему, или
- Првобитни концепт софтвера, анализа захтева и дизајн архитектуре и система језгра су дефинисани преко водопада, а затим итеративном израдом прототипова, који кулминирају у инсталирању коначног прототипа, радног система.
Итеративни и постепени развој
Итератни развој[4] прописује изградњу која је у почетку мала, али увек веће порције софтверског пројекта да се помогне свима онима који су укључени да открију важне теме рано пред проблемима или неисправне претпоставке које могу довести до катастрофе.
Спирални развој
.svg)
Године 1988, Barry Boehm је објавио развој система софвера као "спирални модел", који комбинује неке кључне аспекет водопад модела и брзу израду прототипова методологије, у настојању да се комбинују предности од врха ка дну и одоздо према горе концепата. Она је дала нагласак у кључној области које су запостављене од стране других методологија: намерно итеративном ризичном анализом, посебно погодном за велики број комплексних система.
Основни принципи су:[1]
- Фокус је на процени ризика и смањењу ризика пројекта разбијањем пројекта на мање сегменте и пружање доста једноставне промене током процеса развоја, као и пружање прилике да оцене ризика вагају разматрање пројекта током животног циклуса.
- "Сваки циклус укључује прогресију истом секвенцом корака, за сваки део производа и за сваки његов ниво израде, из укупног концепта-оф-операције документа доле на кодирање сваког индивидуалног програма."[5]
- Сваки пут око спирале прелази четири основна квадраната: (1) одређују циљеве, алтернативе, и ограничења у итерацији; (2) процењују алтернативе; идентификација и решавање ризика; (3) развој и верификација испоруке из итерације; и (4) планира следећу итерацију.[6]
- Почните сваки циклус са идентификацијом актера и њиховим "добитним условима", и на крају сваког циклуса са прегледима и посвећености.[7]
Брзи развој апликација
Брз развој апликација (РАД) је методологија развоја софтвера, која фаворизује итеративни развој и брзу изградњу прототипова уместо велике количине уп-фронт планирања."Планирање" развоја софтвера користећи РАД је прошарано писање самог софтвера. Недостатак унапред планирања генерално омогућава софтверу да буде написан много брже, и олакшава да се промени захтеве.
Брз развој процеса почиње са развојем прелиминарних модела података и пословних процеса модела који користе структуриране технике. У наредној фази, захтеви се верификују помоћу прототипа, на крају да побољшају моделе података и процеса. Ове фазе се итеративно понављају; даљи развој резултата у "комбинованим пословним захтевима и техничкој дизајн изјави се користи за изградњу нових система".[8]
Термин је први пут употребљен да опише процес за развој софтвера који је увео James Martin 1991. Према писању (2003), то је спајање различитих структурних техника, нарочито подаци Информатичког инжењеринга, са техникама за израду прототипова да убрзају развој софтверских система.[8]
Основни принципи брзог развоја апликација су:[1]
- Кључни циљ је брз развој и испоруку високог система квалитета у релативно ниској цени инвестиција.
- Покушаји да се смањи потенцијални ризик пројекта разбијањем пројекта на мање сегменте и пружање више једноставне промене током процеса развоја.
- Има за циљ да произведе висококвалитетне системе брзо, пре свега преко итеративних Прототипова (у било којој фази развоја), активно учешће корисника, и компјутеризоване развојним алатима. Ови алати могу укључивати Графички кориснички интерфејс (GUI) builders, Computer Aided Software Engineering (CASE) tools, База података (DBMS), Четврта генерација програмског језика, код генератори и технике објектно оријентисане
- Кључни акценат је на испуњењу пословне потребе, док је технолошка или инжењеринг изврсност од мањег значаја.
- Контрола Пројекта укључује приоритете развоја и дефинисања рокова испоруке или "timeboxes". Ако се пројекат провуче, нагласак је на смањењу потреба да се уклопи у Тимебок, не у повећању рока.
- Генерално подразумева заједнички дизајн апликација (ЈАД), где корисници су интензивно укључени у дизајну система, преко консензуса у било структурним радионицама или електронски олакшаном интеракцијом.
- Активно укључивање корисника је императив.
- Итеративни производи за производњу софтвера
- Производи документације неопходни да олакшају будући развој и одржавање
- Стандардна анализа система и методе дизајна могу се уградити у овај оквир.
Агилни развој
"Агилни развој софтвера" се односи на групу софтверских методологија развоја заснованог на итеративном развоју, где захтеви и решења еволуирају преко сарадње самоорганизујућих крос-функционалних тимова. Термин је настао у 2001. години када је формулисан агилни развој софтвера.
Агилни развој софтвера користи итеративни развој као основу, али се залаже за упаљач и више људи имају оријентисано мишљење традиционалних приступа. Агилни процеси у основи укључе итерацију и континуирану повратну информацију да пружа сукцесивну прераду и да достави софтверски систем.
Постоје многе агилне методологије, укључујући:
- Развој метода динамичког система (DSDM)
- Канбан
- Скрам
Код и поправка
"Код и поправка" развој није толико намерно стратегија, као резултат притиска на распореду програмера.[9] Без много дизајна, програмери почињу одмах производњом кода. У једном тренутку, испитивање почиње (често касно у развојном циклусу), а незаобилазни багови онда морају бити поправљени пре него што производ буде испоручен. Програмирање без планираног дизајна је такође познато као каубој кодирање.
Лагане методологије
Лагана методологија има мали број правила. Неке од ових метода се такође сматрају "агилном".
- Адапривни развој софтвера описао је Jim Highsmith, 1999., у својој књизи Adaptive Software Development
- Crystal Clear породица методологије са Alistair Cockburn,
- Екстремно програмирање (XP), промовисан од стране људи као што су Kent Beck и Martin Fowler. У екстремном програмирању, фазе се спроводе у изузетно малим (или "континуираним") корацима у односу на старије "batch" процесе. Прво, један пише аутоматизоване тестове, да обезбеди конкретне циљеве за развој. Следеће је кодирање (од стране програмера који раде у паровима, технику познату као "пар програмирања"), које је завршено када сви тестови прођу, а програмери не могу да се сете више тестова који су потребни. Дизајн и архитектура излазе из рефакторисања, а долазе након кодирања. Исти људи који раде кодирање ураде и дизајн. (Само последња опција - спајање дизајна и кода - је заједничко свим осталим агилним процесима.) . У овом тренутку, практиканти поново почињу писање тестова за наредни најбитнији део система.[10]
- Feature Driven Development (FDD) развијен (1999) ода стране Jeff De Luca и Peter Coad
- ICONIX - UML-заснован објекат моделирања са случајевима употребе, лагани увод у Rational Unified Process
Друго
Остале методологије софтверско пројекта на високом нивоу су:
- Chaos модел- Основно правило је увек прво реши најважнија питања.
- Методологија постепеног финансирања - итеративни приступ
- Структурна анализа система и метода дизајна - посебна верзија водопада
- Споро програмирање, као део ширег спорог кретања, наглашава пажљив и постепен рад без временског притиска. Споро програмирање има за циљ да се избегну грешке и сувише брзо ослобађање распореда.
- V-Модел (Развој софтвера) - продужетак водопад модела
- Обједињени процес (UP) је понављање методологије за развој софтверског оквира, на основу Unified Modeling Language (UML). UP организује развој софтвера у четири фазе, свака се састоји од једног или више извршних понављања софтвера у тој фази развоја почетак, израду, изградњу и смернице. Многи алати и производи постоје да би се олакшало UP имплементацију. Једна од популарнијих верзија UP је Rational Unified Process (RUP).
Неки "процес модели" су апстрактни описи за вредновање, упоређивање и побољшање специфичног процеса усвојеног од стране организације.
- ISO/IEC 12207 је међународни стандард који описује начин да одаберете, имплементирате и пратите животни циклус за софтвер.
- Capability Maturity Model Integration (CMMI) је један од водећих модела основу најбоље праксе. Независне процене граде организације о томе како добро да прате своје дефинисане процесе, а не на квалитет тих процеса или софтвера произведеног. CMMI је заменио CMM.
- ISO 9000 описује стандарде за формално организован процес за производњу производа и методе управљања и праћења напретка. Иако је стандардни првобитно направљен за производни сектор, ISO 9000 стандарди су примењени у развоју софтвера као добро. Као CMMI, сертификација са ИSО 9000 не гарантује квалитет крајњег резултата, они су пратили формализоване пословне процесе.
- ISO/IEC 15504 Информациона технологија - Процес процене такође познат као Процес могућности одређивања софтвера (SPICE), је "оквир за процену софтверских процеса". Овај стандард има за циљ успостављање јасног модела за процес поређења. SPICE се користи слично као CMMI. Модели процеса за управљање, контролу, води и надгледа развој софтвера. Овај модел се затим користи за мерење шта развојна организација или пројектни тим заправо ради током развоја софтвера. Ове информације се анализирају да идентификују слабости и побољшање диска. Такође идентификује предности које може наставити или интегрисани у уобичајеној пракси те организације или тима.
- Методологија софт система - општи метод за побољшање процеса управљања
- Метод инжењеринга - општи метод за побољшање процеса информационог систем
Формалне методе су математички приступи решавању софтверских (и хардвера) проблема у захтевима, ниво спецификација и дизајна. Формалне методе се највероватније примењују за безбедност критичног софтвера и система, као што је авионика софтвера. Стандардна безбедност софтвера , као што је DO-178B, DO-178C, и опште критеријумима захтевају формалне методе у највишим нивоима категоризације.
За секвенцијални софтвер, примери формалних метода укључују B-метод, језике који се користе у спецификацијама аутоматизованог доказивања теорема, RAISE, и Z запис.
Формализација развоја софтвера је ситна, на другим местима, уз примену Object Constraint Language (и специјализације, као што је Java Modeling Language), а посебно са модела погон архитектуре дозвољава извршење пројеката, ако не и спецификације.
За истовремено софтвер и систем, Петри мреже, процес алгебре и коначне државне машине (које су засноване на теорији аутомата - види виртуелни коначни аутомат) дозвољавају извршавање софтвера спецификације и може да се користи да изгради и потврди апликацију понашања.
Други настојани тренд у развоју софтвера је да напише спецификацију у неком логичцном облику обично варијација првог реда логике(FOL) -и онда да директно изврши логику као да је програм. Језик OWL , на основу Описне логике (DL), је пример. То је рад на мапирању неке верзије енглеског (или неки други природни језик) аутоматски да и из логике, и извршавање логике буде директно. Примери су Attempto Controlled English и Интернет пословна логика, која не тражи да контролише вокабулар или синтаксу. Карактеристика система који подржавају двосмерно мапирање Енглеске-логике и директно извршење логике је да могу да објасне своје резултате, на енглеском језику, на послу или научном нивоу.
- Софтверско инжењерство рачунара (неки од ових алата подржава специфичне методологије)
- Филозофија развоја софтвера
- Иза линије софтверског инжењерства
- Пројектни менаџмент
- Развој софтвера
- Процена напора развоја софтвера
- Животни циклус софтверских издања
- Софтверски дизајн
- Дебаговање
- Софтверско распоређивање
- Одржавање софтвера
- Конструкција софтвера
- Тестирање софтвера
- Анализа захтева
- Софтверско инежењерство
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
