ПАНЕВРОПСКИ УНИВЕРЗИТЕТ АПЕИРОН

ФАКУЛТЕТ ПОСЛОВНЕ ИНФОРМАТИКЕ

Ванредне студијеСмјер „НАСТАВНИЧКА ИНФОРМТИКА”

Предмет

СОФТВЕРСКО ИНЖЕЊЕРСТВО

„МОДЕЛОВАЊЕ СОФТВЕРСКОГ ПРОЦЕСА И ЖИВОТНОГ ЦИКЛУСА”

(семинарски рад)

Предметни наставник:Проф. др Зоран Ж. Аврамовић, дипл.инж.елек.

Кандидат:Саша Благојевић 83/11

САДРЖАЈ

1.Увод................................................................................................................................... 2. Значење термина процес................................................................................................3. Модели процеса израде софтвера .................................................................................4. Најчешћи модели развоја софтвера ...............................................................................

4.1. Модел водопада............................................................................................................ 4.2. Модел еволуцијског развоја..........................................................................................4.3. Модел усмјерен на поновну употребу.......................................................................... 4.4. Модел V....................................................................................................................4.5. Фазни развој............................................................................................................ 4.6. Инкрементални модел............................................................................................ 4.7. Модел прототипског развоја .................................................................................4.8. Модел спецификације рада ...........................................................................................4.9. Трансформациони модел................................................................................................ 4.10. Спирални модел....................................................................................................

4.11. Модел заснован на компонентама...................................................................... 4.12. Модел унифицираног процеса развоја..............................................................

4.13. Агилни модели развоја.........................................................................................4.14. Комбиновани модели...........................................................................................4.15. Extreme programming (XP)....................................................................................5.Закључак......................................................................................................................

Литература..................................................................................................................

1

24577

11121314151618191922222325262829

1.УВОД

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

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

Друштво информатичара Њемачке спровело је прије неколико година, међу млађим експерима у информатици, истраживање у којем су они наводили које дисциплине са студија (које су имали или би требало да су имали) сматрају најважнијим за свој стручни рад. Добијени су сљедећи резултати, дати у облику ранг-листе, при чему виши ранг означава и већу значајност:1. тимски рад,2. управљање пројектима,3. софтверски инжењеринг,4. вођење тима,5. базе података,6. реторика,7. комуникациони системи и мреже,8. систем квалитета,9. структуре података и алгоритми,10. оперативни системи,

2

11. ергономија софтвера,12. управљање пословањем,13. основи алгоритама,14. основи математике и логике,15. дистрибуирани системи,16. методе научног истраживања,17. безбедност података,18. информациони системи,19. концепти програмских језика и20. архитектура рачунара.

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

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

3

2. ЗНАЧЕЊЕ ТЕРМИНА ПРОЦЕС

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

Сваки процес посједује сљедеће карактеристике:

Процес прописује све главне активности

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

Процес може да се састоји од међусобно повезаних подпроцеса.

Активности су организоване у секвенце, тако да је јасно када се једна активност изводи у односу на друге

Сваки процес посједује скуп упутстава која објашњавају циљеве сваке активности

Ограничења или контроле могу да се примјене на активност, ресурсе или производ.

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

Развој софтвера обично обухвата сљедеће фазе:

Анализу и дефинисање захтјева,

Пројектовање систстема,

Пројектовање програма,

Писање програма,

Јединично тестирање,

Тестирање интегрисаног рјешења,

Тестирање система,

Испорка система и

Одржавање.

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

3.МОДЕЛИ ПРОЦЕСА ИЗРАДЕ СОФТВЕРА

4

Софтверски производ (апликација) створен по принципима софтверског инжењерства може бити развијен као:

Генерички производ (флексибилан, слободно обликован, развијен од произвођача софтвера,понуђен на тржишту било којем купцу),

Наручени производ (израђен према договореним захтјевима, строго детерминиран, намењен и испоручен конкретном одређеном купцу).

