Back

ⓘ Развојни циклус софтвера




                                     

ⓘ Развојни циклус софтвера

У софтверском инжењерству, методологија за развој софтвера је развој софтверског рада у различитим фазама који садржи активности са намерама за боље планирање и управљање. Често се сматра подскупом система развоја животног циклуса. Методологија може укључити пре-дефинисање конкретних резултата и артефаката који су створени и завршени од стране пројектног тима за развој или одржавање апликације.

Уобичајене методологије укључују водопад модел, израду прототипова, итеративни и постепен развој, спирални развој, брз развој апликација, екстремно програмирање и разне врсте агилане методологије. Неки људи сматрају да животни циклус "модела" је општији термин за категорију методологије и "процеса" развоја софтвера а конкретнији назив се односи на конкретан процес по избору одређене организације. На пример, постоје многи специфични процеси развоја софтвера који се уклапају у спирални животни век модела.

                                     

1. У пракси

Мноштво тих оквира је еволуирало током година, сваки са својим признатим предностима и слабостима. Развојни оквири методологије софтвера није нужно погодан за употребу од стране свих пројеката. Сваки од расположивих методологија оквира су најбољи одговари за специфичне врсте пројеката, на основу различитих техника, организација, пројеката и тимова разматрања.

Организације за развој софтвера спроведе процес методологије да олакша процес развоја. Понекад, извођачи радова могу да захтевају методологију запослених, пример је америчка одбрамбена индустрија, која захтева оцену на основу процеса модела за добијање уговора. Међународни стандард за описивање начина одабира, спровођење и праћење животног циклуса за софтвер је ISO/IEC 12207.

Вишедеценијски циљ је био да пронађу понављање, предвидљиви процеси који побољшавају продуктивност и квалитет. Неки покушавају да систематизују или формализују наизглед весели задатак за дизајнирање софтвера. Други примењују технике управљања пројектима у дизајнирању софтвера. Без ефикасног управљања пројектима, софтверски пројекти могли би лако бити касно испоручени или преко буџета. Уз велики број софтверских пројеката не испуњавају њихова очекивања по питању функционалности, трошкова, или о роковима испоруке,јер ефикасно управљање пројектом изгледа да недостаје.

Организације могу створити групу софтверског инжењерства, што је кључна тачка за побољшање процеса. Састоји се од ресорних практичара који имају различите вештине, група је центар заједничког напора свих у организацији, која се бави побољшањем софтверског инжењерства.

Посебно развојни тим може да пристане на програмско окружење детаља, као што је интегрисано развојно окружење које се користи, и један или више доминантних парадигми програмирања, правила програмирања стила или избор специфичних софтверских библиотека или софтверских оквира. Ови детаљи углавном нису диктирани избором модела или општом методологијом.

                                     

2. Историја

Развој методологије софтвера такође познат као СДМ није настао до 1960. године. Према Elliott 2004 развој животног циклуса система СДЛЦ може се сматрати да је најстарија формализована методологија оквира за изградњу информационих система. Основна идеја СДЛЦ је била "да настави развој информационих система на организован и методичан начин, захтевајући сваку фазу животног циклуса - од настанка идеје до испоруке финалног система - да буде обављан строго и редом примењујући контекст оквира. Главни циљ ове методологије оквира у 1960. био је "да се развије велики обим функционалних пословних система у ери великих пословних конгломерата. Информациони системи активности врти се око тешке обраде података и бројне рутине".

Методологије, процеси, и оквири у распону од специфичних рестриктивних корака који се могу директно користити од стране организације у дан у дан рада, до флексибилних оквирима које организација користи да генерише прилагођени скуп корака прилагођених потребама конкретног пројекта или групе. У неким случајевима "спонзор" или "Одржавање" организација дистрибуира званични скуп докумената који описују процес. Специфични примери укључују:

1970
  • Cap Gemini SDM, пореклом из ПАНДАТЕ, први енглески превод је објављен 1974. СДМ стоји за систем методологије за израду
  • Структурирано програмирање од 1969. године
1980
  • Структурна системска анализа и метода дизајна ССАДМ од 1980. па надаље
  • Information Requirement Analysis/Soft systems methodology
1990
  • Објектно оријентисано програмирање ООП развијено у раним 1960-им, и посталоа доминантан приступ програмирању током средине 1990-их
  • Брз развој апликацијаРАД од 1991.
  • Team software process, од 1998
  • Екстремно програмирање, од 1999. године
  • Методе развоја динамичског система, од 1994
  • Скрам, од 1995
  • Rational Unified Process RUP, одржава га IBM од 1998
