Софтуерно инженерство

Еърбъс А380 използва значително количество софтуер, за да не се използва хартия за пилотското място.

Софтуерното инженерство (на английски: Software engineering) е проектирането, прилагането и видоизменянето на софтуер с цел неговото високо качество, приемлива цена, поддръжка и бързо разработване. Това е „систематичен подход към анализа, проектирането, оценяването, прилагането, тестването, поддръжката и повторната разработка на софтуер, или с други думи приложение на инженерната наука към софтуера.“^[1]

Разработка на софтуер

Софтуерен разработчик на работа

Разработката на софтуер (среща се и като разработка на приложения, софтуерен дизайн, проектиране на софтуер, разработване на приложен софтуер) е разработването на софтуерен продукт съобразен с нуждите на дадена целева група или маркетинга на един софтуерен продукт. Терминът „разработка на софтуер“ може да се използва, за да опише компютърното програмиране, което е процес на писане и поддържане на сорс код, но в по-широк смисъл на понятието се включва всичко – от концепцията на желания софтуер до крайната проява на софтуера, което в идеалния случай е планиран и структуриран процес.^[2][3] Следователно, разработката на софтуер може да включва изследвания, нови разработки, прототипиране, модификация, повторно използване, ре-инженеринг, поддръжка, или всякакви други дейности, чийто краен резултат е софтуерният продукт.

Основни задачи

Планиране

Планирането е част от всеки проект. В процеса на планиране се откриват конкретни задачи свързани със самия проект.

Важна част от създаването на софтуерна програма е извличане на изискванията или техния анализ.^[4] Клиентите най-често имат абстрактно виждане какво искат като краен резултат и нямат идея какво софтуерния продукт трябва да прави. Опитните софтуерни инженери разпознават непълните, прекалено амбициозни или често противоречиви изисквания още във фазата на планиране. Честото тестване и изпробване на продуктите в процеса на разработка намалява риска от внедряване на ненужни изисквания.

След като основните изисквания са събрани от клиента, започва техния по-задълбочен анализ. Определя се обхвата на разработения продукт като се поставят конкретни задачи на проекта и се изработва съответната документация.

Някои функционалности могат да останат извън обхвата на проекта като впоследствие могат да го оскъпят. Най-честа причина е неяснота по отношение на изискванията и приложението в самото начало на разработване. Ако друга компания извършва разработването и планирането, този документ може да се счита за правен документ и е част от договорните отношения. В случай на възникване на спорове и двусмислено тълкуване – какво е обещано на клиента и какво е получено като продукт, документацията по разработване на проекта може да се приложи за изясняване и разрешаване на спорни моменти.

Архитектура, имплементация, тестване и документация

Софтуерна архитектура представлява процеса за изработка на архитектурата на софтуера, при което се избират технологиите които ще се използват, стандарт за писане на код, инструменти и платформа. Разделят се сложните задачи на по-прости и лесни за изпълнение. Разделяне на компоненти и описание на тяхната функционалност.

Имплементацията е част от процеса, при който софтуерните инженери пишат програмния код за проекта на база вече създадената архитектура.

Софтуерното тестване е процес на изследване и проучване на софтуера, с цел получаване на информация за качеството на продукта и услугата, която се изпитва. Процесите на софтуерното тестване са неразделна част от софтуерното разработване и осигуряване на качеството на софтуера.

Документацията описва начина на работа на програмата, така че тя да може да бъде използвана от крайните потребители. Без ясна документация софтуерът трудно може да бъде използван, особено когато става дума за силно специализирани и сравнително сложни продукти, като Photoshop или AutoCAD.

Често софтуерът включва и техническа документация, предназначена за използване от разработчиците. Тя може да бъде във вид на коментари в самия изходен код или обособена в отделни файлове. Предназначението на тази документация е да улесни бъдещата поддръжка и промяна на софтуера.

Внедряване и поддръжка