Темељни циљ софтверског инжењерства огледа се у тежњи да се створи високо квалитетан софтверски производ у договореном року и уз што мање трошкове. У складу с изреченим циљем могуће је препознати три кључне категорије у процесу развоја софтверског производа :

1. Испорука софтвера у договореном року,2. Трошкови развоја софтвера у договореним оквирима,3. Задовољавајући квалитет софтвера.

За развој софтвера карактеристичне су одређене темељне активности:

Спецификација потреба (идентификација, трансформација потреба у захтјеве, анализа, одређивање приоритета …)

Дизајнирање проблема (обликовање проблема графичком нотацијом, обликовање процеса, анализа …)

Имплементација (кодирање, тестирање, увођење у рад, документирање, едукација …) Валидација (тестирање софтверског система, процјена квалитета …) Еволуција (одржавање система, реинжењеринг …)

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

Модел развоја се одабира у зависности од природе пројекта и апликације, техничке оријентације људи који ће учествовати у развоју, метода и алата који ће се употребљавати при развоју, начина контроле и самих производа који се захтјевају.

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

5

Основни принципи начина извршења рада су: принцип моделовања, принцип итерација, принцип симулације, принцип документовања.

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

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

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

Модел може представљати: модел процеса развоја, модел софтвера или модел начина управљања софтвером.

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

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

Прескриптивни модели развоја – конвенционални модели са дјелимично различитим током процеса развоја али са истим генеричким активностима;Модел водопада,

Инкрементални модели развоја: Инкрементални модел,

РАД модел, Развојни модели:

Модел прототипског развоја,Спирални модел,Истовремени модел развоја (Concurrent Development)

Специјализовани модели:Модел заснован на компонентама,Модел заснован на формалним методама,Модел унифицираног процеса развоја (Unified Process)

Модели агилног развоја:Extreme Programming (XP)

6

Adaptive Software Development (ASD)Dynamic Systems Development Method (DSDM)ScrumFeature Driven Development (FDD)Agile Modeling (AM)

4. НАЈЧЕШЋИ МОДЕЛИ РАЗВОЈА СОФТВЕРА

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

Модел треба да одражава циљеве развоја:

израда софтвера високог нивоа квалитета откривање грешака у раним фазама развоја

остајање у оквирима буџета и формулисаних ограничења везаних за рокове завршетка

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

4.1. Модел водопада

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

Фазе и активности развоја према овом моделу су сљедеће:

7

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

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

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

Кодирање – Овом фазом се извршава задатак превођења резултата пројектовања у машински препознатљиву форму. Уколико је пројектовање урађено довољно детаљно, тада се кодирање обавља механички.

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

Одржавање - Софтвер ће сигурно претрпјети одређене измјене након што се дистрибуира кориснику.

8

Илустрација 1. Моgел воgопаgа

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

9

Примјена овог модела се предлаже у сљедећим ситуацијама: приликом развоја софтвера који је по основним карактеристикама јединствен и има

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

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

постоји довољно времена и стрпљења код корисника за дуги период развоја и када високи развојни трошкови и потребна финансијска средства нису

ограничавајући фактор развоја.

Слабост модела је недостатак повратне спреге између корака који нису сукцесивни и не одвијају се у секвенцијалном редосљеду. Такође, као недостаци се наводе сљедеће чињенице:

реални пројекти веома ријетко прате моделом дефинисани секвенцијални ток, а итерације увијек изазивају или се код њих јављају проблеми у примјени модела,

увијек је тешко за корисника да у почетку рада на развоју софтвера наведе експлицитно све своје захтјеве (а што модел захтјева), јер се тешко прилагођава неизвјесности која углавном егзистира на старту,

купац мора бити веома стрпљив и истрајан, јер ће му радне верзије програма бити доступне тек на крају активности развоја софтвера,

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

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

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

10

На слици је приказан реални процес развоја софтвера:

Илустрација 2. Реални процес развоја софвера

4.2.Модел еволуцијског развоја

Модел еволуцијског развоја (енглески evolutionary development) настао је као противтежа моделу водопада. На основу приближног описа проблема развија се полазна верзија система која се показује кориснику. На основу корисникових примједби, та полазна верзија се побољшава, опет показује, итд. Након довољног броја итерација добива се коначна верзија система. Унутар сваке итерације, основне активности се обављају симултано и не дају се раздвојити.