2000
  • Agile Unified Process AUP одржава се од 2005. од стране Scott Ambler
                                     

3. Приступи

Неколико развојних софтверских приступа се користи од настанка информационе технологије, у две главне категорије. Типичан приступ или комбинација приступа је изабрано од стране менаџмента или развојног тима.

"Традиционалне" методологије, као што је водопад који имају различите фазе се понекад називају развојем животног циклуса софтвера СДЛЦ, мада овај термин такође може да се користи уопштено и да се односи на било коју методологију. А "животни циклус" приступ са одвојеним фазама је у супротности са Агиле приступима који дефинишу процес понављања, али где пројектовање, изградња и распоређивање различитих делова може доћи истовремено.

                                     

3.1. Приступи Развој водопад модела

Водопад модел је секвенцијални приступ развоју, у којем се види како развој тече надоле као водопад кроз неколико фаза, типично:

  • Одржавање
  • Анализа резултата услова у захтевима спецификације софтвера
  • Софтверски дизајн
  • Распоређивање или инсталација
  • Тестирање
  • Интеграција, ако постоји више подсистема
  • Имплементација

Први формални опис метода се често наводи као чланка објављеном од стране Winston W. Royce 1970. године иако Royce није користио термин "Водопад" у овом чланку. Основни принципи су:

  • Пројекат је подељен на узастопне фазе, са неким преклапањима између фаза.
  • Нагласак је на планирању, временским распоредом, роковима, буџетим и реализацијом читавог система у једном тренутку.
  • Строга контрола се одржава током трајања пројекта путем обимне писане документације, формалних прегледа и одобрења / искључења од стране корисника и информационе технологије управљања која је настала крајем већине фаза пре почетка следеће фазе.

Водопад модел је традиционални инжењерски приступ примењен на софтверско инжењерство. Строг приступ водопаду обесхрабрује преглед и проверу било какве фазе након што је завршена. Ова "нефлексибилност" у чистом водопад моделу је био извор критика од стране присталица других "флексибилних" модела. То је велики блам за владине пројекте неколико великих радова преко буџета, током времена и понекад не да испуни захтеве услед великог Дизајн напред приступа. Осим када је уговором потребно, водопад модел је углавном замењен флексибилнијом и развијенијом методологијом за развој софтвера. Погледајте критике водопад модела.

Водопад модел се такође често учи са мнемоником Плес у мраку сваког понедељка, представља анализу, дизајн, имплементацију, тестирање, документацију и извођење и одржавање.



                                     

3.2. Приступи Прототипови

Софтвер прототипа, је развојни приступ активности током развоја софтвера, креирање прототипа, односно непотпуне верзије софтвера се развијају.

Основни принципи су:

  • Несамосталана, комплетна методологија развоја, већ је приступ да издржи одабране делове веће, традиционално развојне методологије).
  • Покушаји да се смањи потенцијални ризик пројекта разбијањем пројекта на мање сегменте и пружање више једноставних промена током процеса развоја.
  • Корисник је укључен током развојног процеса, што повећава вероватноћу прихватања корисника коначне реализације.
  • Малог обима макете система су развијене итеративним процесом модификације све док прототип еволуира у сусрет захтевима корисника.
  • Док већина прототипова је развијено са очекивањем да ће бити одбачени, могуће је у неким случајевима да еволуира од прототипа на рад система.
  • Основно разумевање основног пословног проблема неопходно је да се избегне решавање проблема
                                     

3.3. Приступи Постепени развој

Различите методе су прихватљиве за комбиновање линеарних и итеративних методологија развоја система, са примарним циљем сваког да се смањи потенцијални ризик пројекта разбијањем пројекат на мање сегменте и пружање више једноставности током процеса развоја.

Основни принципи су

  • Укупни захтеви су дефинисани пре него што наставите да еволуирате, развој појединих корака мини-водопада у систему, или
  • Првобитни концепт софтвера, анализа захтева и дизајн архитектуре и система језгра су дефинисани преко водопада, а затим итеративном израдом прототипова, који кулминирају у инсталирању коначног прототипа, радног система.
  • Низ мини водопада се изводе, где су све фазе водопада завршене за мали део система, пре него што пређете на следећи прираст, или
                                     

3.4. Приступи Итеративни и постепени развој