Внедряването започва веднага след като кода мине през подходящо тестване, одобрен е за пускане на пазара, продаден или е пласиран по друг начин. Това може да включва инсталиране на съответен брой машини, настройка на продукта към конкретните изисквания на клиента, тестване и при необходимост удължаване на периода на оценяване.

Обучението за работа със софтуера и техническата поддръжка е изключително важно, тъй като ефективността му зависи от познанията на обикновения потребител.

Отстраняване на дефектите и подобряването на софтуера при възникнали проблеми може да отнеме значително време и усилия, а пропуснатите изисквания могат да принудят цялостна пренастройка на софтуера.

Етапи от разработката на софтуер

Анализ на изискванията в системното инженерство и софтуерното инженерство, обхваща онези задачи, които определят потребностите или условията отговарящи за нови или изменени продукти, като се вземат предвид възможните противоречащи си изисквания на различни заинтересовани страни, анализиране, документиране, валидиране и управление на софтуера или системните изисквания.^[5] Анализа на изискванията е от решаващо значение за успеха на системите или софтуерните проекти.^[6] Изискванията трябва да бъдат документирани, обжалвани, измерими, проверими, проследими, свързани с определени бизнес потребности или възможности, и да определя ниво на детайлност, достатъчно за проектирането на системата.

Спецификация на изискванията (SRS) представлява пълно описание за поведението на една система, която ще бъде развивана, и да включва набор от използвани случаи описващи взаимодействията, които потребителите ще имат със софтуера. Спецификация на изискванията съдържа ѝ нефункционални изисквания, които налагат ограничения по отношение на дизайна или имплементацията (като например изисквания за ефективност, стандарти за качество или ограничения по проекта).

Документът отнасящ се за спецификация на софтуерните изисквания събира всички необходими изисквания, които са важни за развитието на проекта. За получаване на изискванията е нужно ясно и задълбочено познание за продуктите, които ще се развиват. Това се получава след подробна комуникация между екипа на проекта и клиента.

Софтуерната архитектура определя високите структури в нивото на една софтуерна система и предоставя един по-обобщен поглед върху даден проект. Тази архитектура може да се определи и като множество от структури, които обхващат софтуерните елементи, отношенията между тях и техните свойства.

Софтуерната архитектура означава и система от практики за подбор, определяне и проектиране на една софтуерна структура.

Също така термина софтуерна архитектура може да се разглежда като документация на софтуерната система. Документирането улеснява комуникацията между заинтересованите страни в проекта, очертава основните насоки на последващия дизайн и позволява повторна употреба на компонентите в други проекти.

Софтуерният дизайн е процес, чрез който се създава софтуерен продукт с определена цел с помощта на набор от основни компоненти и подлежащи ограничения. Към този дизайн се отнасят и всички дейности, включващи концепцията, изготвянето, прилагането, въвеждането в експлоатация и последващата промяна на цялата система.

Софтуерният дизайн обикновено включва разрешаването на проблеми и планиране на софтуерното решение. Това обхваща както алгоритмичния дизайн на ниско равнище така и софтуерната архитектура на високо ниво.

Писането на програмен код започва, когато дизайна приключи и важните решения относно софтуерната система са направени. Целта на фазата на писането на код е да се преведе дизайна на системата използвайки кода на някой от езиците за програмиране. Винаги се търси най-добрия начин за това представяне, защото се влияе директно на фазите за тестване и поддръжка. Добре написаният код намалява усилията при тестването и поддръжката.

За ефективно оползотворяване на времето работата се разделя на модули/части, които се задават като под-задачи на отделните софтуерни разработчици според техните умения.

Тази фаза отнема най-много време спрямо останалите.

Софтуерното тестване е процес на изследване и проучване на софтуера, с цел получаване на информация за качеството на продукта и услугата, която се изпитва. То може също да предостави обективна и независима гледна точка върху софтуера и да позволи на компаниите да оценят риска от вграждането на този софтуер.