11

Илустрација 3.Моgел еволуцијског развоја

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

Предности модела еволуцијског развоја су сљедеће:

• Модел је у стању произвести брзи одговор на захтјеве корисника.• Постоји могућност да се спецификација постепено развија у складу са све бољим корисниковим разумијевањем проблема.

Мане модела еволуцијског развоја су сљедеће.

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

Модел се успјешно користи за развој web сједишта, те за мале системе с кратким животним вијеком, поготово за системе с нејасним захтјевима.

4.3. Модел усмјерен на поновну употребу

Модел усмјерен на поновну употребу (енглески reuse-oriented development) полази од претпоставке да већ постоје готове и употребљиве софтверске цјелине, као што су COTS системи (енглески Commercial Off-The-Shelf Systems) или дијелови прије развијених система. Нови систем настоји се у што већој мјери реализовати спајањем постојећих

12

дијелова. Иста идеја присутна је и у другим техничким дисциплинама: нови механички или електронички производ настоји се склопити од стандардних дијелова (вијака, чипова, . . . ).

Илустрација 4.Моgел усмјерен на поновну употребу

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

Мане модела усмјереног на поновну употребу су сљедеће.• Због компромиса у спецификацији могуће је да систем неће у потпуности одговорити стварним потребама корисника..• Дјеломично је изгубљена контрола над еволуцијом система, будући да не управљамо развојем нових верзија кориштених дијелова.

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

4.4. Модел V

V модел (њемачко Министарство одбране, 1992.) је модификовани каскадни модел који показује однос тестирања и фаза анализе и пројектовања, чинећи експлицитним неке повратне спреге које су скривене у каскадном моделу.V модел се првенствено бави активностима и исправним радом система, за разлику од каскадног модела који је усредсређен на документе и међупроизводе.

13

Илустрација 5. V модел процеса

V модел се користи на следећи начин: Тестирање дијелова, тестирање система при интеграцији и тестирање система баве се

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

имплементирани. Ако се пронађу проблеми током верификације или валидације, активности са лијеве

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

4.5. Фазни развој

Фазни развој је начин пројектовања софтвера који омогућава испоручивање система у дијеловима, тако да је корисницима на располагању један део функција, док је остатак функција још у развоју. Зато обично постоје два система који упоредо функционишу: продукциони и развојни систем.

14

Продукциони систем је онај који тренутно користе наручилац и корисник. Развојни систем представља сљедећу верзију која се припрема да замјени постојећи продукциони систем. Системи се обично називају према редном броју њихове верзије. Тако, пројектни тим увијек ради на верзији n+1, док је верзија n у фази оперативног коришћења.

Илустрација 6. Фазни развој

4.6. Инкрементални модел

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

Илустрација 7. Инкрементација

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

15

Илустрација 8. Итерација

Пројектовање софтвера се изводи у првом кораку, али се увођење софтвера одвија сукцесивном разрадом (усавршавањем иницијалног подскупа). Софтвер се развија малим додацима (инкрементима) којима се може једноставно и лако управљати. Сваки инкремент додаје постојећем софтверу поједине нове функције, при чему се постојеће задржавају.Инкрементални развој подразумијева да се систем у складу са спецификацијом захтјева дијели на подсистеме према функцијама. Верзије се дефинишу као функционални подсистеми, тако да се свакој новој верзији прикључују нове функције. Систем се надограђује до потпуне функционалности.

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

4.7. Модел прототипског развоја

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

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

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

16

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

ISPORUČENI SISTEMИлустрација 9. Моgел прототипског развоја

Модел прототипског развоја се најчешће употребљава и даје солидне резултате уситуацијама:

када су од стране корисника само уопштено дефинисани циљеви развоја софтверског производа, али не и детаљи у погледу улаза, процедура и излаза,

када је могуће симулирати рад софтвера да би корисник могао видјети како ће будући софтверски производ функционисати и