Итератни развој прописује изградњу која је у почетку мала, али увек веће порције софтверског пројекта да се помогне свима онима који су укључени да открију важне теме рано пред проблемима или неисправне претпоставке које могу довести до катастрофе.

                                     

3.5. Приступи Спирални развој

Године 1988, Barry Boehm је објавио развој система софвера као "спирални модел", који комбинује неке кључне аспекет водопад модела и брзу израду прототипова методологије, у настојању да се комбинују предности од врха ка дну и одоздо према горе концепата. Она је дала нагласак у кључној области које су запостављене од стране других методологија: намерно итеративном ризичном анализом, посебно погодном за велики број комплексних система.

Основни принципи су:

  • Фокус је на процени ризика и смањењу ризика пројекта разбијањем пројекта на мање сегменте и пружање доста једноставне промене током процеса развоја, као и пружање прилике да оцене ризика вагају разматрање пројекта током животног циклуса.
  • "Сваки циклус укључује прогресију истом секвенцом корака, за сваки део производа и за сваки његов ниво израде, из укупног концепта-оф-операције документа доле на кодирање сваког индивидуалног програма."
  • Сваки пут око спирале прелази четири основна квадраната: 1 одређују циљеве, алтернативе, и ограничења у итерацији; 2 процењују алтернативе; идентификација и решавање ризика; 3 развој и верификација испоруке из итерације; и 4 планира следећу итерацију.
  • Почните сваки циклус са идентификацијом актера и њиховим "добитним условима", и на крају сваког циклуса са прегледима и посвећености.


                                     

3.6. Приступи Брзи развој апликација

Брз развој апликација РАД је методологија развоја софтвера, која фаворизује итеративни развој и брзу изградњу прототипова уместо велике количине уп-фронт планирања."Планирање" развоја софтвера користећи РАД је прошарано писање самог софтвера. Недостатак унапред планирања генерално омогућава софтверу да буде написан много брже, и олакшава да се промени захтеве.

Брз развој процеса почиње са развојем прелиминарних модела података и пословних процеса модела који користе структуриране технике. У наредној фази, захтеви се верификују помоћу прототипа, на крају да побољшају моделе података и процеса. Ове фазе се итеративно понављају; даљи развој резултата у "комбинованим пословним захтевима и техничкој дизајн изјави се користи за изградњу нових система".

Термин је први пут употребљен да опише процес за развој софтвера који је увео James Martin 1991. Према писању 2003, то је спајање различитих структурних техника, нарочито подаци Информатичког инжењеринга, са техникама за израду прототипова да убрзају развој софтверских система.

Основни принципи брзог развоја апликација су:

  • Кључни циљ је брз развој и испоруку високог система квалитета у релативно ниској цени инвестиција.
  • Покушаји да се смањи потенцијални ризик пројекта разбијањем пројекта на мање сегменте и пружање више једноставне промене током процеса развоја.
  • Кључни акценат је на испуњењу пословне потребе, док је технолошка или инжењеринг изврсност од мањег значаја.
  • Има за циљ да произведе висококвалитетне системе брзо, пре свега преко итеративних Прототипова у било којој фази развоја, активно учешће корисника, и компјутеризоване развојним алатима. Ови алати могу укључивати Графички кориснички интерфејс GUI builders, Computer Aided Software Engineering CASE tools, База података DBMS, Четврта генерација програмског језика, код генератори и технике објектно оријентисане
  • Контрола Пројекта укључује приоритете развоја и дефинисања рокова испоруке или "timeboxes". Ако се пројекат провуче, нагласак је на смањењу потреба да се уклопи у Тимебок, не у повећању рока.
  • Генерално подразумева заједнички дизајн апликација ЈАД, где корисници су интензивно укључени у дизајну система, преко консензуса у било структурним радионицама или електронски олакшаном интеракцијом.
  • Активно укључивање корисника је императив.
  • Стандардна анализа система и методе дизајна могу се уградити у овај оквир.
  • Производи документације неопходни да олакшају будући развој и одржавање
  • Итеративни производи за производњу софтвера
                                     

3.7. Приступи Агилни развој

"Агилни развој софтвера" се односи на групу софтверских методологија развоја заснованог на итеративном развоју, где захтеви и решења еволуирају преко сарадње самоорганизујућих крос-функционалних тимова. Термин је настао у 2001. години када је формулисан агилни развој софтвера.

