Софтверски процеси

Софтверскиот процес претставува структурирано множество од активности потребно да се развие софтверот.^[1] Иако постојат неколку модели на софтверски процеси, коишто се разликуваат во пристапот на развој на софтверот, тие ги имаат основните активности што се заеднички за сите процеси и тоа:

• спецификацијата;
• дизајнот
• валидацијата и
• еволуцијата на софтверот.

Многу битна задача во создавањето на софтверската програма е извлекувањето на барањата или анализа на барањата. Обично клиентите имаат апстрактна идеја за тоа што тие сакаат како краен резултат, а не за тоа што софтверот треба да прави. Искусните и вешти софтверски инженери се соочуваат со некомплетни, нејасни дури и некогаш и контрадикторни барања во оваа фаза. Понекогаш со демонстрирање на софтверска програма на корисникот може да биде корисно и да се намалат грешните барања. Откако барањата се извлечени од клиентот , тие се анализираат и се планира и одредува како ќе се одвива развојот. Пред да почне процесот на развивање на софтверот некои функционалности може да бидат исфрлени надвор од областа на проектот како резултат на трошоци или пак како резултат на недоволно јасно прецизирани барања.^[2]

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

Документирање за време на развојот на софтверот е потребно за понатамошно одржување и надградба. Овде може да биде вклучено и запишано Апликацискиот Програмски Интерфејс (АПИ), без разлика дали ќе биде надворешно или внатрешно. Во зависност од моделот на софтверскиот процес, кој е избран од софтверските инженери, ќе се одреди колкава документација е потребна. Моделите водени од планот (на пример Водопадниот модел) генерално произведуваат повеќе документација отколку прилагодливите методи.

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

Постојат неколку модели на софтверски процеси според кои се развива софтверот. Секој модел на софтверски процес си има свои предности и негативности, а кој модел ќе биде избран зависи од тимот кој е задолжен за развојот. Понекогаш може да има и комбинација од модели доколку се смета дека тоа најмногу би одговарало. Некои од моделите на софтверски процеси се:

• Водопаден модел
• Спирален модел
• Инкрементален модел
• Прилагодлив модел
• V – модел
• Рационално унифициран модел и други модели

Овој модел се појавува во 1970 година во една статија напишана од страна на Винстон Ројс (Winston W. Royce), меѓутоа таму не бил спомнат како Водопаден модел. Тој го презентирал моделот како премин од една фаза во друга и тоа личело како водопад.^[3] This, in fact, is how the term is generally used in writing about software development—to describe a critical view of a commonly used software practice.^[4]

Кај Водопадниот модел (англиски: Waterfall model) на софтверски процес , развивачите ги извршуваат следните фази редоследно:

1. Спецификација на барањата (Анализа на барањата) – Во оваа фаза се подготвува студија на изводливост, предвидување на трошоците
2. Софтверски дизајн
3. Конструкција (Имплементација или кодирање)
4. Тестирање (или Валидација)
5. Поставување (или Инсталација)
6. Одржување

Кај строг Водопаден модел, по завршување на секоја фаза се преминува на следна. На крајот од секоја фаза се прави документација. Со документацијата се дава до знаење дека фазата е целосно комплетна. Критериумот за завршување на фазата се нарекува и ,,порта‘‘ низ којшто фазите од проектот мора да поминат. Водопадниот модел не настојува на навраќање и ревизија на претходните комплетирани фази. Оваа ,,нефлексибилност‘‘ кај чистиот Водопаден модел е изложена на критики од страна на поддржувачите на ,,флексибилните‘‘ модели.^[5]

Овој модел е најстар и најмногу користен во развојот на софтверот. Има некои предности што го прават да биде најмногу користен. Тоа се:

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

• Враќањето во некоја претходна фаза е невозможно, доколку се направи грешка во почетните фази трошоците значително ќе бидат зголемени.
• Дополнителни барања од страна на клиентот може да направат големи проблеми.
• Сè додека и последната фаза не е завршена, софтверот клиентот не може да го разгледа софтверот и да провери дали е како тој што замислил.^[6]

Во 1988 од страна на Бари Боем бил објавен Спиралниот модел, којшто ги комбинирал некои клучни аспекти од Водопадниот модел и методите од брзото градење на прототип.^[7] Тој обично се користи за големи, скапи и комплицирани проекти. Секој круг на спиралата е поделен на четири делови и тоа:^[8]

1. Одредување на целите
2. Идентификација и справување со ризиците
3. Развој и тестирање
4. Планирање за следната итерација

Разликата од Водопадниот модел е тоа што Спиралниот модел фазите ги дели на многу парчиња на итеративни процеси и со тоа во голема мера се намалува ризикот.

• Лесно може да се управува со ризикот. Прво се завршуваат барањата од повисок приоритет, се прави прототип, се тестира и се прават потребните промени. Ова се прави во континуитет и на тој начин се минимизираат ризиците и неуспехот.
• Прилагодливиот дизајн на спиралниот модел им овозможува на софтверските инженери да прават различен број на промени, во било која фаза од проектот.
• Откако еден прототип ќе биде направен од помали делови, тогаш полесно е да се пресметаат останатите трошоци и клиентот на одреден начин ќе може да го тестира прототипот.
• Како што моделот се приближува кон завршната фаза, така и искуството на клиентот со системот станува сè поголемо и она што го барал клиентот од системот е во најголема мера исполнето.^[9]

• Најдобро работи само за големи проекти.
• Одговорните треба да имаат добри вештини за проценка на ризици и справување со нив.

Инкременталниот модел е произлезен од Водопадниот модел. Софтверскиот производ се дизајнира, имплементира, интегрира и тестира како серија од инкременти.^[10]

Кога овој модел се користи, првиот инкремент најчесто е јадрото, т.е. основата на производот. Овој инкремент се разгледува од страна на клиентот или поминува низ детален преглед. Како резултат на тоа се прави план за започнување со следниот инкремент. Планот ги содржи потребните модификации што треба да се направат, за да се задоволат потребите на клиентите и да се додадат нови функционалности и одлики на производот. Софтверот се гради чекор по чекор. Во текот на развојот на софтверот, во секој чекор се запишува што точно било направено.^[11]

• Флексибилен –Промена на опсегот и барањата нема да биде многу скапо
• Инкрементите на производот полесно се тестираат и дебагираат.
• При секој инкремент се идентификуваат ризиците и полесно се справува со нив.
• Го вклучува клиентот во развојот на производот.

• Проблеми можат да настанат со архитектурата на системот, затоа што некои барања може да зададат и подоцна.

Овој модел (англиски: Capability Maturity Model Integration (CMMI)) e приближување кое го подобрува процесот и негова цел е да им помогне на организациите да ги подобрат нивните перформанси. CMMI се користи како водач на подобрување на процесот во рамките на проектот или целокупната организација.^[12]

ISO 9000 овој стандард е дефиниран од страна на Интернационалата Организација за Стандардизација (англиски: International Organization for Standardization) и ги опишува стандардите кои се поврзани со управувањето на квалитет и им овозможува на организациите да бидат сигурни дека она што го работат ќе биде квалитетен производ.^[13] Иако овие стандарди се применуваат во сите индустрии кај што има производство, овој стандард се користи и во развојот на софтверот.