када саме развојне организације желе провјерити ефикасност алгоритама или адаптибилност система.

Модел уобичајено може имати три облика: прототип у облику папира који описује везу човјека и машине на начин да кориснику

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

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

17

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

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

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

Неадекватан оперативни систем или програмски језик се једноставно употребљавају само зато што су расположиви или познати; неефикасан алгоритам се примјењује само да би се демонстрирала способност софтвера.

Након извјесног времена, заборавља се на начин одабира и њихове узроке, па мање идеална решења или боље речено мање квалитетна решења остају интегрални дио коначног софтверског рјешења.Због тога, значајно је да се пројектант и корисник, у циљу ефикасности овог модела, договоре и дефинишу „правила игре“ на почетку процеса развоја софтвера. Другим рјечима они се морају сложити да се прототип развија као механизам за дефинисање захтјева, а софтвер се развија у циљу задовољења критеријума квалитета и могућности одржавања.

4.8. Модел спецификације рада

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

Илустрација 10. Модел спецификације рада

18

4.9. Трасформациони модел

Трансформациони модел покушава да редукује могућност грешке примјеном низа трансформација којима се спецификација захтјева претвара у систем који може да се испоручи. Секвенце трансформација и одлука се чувају као формални запис у оквиру дизајна.

Трансформациони модел веома много обећава. Главна сметња да буде шире прихваћен је неопходност формалне спецификације да би трансформације могле над њом да се извршавају.

Илустрација 11. Трасформациони модел

4.10. Спирални модел

Спирални модел је развијен од. Б Боехма 1988. године, да би се објединиле добреособине модела водопада и модела прототипског развоја уз истовремено укључивањеактивности анализе ризика.

Модел се представља спиралом на којој су дефинисане четири фазе развоја:1) планирање – фаза коју чине активности одређивања циљева, алтернатива и

ограничења,2) анализа ризика – фаза коју чине активности анализе алтернатива и идентификовања

ризика,3) инжењеринг – фаза развоја нових нивоа производа и4) развој и оцењивање – фаза процјене резултата инжењеринга.

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

19

Илустрација 12. Спирални модел

Након што се донесе одлука о даљем развоју, обавља се инжињеринг у сваком циклусу спирале и то одабраним моделом развоја софтвера (модел водопада и-или модел прототипског развоја). Број активности у инжењерингу расте, уколико се циклуси удаљују од центра спирале. Истовремено, активности су сложеније и увијек са много мање апстракције.

20

Илустрација 13. Спирални модел 4 итерације

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

Типична расподијела времена, за која ипак треба рећи да варирају од циклуса до циклуса, је: планирање и дизајн 20%, процјена ризика 5%, реализација (са тестирањем) 40%, ревизија 15% и оцјењивање 20%.

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

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

21

4.11. Модел заснован на компонентама

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

Вишеструко коришћење софтвера је процес укључивања у нови производ појединихкомпоненти:

претходно тестираног кода, претходно провереног дизајна, претнодно развијене и коришћене спецификације захтјева и пријетходно коришћених процедура за тестирање.

Користи које собом доноси поновно коришћење компоненти развијеног софтвера су сљедеће:

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

4.12. Модел унифицираног процеса развоја

За разлику од претходно описаних модела развоја софтвера, Ivar Jacobson, Grady Booch и James Rumbaugh су 1999. године објавили USDP – модел унифицираног процеса развоја софтвера. Овај модел описује процес развоја коришћењем UML – обједињеног језика за моделовање у објектно-оријентисаном развоју софтвера.Овај модел се заснива на 3 основна принципа - основу чине дијаграми случајева коришћења, у центру модела се налази његова архитектура која сазрева са развојем нових дијаграма корисника и развија се кроз итерације које доносе нове инкременте коначног производа. Суштински посматрано, у свакој од итерација одвијају се анализа, пројектовање, имплементација и тестирање производа.

22

Према ауторима, модел се може описати као процес класифицирања итерација, које се могу подјелити у 4 групе:

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