Техниките за тестване включват, но не се изчерпват с, процеса по изпълнение на програмите и приложенията, за да се намерят евентуално грешки или други дефекти в тях. Важно е да се установи дали написания софтуер реално удовлетворява зададените при дизайна параметри. Тестовете на качеството може да се извършат или ръчно, или чрез автоматизирани тестващи инструменти, докато не е сигурно, че всички компоненти на софтуера работят коректно.

Софтуерното тестване е компромис между бюджета, времето и качеството.

Дебъгване (на английски: debugging) е процесът на проследяване на изпълнението на дадена компютърна програма с цел намиране и отстраняване на грешки („бъгове“) в нея. Дебъгването има тенденция да бъде по-трудно когато различни подсистеми са тясно свързани, тъй като промените по едната може да доведе до грешки в другата. Процесът на отстраняване на грешки се извършва с помощта на специализирани програмни инструменти наречени дебъгери.

Внедряването на софтуер обхваща всички процеси, които се извършват, за да може една софтуерна система да бъде напълно готова за употреба.

Най-общо това са няколко свързани дейности с възможност за преход между тях. Тези дейности могат да се проявят както при изпълнителят на проекта, така и при клиента. Поради уникалността на всяка една софтуерна система е трудно да се дефинират точните процеси и процедури, които се извършват. Следователно внедряването на софтуер следва да се тълкува като общ процес, който трябва да се адаптира в зависимост от специфичните изисквания на всеки отделен проект.

Поддръжка на софтуера е процеса на модифициране на софтуерните продукти след пускането им в експлоатация и цели подобряване на характеристиките и качествата им.

Всяка работа по промяна на софтуера след това се счита за поддръжка. Целта е да се запази стойността на софтуера за по-дълго време. Това се постига чрез добавяне на нови функции, улесняване на използването, постигането на по-голяма ефикасност и прилагането на нови технологии. Дейностите, които се извършват, включват поправка на грешки, усъвършенстване на възможностите, премахване на остарели функционалности и оптимизации.

Тъй като промените са неизбежни, в софтуерните системи е необходимо да бъде заложена възможността да се правят модификации още при тяхното проектиране.

Процеси на разработка на софтуер

Методологии

Методологията е свързана от една страна с анализ на принципите и методите, правилата и постулатите, прилагани в една дисциплина, а от друга – със систематичното изследване на методите, които са или могат да бъдат приложени в тази дисциплина.^[7]

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

Немодифицирания „водопаден модел“. Процеса тече от горе надолу като каскаден водопад.

Водопадният модел (среща се и като каскаден модел) е една от най-ранните методологии разработена за изграждане на софтуерни продукти. Този модел разделя софтуерните процеси на различни фази, всяка от които следва точно определен ред при разработката на софтуер. Тези фази са:^[8]

1. Спецификация на изискванията
2. Софтуерен дизайн
3. Имплементация и интеграция
4. Тестване (или Валидация)
5. Внедряване (или Инсталация)
6. Поддръжка

Процесите при водопадния модел протичат линейно и последователно. Всеки от етапите в процеса на разработка започва, само когато предишната фаза е напълно завършена. При стриктно спазване на методологията, връщане към предишна фаза за преправяне на продукта поради промяна на изискванията, не се допуска.

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

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

Главната характеристика на Спиралния модел е рисковото управление във всяка стъпка от процеса на разработка. През 1988, Barry Boehm публикува официална система за разработка на софтуер наречена „Спирален модел“, която комбинира някои основни аспекти на методологиите на водопадния модел и модела за бързо създаване на прототипи. В Спиралния модел се набляга на някои ключови области, в които при другите два модела са пренебрегнати като се разисква: необходимостта от по-задълбочен анализ на риска крайно необходим за големи по мащаб и сложност системи.

Спиралният модел се визуализира като повтарящ се процес преминаващ през няколко сектора, които чрез диаграма с четири квадранта могат да се визуализират следните дейности:

1. Изграждане на план за: набелязване на целите, разработване на програма, уточняване на задачите и дейностите по проекта.
2. Анализ на риска включва: оценка доколко са успешни набелязаните програми, идентифициране на рисковите моменти по време на разработването и предотвратяването им.
3. Имплементирането на съответния проект: разработването на програмния код и преминаването през съответните тестове за годност и пускане на пазара.