Агилни развој софтвера користи итеративни развој као основу, али се залаже за упаљач и више људи имају оријентисано мишљење традиционалних приступа. Агилни процеси у основи укључе итерацију и континуирану повратну информацију да пружа сукцесивну прераду и да достави софтверски систем.

Постоје многе агилне методологије, укључујући:

  • Развој метода динамичког система DSDM
  • Канбан
  • Скрам
                                     

3.8. Приступи Код и поправка

"Код и поправка" развој није толико намерно стратегија, као резултат притиска на распореду програмера. Без много дизајна, програмери почињу одмах производњом кода. У једном тренутку, испитивање почиње често касно у развојном циклусу, а незаобилазни багови онда морају бити поправљени пре него што производ буде испоручен. Програмирање без планираног дизајна је такође познато као каубој кодирање.

                                     

3.9. Приступи Лагане методологије

Лагана методологија има мали број правила. Неке од ових метода се такође сматрају "агилном".

  • ICONIX - UML-заснован објекат моделирања са случајевима употребе, лагани увод у Rational Unified Process
  • Екстремно програмирање XP, промовисан од стране људи као што су Kent Beck и Martin Fowler. У екстремном програмирању, фазе се спроводе у изузетно малим или "континуираним" корацима у односу на старије "batch" процесе. Прво, један пише аутоматизоване тестове, да обезбеди конкретне циљеве за развој. Следеће је кодирање од стране програмера који раде у паровима, технику познату као "пар програмирања", које је завршено када сви тестови прођу, а програмери не могу да се сете више тестова који су потребни. Дизајн и архитектура излазе из рефакторисања, а долазе након кодирања. Исти људи који раде кодирање ураде и дизајн. Само последња опција - спајање дизајна и кода - је заједничко свим осталим агилним процесима. У овом тренутку, практиканти поново почињу писање тестова за наредни најбитнији део система.
  • Feature Driven Development FDD развијен 1999 ода стране Jeff De Luca и Peter Coad
  • Crystal Clear породица методологије са Alistair Cockburn,
  • Адапривни развој софтвера описао је Jim Highsmith, 1999., у својој књизи Adaptive Software Development


                                     

3.10. Приступи Друго

Остале методологије софтверско пројекта на високом нивоу су:

  • Chaos модел- Основно правило је увек прво реши најважнија питања.
  • Споро програмирање, као део ширег спорог кретања, наглашава пажљив и постепен рад без временског притиска. Споро програмирање има за циљ да се избегну грешке и сувише брзо ослобађање распореда.
  • Структурна анализа система и метода дизајна - посебна верзија водопада
  • Методологија постепеног финансирања - итеративни приступ
  • V-Модел Развој софтвера - продужетак водопад модела
  • Обједињени процес UP је понављање методологије за развој софтверског оквира, на основу Unified Modeling Language UML. UP организује развој софтвера у четири фазе, свака се састоји од једног или више извршних понављања софтвера у тој фази развоја почетак, израду, изградњу и смернице. Многи алати и производи постоје да би се олакшало UP имплементацију. Једна од популарнијих верзија UP је Rational Unified Process RUP.
                                     

4. Процес мета-модели

Неки "процес модели" су апстрактни описи за вредновање, упоређивање и побољшање специфичног процеса усвојеног од стране организације.

  • ISO/IEC 12207 је међународни стандард који описује начин да одаберете, имплементирате и пратите животни циклус за софтвер.
  • Capability Maturity Model Integration CMMI је један од водећих модела основу најбоље праксе. Независне процене граде организације о томе како добро да прате своје дефинисане процесе, а не на квалитет тих процеса или софтвера произведеног. CMMI је заменио CMM.
  • ISO 9000 описује стандарде за формално организован процес за производњу производа и методе управљања и праћења напретка. Иако је стандардни првобитно направљен за производни сектор, ISO 9000 стандарди су примењени у развоју софтвера као добро. Као CMMI, сертификација са ИSО 9000 не гарантује квалитет крајњег резултата, они су пратили формализоване пословне процесе.
  • ISO/IEC 15504 Информациона технологија - Процес процене такође познат као Процес могућности одређивања софтвера SPICE, је "оквир за процену софтверских процеса". Овај стандард има за циљ успостављање јасног модела за процес поређења. SPICE се користи слично као CMMI. Модели процеса за управљање, контролу, води и надгледа развој софтвера. Овај модел се затим користи за мерење шта развојна организација или пројектни тим заправо ради током развоја софтвера. Ове информације се анализирају да идентификују слабости и побољшање диска. Такође идентификује предности које може наставити или интегрисани у уобичајеној пракси те организације или тима.
  • Метод инжењеринга - општи метод за побољшање процеса информационог систем
  • Методологија софт система - општи метод за побољшање процеса управљања
                                     