2) другу групу сачињавају разрађене итерације жеља и потреба корисника,3) итерације конструисања иницијалних операционих могућности сачињавају трећу

групу и4) прелазне итерације комплетирања производа су четврта, коначна итерација развоја

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

Илустрација 13. Модел унифицираног процеса

4.13. Агилни модели развоја

Агилне методе (Agile Alliance, 2001.) су настале као отпор многим ранијим моделима развојног процеса који су покушавали да наметну неки облик дисциплине везане за осмишљавање софтвера, документовање, развој и тестирање. Идеја је да се нагласи улога флексибилности у спретном брзом развоју софтвера.Честа кашњења пројеката развоја софтвера, пробијање буџета и постављених временских рокова у њиховој реализацији, перманентни раст сложености технологије и учестале промјене корисничких захтјева, довели су крајем двадесетог вијека до појаве нових модела развоја. Настали су агилни модели, по особинама много гипкији и прилагодљивији промјенама, који омогућују корисницима активно учешће током свих фаза и активности

23

развоја. Агилни приступ се дакле суочио са основним проблемом савременог и уједно брзог развоја софтвера.

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

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

Илустрација 15. 4 принципа агилног развоја

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

24

Илустрација 16. Модел агилног развоја софтвера

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

4.14. Комбиновани модели

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

25

Илустрација 17. Комбиновани модел

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

4.15. Extreme programming (XP)

Екстремно програмирање, XP (eXtreme Programming), (Beck, 1999.) представља скуп техника за омогућавање креативности пројектног тима уз минимизовање прекомерног администрирања.

Заснована је на једноставности, комуникацији, feedbacku и храбрости. Тимови користе једноставну форму планирања и праћења како би одлучили шта

сљедеће да раде. Тимови креирају софтвер у серији малих, потпуно интегрисаних издања која су

прошла све тестове које је корисник дефинисао.

Фазе које прате Екстремно програмирање су:1) Планирање

Идентификују се кориснички Захтјеви.Планирањем верзија креира се распоред верзија.Често се праве мала издања.Пројект је подјељен уитерације.Планирање итерације започиње сваку итерацију.

2) Управљање26

Даје тиму локални отворени радни простор.Одређује одржив корак.Сваки дан започиње почетним састанком.Прати се брзина пројекта.Људи се размјештају.Поправљасе XP када дође до проблема.

3) ДизајнирањеЈедноставност.Коришћење CRC картицаза дизајн сесија.Креирање клинастих решењада би се смањио ризик.Функционалности се не додају у раним фазама.Поновно планирање када год и гдје год је потребно.

4) КодирањеКорисник је увијек доступан.Код се мора писати тако да буде у складу са стандардима.Кодира се тест јединице прво.Сав продуктивни код је програмиран у пару.Само један пар интегрише код у једном тренутку.Честе интеграције.Одређен је рачунар за интеграцијуПостоји колективно власништво.

5) ТестирањеСав код мора имати тестове јединица.Сав код мора проћи све тестове јединица прије него што се може ставити у употребу.Када се пронађе баг креирају се тестови.Тестови прихватљивости се често извршавају, а резултати се објављују.

Илустрација 18. Екстремно програмирање

27

5. ЗАКЉУЧАК

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

Циљ овог семинарског рада је био да наведем и опишем доста различитих модела развоја софтвера.

Модел развоја се одабира у зависности од природе пројекта и апликације, техничке оријентације људи који ће учествовати у развоју, метода и алата који ће се употребљавати при развоју, начина контроле и самих производа који се захтјевају.

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

28

Литература

1.SWing - S.L.Pfleeger i J.M.Atlee – Софтверско инжењерство теорија и пракса

2.Драгица Радосав, Софтверско инжењерство,технички факулетет „Михајло Пупин”,

Зрењанин 2008.

3. Hartmann, Ђорђевић, Гоцић, Увод у објектно оријентисано моделирање (Софтверски инжењеринг).

4. Увод у обједињени језик моделирања, Мр.Ивана Станојевић, Др.Душан Сурла, ПМФ Нови Сад.5. http://www.link-elearning.com

29