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

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

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

 Активности за развивање на софтверот 
 Планирање 
Многу битна задача во создавањето на софтверската програма е извлекувањето на барањата или анализа на барањата. Обично клиентите имаат апстрактна идеја за тоа што тие сакаат како краен резултат, а не за тоа што софтверот треба да прави. Искусните и вешти софтверски инженери се соочуваат со некомплетни, нејасни дури и некогаш и контрадикторни барања во оваа фаза. Понекогаш со демонстрирање на софтверска програма на корисникот може да биде корисно и да се намалат грешните барања. Откако барањата се извлечени од клиентот , тие се анализираат и се планира и одредува како ќе се одвива развојот. Пред да почне процесот на развивање на софтверот некои функционалности може да бидат исфрлени надвор од областа на проектот како резултат на трошоци или пак како резултат на недоволно јасно прецизирани барања.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

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

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

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

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

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

 Водопаден модел 
310 px|десно|Водопаден модел
Овој модел се појавува во 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.Conrad Weisert, Waterfall methodology: there's no such thing!

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

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

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

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

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

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

 Спирален модел 
310 px|десно|Спирален модел (Boehm, 1988)

Во 1988 од страна на Бари Боем бил објавен Спиралниот модел, којшто ги комбинирал некои клучни аспекти од Водопадниот модел и методите од брзото градење на прототип.Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986
Тој обично се користи за големи, скапи и комплицирани проекти.
Секој круг на спиралата е поделен на четири делови и тоа:NASA (2004). NASA Software Safety Guidebook. NASA-GB-8719.13, March 31, 2004. p.56-57
 Одредување на целите 
 Идентификација и справување со ризиците
 Развој и тестирање
 Планирање за следната итерација

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

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

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

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

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

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

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

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

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

 Наводи