5. Формалне методе

Формалне методе су математички приступи решавању софтверских и хардвера проблема у захтевима, ниво спецификација и дизајна. Формалне методе се највероватније примењују за безбедност критичног софтвера и система, као што је авионика софтвера. Стандардна безбедност софтвера, као што је DO-178B, DO-178C, и опште критеријумима захтевају формалне методе у највишим нивоима категоризације.

За секвенцијални софтвер, примери формалних метода укључују B-метод, језике који се користе у спецификацијама аутоматизованог доказивања теорема, RAISE, и Z запис.

Формализација развоја софтвера је ситна, на другим местима, уз примену Object Constraint Language и специјализације, као што је Java Modeling Language, а посебно са модела погон архитектуре дозвољава извршење пројеката, ако не и спецификације.

За истовремено софтвер и систем, Петри мреже, процес алгебре и коначне државне машине које су засноване на теорији аутомата - види виртуелни коначни аутомат дозвољавају извршавање софтвера спецификације и може да се користи да изгради и потврди апликацију понашања.

Други настојани тренд у развоју софтвера је да напише спецификацију у неком логичцном облику обично варијација првог реда логикеFOL -и онда да директно изврши логику као да је програм. Језик OWL, на основу Описне логике DL, је пример. То је рад на мапирању неке верзије енглеског или неки други природни језик аутоматски да и из логике, и извршавање логике буде директно. Примери су Attempto Controlled English и Интернет пословна логика, која не тражи да контролише вокабулар или синтаксу. Карактеристика система који подржавају двосмерно мапирање Енглеске-логике и директно извршење логике је да могу да објасне своје резултате, на енглеском језику, на послу или научном нивоу.

                                     

6. Види још

  • Софтверско инежењерство
  • Пројектни менаџмент
  • Софтверско инжењерство рачунара неки од ових алата подржава специфичне методологије
  • Иза линије софтверског инжењерства
  • Дебаговање
  • Процена напора развоја софтвера
  • Одржавање софтвера
  • Развој софтвера
  • Конструкција софтвера
  • Софтверски дизајн
  • Животни циклус софтверских издања
  • Анализа захтева
  • Филозофија развоја софтвера
  • Тестирање софтвера
  • Софтверско распоређивање
                                     

7. Спољашње везе

  • Gerhard Fischer, "The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design", 2001
  • Фазе развоја софтвера
  • Selecting a development approach at cms.hhs.gov.
                                     
  • Skram engl. scrum predstavlja agilni pristup za upravljanje razvojem softvera opšte prihvaćen u svetu. On se javlja polovinom 90 - tih godina prošlog veka
  • самог WYSIWYG - а. За разлику од процесора речи, табеле или презентације софтвера намерна средина има већу подршке за структуру и семантику намера да се
  • рачунара, софтвер је годинама писан асемблерским језиком. Виши програмски језици нису пронађени све док предности могућности поновног коришћења софтвера на разним
  • изразе написане на једном од језика за опис хардвера. HDL симулациони софтвер прошао је дуг пут развоја од свог порекла као појединачни производ који
  • уређаја испоручује у комбинацији софтвера отвореног кода и власничких лиценци, између осталог и власничког софтвера неопходног за приступ Гугл сервисима
  • uputstvo za PECL ekstenzije. Takode, nekoliko ekstenzija je počelo svoj ciklus razvijanja u PECL - u i završilo u jezgru distribuirani PHP iyvorni kod
  • не усвоје гусеница ће угинути, док ће се у супротном наставити њен развојни циклус Унутар мрављег гнезда, гусенице лептира се хране ларвама мрава и
  • pojedinačnih jedinjenja ili hemijskih struktura formiranih pomoću računarskog softvera Kombinatorna hemija se može koristiti za sintezu malih molekula i peptida
  • скали. GeneXus је унакрсно платформни, базиран на репрезентацији знања, развојни алат, који је углавном оријентисан на професионалну класу примена Веб апликација
  • Борланд, прво интегрисано развојно окружење ИДЕ за системе ЦП М и ДОС. Турбо Паскал обједињује све функције циклуса развоја софтвера у један целовит програм

Users also searched:

...
...
...