Риск-устойчивият спирален модел, набляга на условностите на различни опции и ограничения с цел да осигури четимост на кода – възможност за надграждането и редактирането му в процеса на разработка. Въпреки това, спиралния модел има някои ограничителни условия които са:

1. Спиралният модел набляга на анализа на риска, поради тази причина се изисква клиента да приеме тази особеност и да сътрудничи активно в процеса на разработване. Това изисква доверие в софтуерния разработчик, както и желание да се инвестира време в изчистването на малките детайли. Това е и причината този модел да е по-подходящ за мащабни вътрешно-търговски приложения.
2. Ако анализа на риска ще повлияе в значителна степен на себестойността на проекта, то тогава спиралния модел е неподходящ за прилагане.
3. За да сработи спиралния модел, софтуерния разработчик активно взима участие в анализа на рисковете преди, по време и след разработването на проекта.

Първата стъпка е да се изработи план за постигане на целите при вече изяснените ограничения, след това да се открият и отстранят всички рискове чрез внимателен анализ, а при необходимост да се изработи и прототип. Ако някои усложнения не могат да бъдат предотвратени, клиентът сам трябва да реши дали да прекрати разработката, или просто да ги пренебрегне. Накрая, след като резултатите се оценят, започва разработването на следващата фаза от планирането.

Scrum методология

Процесът на Scrum

Scrum e итеративна, инкрементална рамка за управление на проекти, често при гъвкавите модели на разработване.

Макар че, подходът на Scrum е първоначално предложен за управление на проектите за разработване на продукти, той се фокусира с времето върху управлението на софтуерни проекти и може да бъде използван за да задвижва екипи за софтуерна поддръжка или като общ подход за проектов / програмен мениджмънт. Тази методология е променила възприятията за типичното управление на проекти, като ясно показва предимствата на гъвкавите пред „водопадните“ или неитеративните, негъвкави методологии.

Scrum процесът се състои от отделни итерации, наречени спринтове. Спринтовете могат да имат продължителност от една седмица до четири седмици. В края на всеки спринт, екипът разполага с работеща версия на продукта, която включва всички готови задачи от backlog-а.

SCRUM е разработен за тези компании, чиято верига на стойността (изобразяваща процеса от началото до края на продукта и всяка стъпка, на която се добавя стойност) прави дългосрочното планиране на продукта доста трудно. За разлика от типичния мениджмънт чрез контрол и командване, тук се набляга на обратната връзка и се дава повече власт в ръцете на хората, които извършват операциите по процесите.

Гъвкава методология

Гъвкави методологии (английски: agile) за разработка на софтуер е неформален сбор от методологии и техники за управление на проекти за разработка на софтуер. Както подсказва и името, във фокуса на гъвкавите методологии е идеята, че разработката на софтуер е динамичен процес, в който дългосрочното планиране има ограничена ефективност.

Гъвкавите методологии намират особено широко приложение в разработката на продукти, където чрез учестеното създаване на прототипи, производителите имат възможност да получат обратна връзка от клиентите и да адаптират разработката според новопостъпилите от това изисквания.

Част от практиките на гъвкавите методологии намират приложение и в други сфери на бизнеса, главно в ИКТ.

Списък с някои от най-популярните гъвкави методологии:

• Scrum
• Екстремно програмиране
• Kanban или Lean
• Crystal
• Dynamic Systems Development Method (DSDM)
• Feature-Driven Development (FDD)^[9]

Докато всяка от гъвкавите методологии е уникална със своя специфичен подход, всички те споделят общи концепции и основни ценности на Agile Manifesto.^[10]

V-образен модел

V-образният модел в системното инженерство.^[11]

V-образният модел^[12] представлява методология за разработка на софтуер (също така приложима в разработването на хардуер), която може да бъде разглеждана като разширение на водопадния модел.

