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

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

Активности за развивање на софтверот
------------------------------------

### Планирање

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

### Имплементација, тестирање и документирање

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

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

### Испорачување и одржување

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

Модели на софтверски процеси
----------------------------

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

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

Водопаден модел
---------------

Водопаден моделВодопаден модел
Овој модел се појавува во 1970 година во една статија напишана од страна на Винстон Ројс (Winston W. Royce), меѓутоа таму не бил спомнат како Водопаден модел. Тој го презентирал моделот како премин од една фаза во друга и тоа личело како водопад. 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.

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

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

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

##### Предности на Водопадниот модел

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

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

##### Негативности на Водопадниот модел

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

Спирален модел
--------------

Спирален модел (Boehm, 1988)Спирален модел (Boehm, 1988)
Во 1988 од страна на Бари Боем бил објавен Спиралниот модел, којшто ги комбинирал некои клучни аспекти од Водопадниот модел и методите од брзото градење на прототип.
Тој обично се користи за големи, скапи и комплицирани проекти.
Секој круг на спиралата е поделен на четири делови и тоа:

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

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

##### Предности на Спиралниот модел

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

##### Негативности на Спиралниот модел

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

### Инкрементален модел

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

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

#### Предности на Инкременталниот модел

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

#### Негативности на Инкременталниот модел

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

### Модели кои го подобруваат процесот

### Интеграција на моделот на способност и зрелост

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

### ISO 9000

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

Наводи
------

1. ↑  Sommerville, Ian (2007) [1982]. *Software Engineering* (8. изд.). Harlow, England: Pearson Education. ISBN 0-321-31379-8. Text "page 7" ignored (help)
2. ↑  Ralph, P. and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K. Loucopoulos, P. Mylopoulos, J. and Robinson, W. (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136
3. ↑  Royce, Winston (1970), „Managing the Development of Large Software Systems" (PDF), *Proceedings of IEEE WESCON*, **26** (August): 1–9, Архивирано од изворникот (PDF) на 2016-03-15, Посетено на 2012-04-01
4. ↑  Conrad Weisert, Waterfall methodology: there's no such thing!
5. ↑  Wikipedia: Software Engineering model - Waterfall model проверена на 01.04.2012
6. ↑  Waterfall Model Advantages and Disadvantages Архивирано на 7 февруари 2012 г. проверена на 01.04.2012
7. ↑  Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986
8. ↑  NASA (2004). *NASA Software Safety Guidebook*. NASA-GB-8719.13, March 31, 2004. p.56-57
9. ↑  Spiral Model Advantages and Disadvantages Архивирано на 8 февруари 2012 г. проверена на 01.04.2012
10. ↑  Incremental lifecycle model проверена на 01.04.2012
11. ↑  Incremental Model Архивирано на 19 април 2012 г. проверена на 01.04.2012
12. ↑  Capability Maturity Model Integration (CMMI) проверена на 01.04.2012
13. ↑  Poksinska, Bozena; Dahlgaard, Jens Jörn; Antoni, Marc (2002). „The state of ISO 9000 certification: A study of Swedish organizations". *The TQM Magazine*. **14** (5): 297. doi:10.1108/09544780210439734.