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

Од Википедија — слободната енциклопедија
Прејди на прегледникот Прејди на пребарувањето

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

Активности за развивање на софтверот[уреди | уреди извор]

Планирање[уреди | уреди извор]

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

Имплементација, тестирање и документирање[уреди | уреди извор]

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

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

Испорачување и одржување[уреди | уреди извор]

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

Модели на софтверски процеси[уреди | уреди извор]

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

Водопаден модел[уреди | уреди извор]

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

Овој модел се појавува во 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]

Спирален модел[уреди | уреди извор]

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

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

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

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

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

Инкрементален модел[уреди | уреди извор]

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

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

Предности на Инкременталниот модел[уреди | уреди извор]

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

Негативности на Инкременталниот модел[уреди | уреди извор]

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

Модели кои го подобруваат процесот[уреди | уреди извор]

Интеграција на моделот на способност и зрелост[уреди | уреди извор]

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

ISO 9000[уреди | уреди извор]

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

Наводи[уреди | уреди извор]

  1. Sommerville, Ian (2007) [1982]. Software Engineering (изд. 8th.). 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
  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 проверена на 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 проверена на 01.04.2012
  10. Incremental lifecycle model проверена на 01.04.2012
  11. Incremental Model проверена на 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.