Вместо процеса на разработка на софтуер да се движи линейно надолу, след етапа на писане на изходен код процесите се „извиват“ нагоре, като по този начин графиката придобива характерната за модела V-образна форма. V-моделът показва връзките между всяка от фазите на жизнения цикъл на софтуерната разработка и как те се отнасят към фазата на тестване. По хоризонталната ос е представено времето или степента на пълнотата на проекта (от ляво надясно), а по вертикалната – нивата на абстракция.

Поддръжниците на V-образния модел твърдят, че той се развива във времето и подкрепя гъвкавостта и подвижността през цялото развитие на процеса.^[13] Те също така твърдят, че предлага много дисциплиниран подход и спомага за щателното проектиране, разработване и документиране, необходими за изграждането на стабилни софтуерни продукти. Напоследък V-моделът се приема и в медицинско-устройствената индустрия.^[14][15]

Бърза разработка на приложения

Фази на бързата разработка на приложения (RAD).

Бърза разработка на приложения (английски: RAD) е методология, която използва минимално планиране за сметка на бързото създаване на софтуерни прототипи. Планирането на софтуера, който се разработва, се припокрива с писането на самия код. Липсата на по-задълбочено предварително планиране позволява кода да се пише много по-бързо, а също така и да се правят лесно промени в първоначалните изисквания. RAD включва итеративни методи за софтуерна разработка и софтуерно прототипиране.

При бързата разработка на приложения, структурни техники и създаване на протипи се използват основно, за да се определят изисквания на потребителите и да се изработи крайната система. Процеса на разработка започва със създаването на предварителен модел на данните и процесите чрез структурни техники. При следващия етап изискванията се проверяват като се използват прототипи, за да може да се стигне до усъвършенстване на създадените модели. Тези етапи се повтарят итеративно.

Етапите при RAD са четири:

• Планиране на изискванията – комбинира елементи от фазите на системното планиране и анализиране. Потребители, мениджъри и техническия персонал дискутират заедно и взимат решения относно обхвата на проекта, целите и системните изисквания.
• Фаза на потребителския дизайн – през тази фаза потребителите подпомагат системните анализатори и се изработват модели и прототипи, които представят всички процеси, входове и изходи.
• Конструкция – фокусът е насочен към програмата и нейната имплементация. При RAD потребителите продължават своето участие и могат да предлагат промени и подобрявания.
• Експлоатация – представлява крайната фаза, където се извършва преработка на данните, тестване и обучение на потребителите. Сравнен с традиционните методи тук процеса е редуциран. Резултата е пускане на системата в експлоатация за по-кратък период.

Итеративно и постепенно развитие

Схема на итеративното и постепенно развитие

Итеративното и постепенно развитие е всякаква комбинация от итеративен дизайн и методи и модела на постепенно изграждане за разработка на софтуер. Тази комбинация е позната отдавна^[16] и е широко използвана за големи проекти. Връзката между итерациите и надграждането се определя от цялостната методология и процеса по разработката на софтуера. Точния брой и природата на конкретните стъпки и кое ще се повтаря е специфично за отделните проекти.

Итеративното и постепенно развитие са основни съставни части на Модифицирания Водопаден Модел, Рационалния Унифициран Процес, Екстремното програмиране и са основна част на някои Аджайл методологии.

Основната идея зад този метод е системата да се разработва чрез повторяемост на цикли (итерации) и това да става за малки периоди от време (постепенно), давайки възможност на разработчиците да се възползват от наученото през по-ранните етапи на системата. При всяка итерация се правят промени по дизайна и се добавят нови функционалности.

Фази:

• Проучване – определят се изискванията (функционални и не-функционални) и риска на общо ниво, но с достатъчно детайли, за да може да се оцени обема на работата.
• Разработка – създава работеща архитектура, която намалява основните рискове и допълва не-функционалните изисквания.
• Конструкция – постепенно допълва архитектурата с работещ код получен след анализ, дизайн, изпълнение и тестване на функционалните изисквания.
• Преход – превръща системата в готова за пускане в експлоатация среда.

