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

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

Шта је животни циклус развоја софтвера?

Животни циклус развоја софтвера (енгл. Software Development Life Cycle - SDLC) је низ фаза кроз које софтверски производ пролази од momenta дефинисања идеје и захтева, преко пројектовања, имплементације и тестирања, до пуштања у употребу и каснијег одржавања, све до тренутка када се производ повлачи из употребе.

Битно је направити разлику између фаза животног циклуса (које су, у основи, исте за скоро сваки софтверски пројекат) и модела животног циклуса (који описују на који начин, редоследом, се те фазе организују и изводе - на пример, да ли се изводе једном, линеарно, или се понављају кроз више циклуса). У овој лекцији фокус ће бити на основним фазама и на waterfall (каскадном) моделу, који је историјски први формализовао ове фазе. У наредној лекцији проширићемо причу и на остале моделе.

Основне фазе животног циклуса

Иако различити аутори и стандарди понекад користе нешто другачије називе или их додатно деле, готово сваки животни циклус софтвера садржи следеће фазе:

Анализа захтева (енгл. Requirements Analysis): Прикупљају се и дефинишу захтеви - шта производ треба да ради, ко ће га користити и под којим условима. Резултат ове фазе је обично документ спецификације захтева.
Пројектовање/дизајн (енгл. Design): На основу захтева осмишљава се архитектура система, структура база података, изглед корисничког интерфејса и начин на који ће компоненте система међусобно комуницирати.
Имплементација (енгл. Implementation): Фаза у којој се пише изворни код - овде "улазе у причу" програмери и претварају дизајн у стварни, функционалан софтвер.
Тестирање (енгл. Testing): Провера да ли софтвер ради у складу са дефинисаним захтевима и проналажење грешака пре него што производ стигне до корисника.
Испорука/пуштање у рад (енгл. Deployment): Софтвер се инсталира и поставља у окружење у коме ће га крајњи корисници стварно користити (продукционо окружење).
Одржавање (енгл. Maintenance): Пошто је производ пуштен у употребу, потребно је исправљати грешке које се накнадно открију, прилагођавати софтвер новим условима (нпр. новим верзијама оперативних система) и додавати нове функционалности.

Waterfall (каскадни) модел

Waterfall модел је најстарији и најједноставнији модел животног циклуса - фазе се изводе строго једна за другом, попут воде која се слива низ каскаду - откуда и потиче назив. Формализовао га је Winston Royce давне 1970. године, и он дуго времена представљао доминантан начин размишљања о развоју софтвера.

Која је кључна карактеристика waterfall модела?

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

Ток waterfall модела изгледа овако:

Анализа захтева
  → Пројектовање
    → Имплементација
      → Тестирање
        → Испорука
          → Одржавање

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

Предности waterfall модела

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

Мане waterfall модела

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

Када је waterfall модел добар избор?

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

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

Задатак

Замисли једноставан пројекат - израду веб сајта за локални ресторан (презентациони сајт са менијем, контакт подацима и формом за резервацију стола).

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