Всяка от тези фази може да бъде разделена на една или няколко итерации, които са по-често разпределени по време от колкото по функционалност. Архитектите и анализаторите работят с една итерация в аванс, за да може навреме да снабдяват с работа разработчиците и тестерите.

Писане на код и фиксиране

Писането на код и фиксиране е може би най-често използваната методология при разработката на софтуер. При нея се започва с много малко или дори никакво планиране. Писането на код е основната начална дейност и когато се появят проблеми те се отстраняват докато проекта бъде завършен.

Това е примамлив избор когато графика за разработката на продукта е силно намален, защото писането на кода започва веднага и следователно бързо се постигат някакви резултати.

Главния недостатък на тази методология се проявява ако бъде открит сериозен архитектурен проблем късно в процеса на разработка, защото тогава се налага пренаписването на големи части от кода. Съществуват алтернативни модели, които могат да помогнат да се уловят такива проблеми в по-ранен етап, когато промените са по-лесни и евтини.

Писането на код и фиксирането е подходящо за малки проекти и не се предполага да бъде използвано за основа на бъдещата разработка на софтуер.

Употреба

Терминът на английски software engineering се появява за първи път в конференцията на НАТО от 1968, озаглавена „NATO Software Engineering Conference“ и има за идея да провокира размисли по отношение на възприеманата като „софтуерна криза“ от онова време.^[17][18]

Източници

1. Laplante, Phillip. What Every Engineer Should Know about Software Engineering. Boca Raton, CRC, 2007. ISBN 9780849372285. Посетен на 21 януари 2011. (на английски)
2. www.bestpricecomputers.co.uk
3. DRM Associates. New Product Development Glossary // 2002. Архивиран от оригинала на 2018-07-13. Посетен на 6 февруари 2012.
4. 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
5. Kotonya, G. and Sommerville, I. 1998. Requirements Engineering: Processes and Techniques Chichester, UK: John Wiley and Sons.
6. Chapter 2: Software Requirements // Guide to the software engineering body of knowledge. 2004. Los Alamitos, CA, IEEE Computer Society Press, March 2005. ISBN 0-7695-2330-7. Посетен на 8 февруари 2007. It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.
7. Methodology, Мириам Уебстър
8. Sommerville 2008, с. 89
9. Agile Methodologies for Software Development // Agile 101. VersionOne. Архивиран от оригинала на 2014-11-05. Посетен на 8/15/2013.
10. What is Agile Development? // Agile Development 101. VersionOne. Архивиран от оригинала на 2014-10-21. Посетен на 8/15/2013.
11. Clarus Concept of Operations. Архив на оригинала от 2009-07-05 в Wayback Machine. Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005
12. Kevin Forsberg and Harold Mooz, „The Relationship of System Engineering to the Project Cycle“, in Proceedings of the First Annual Symposium of National Council on System Engineering, October 1991: 57 – 65.
13. "Toward Agile Systems Engineering Processes"^{[неработеща препратка]}, Посетен на 6 януари 2013
14. "Barriers to Adopting Agile Practices When Developing Medical Device Software"
15. "A Software Process Development, Assessment and Improvement Framework, for the Medical Device Industry "
16. Larman, Craig. Iterative and Incremental Development: A Brief History // Computer 36 (6). Юни 2003. DOI:10.1109/MC.2003.1204375. с. 47 – 56. We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell ...'
17. Peter, Naur et al. Software engineering: Report of a conference sponsored by the NATO Science Committee // Garmisch, Germany, Scientific Affairs Division, NATO, 7 – 11 октомври 1968. (на английски)
18. Randell, Brian. The 1968/69 NATO Software Engineering Reports // The School of the Computer Sciences, Newcastle University, 10 август 2001. Архивиран от оригинала на 2018-06-24. Посетен на 2011-03-18. (на английски)

Тази страница частично или изцяло представлява превод на страницата Software engineering в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​ ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​