usi

ЕН, 2018/2019 1
Увод в софтуерното инженерство
I. Софтуер
1. Какво е софтуер?
• Инструкции (компютърни програми), които при изпълнение осигуряват желаните
характеристики, функциониране и производителност.
• Структури от данни, които дават възможност на програмите адекватно да манипулират
информация.
• Документи, които описват работата и използването на програмите.
• Софтуерните инженери създават софтуера и виртуално всички хора го използват – директно или
индиректно.
• Важен е, защото засяга почти всеки аспект на нашия живот и става всепроникващ (pervasive) - в
търговията, културата, ежедневните активности.
• Кои са основните предизвикателства пред софтуера?
a. Как да осигурим качеството на софтуера, който разработваме.
b. Как да удовлетворим нарастващото търсене, като продължим да управляваме бюджета.
c. Как да избегнем пагубните закъснения във времето.
d. Как успешно да въведем нови софтуерни технологии.
Софтуерът, който е предназнаен да се продава на клиент или потребител, се нарича продукт. Различават
се два типа софтуерни продукти:
• Общи (generic) продукти – самостоятелни продукти или системи, които се продават на пазара и
са предназначени за всеки потребител, който иска и може да ги купи.
• Поръчани (customized) продукти – продукти или системи, които са възложени от отделен клиент
и се разработват само за него.
Основната разлика между тези два типа софтуерни продукти е в това кой определя изискванията към
продукта – в първия случай това е самата организация, а във втория – външните клиенти.
2. Характеристики на софтуера
• логическата единица.
• разработва се, а не се произвежда.
• не се износва.
• не се амортизира в резултат на външни явления.
3. Основни категории софтуер
• Системен софтуер – съвкупност от програми, които са предназначени за обслужване на
други програми. Има за цел да улесни работата на хардуера. Характеризира се с интензивна
комуникация с хардуера, интензивно използване от много потребители и сложно управления на
процеси. Примери – операционни системи, драйвъри за устройства, компилатори, асемблери.
• Приложен софтуер – състои се от самостоятелни програми, които решават специфична
нужда на бизнеса. Приложенията в тази категория обработват бизнес или технически данни, така
че да улеснят бизнес операциите. Използва се все повече за управление на бизнес функции в
реално време.
• Научен софтуер – обслужва нуждите на отделни дялове от фундаменталните науки.
Приложенията са свързани основно със симулации на системи, автоматизирано проектиране.
ЕН, 2018/2019 2
• Вграден софтуер – намира се в дадена система и се използва за реализиране и управление на
определени функции вместо крайния потребител или системата. Може да извършва както
елементарни функции, така и значителни по обем и сложност функции. Примери – мобилни
телефони, домашни и медицински устройства, конзоли за видеоигри.
• Продуктова линия – съвкупност от софтуерни системи, които притежават общи черти,
задоволяващи нуждите на определен търговски сегмент или предопределена функция. Тези
софтуерни системи са разработени от общи основни компоненти по определен начин (намалява
цената за разработването на всичко). Повторното използване е планирано и задължително.
• Уеб проложения – множество от свързани файлове хипертекст, които представят
информация, използвайки текст и ограничени графики. Сложни среди, които осигуряват
изчислителни функции и съдържение на крайния потребител и в допълнение се интегрират с бази
данни.
a. Работят в мрежова среда.
b. Обикновено са многослойни.
c. Ориентирани са към голям брой различни потребители.
d. Трябва да позволяват едновременен достъп (натовареност).
e. Водещи са данните, а не алгоритмите.
f. Продължават да се развиват след внедряването.
g. Изискват разработка в кратки срокове.
• Изкуствен интелект – използва нечислови алгоритми за решаване на сложни проблеми,
които не подлежат на изчисления или директен анализ. Примери – роботика, невронни мрежи
• Наследен софтуер (Legacy software) – съществуващ софтуер, който е разработен преди
няколко десетилетия и продължава да се използва като непрекъснато е бил променян, за да
задоволи промени в бизнес изискванията и платформите (хардуерни и софтуерни).
A. Характеристики:
a. Дълъг живот.
b. Критична важност за бизнеса.
c. Лошо качество (нье сигурно).
B. Причини за развитие на наследените системи. Софтуерът трябва:
a. Да се адаптира, за да задоволи нуждите от нови среда за работа или технология.
b. Да се разширява, за да реализира нови бизнес изисквания.
c. Да се разширява, за да може да си взаимодейства със повече съвременни системи или БД.
d. Да се изгражда повторно архитектурата му, за да може да работи и в рамките на мрежа.
C. Четири възможности:
a. Напълно отхвърляне на наследения софтуер.
b. Непрекъснато поддържане на наследения софтуер.
c. Трансформиране на наследения софтуер по такъв начин, че да се подобри възможността
за поддръжка.
d. Замяна на наследения софтуер с нов.
Изводи
• Софтуерът се проектира и изгражда от софтуерни инженери.
• Софтуерът се използва от всеки един човек в обществото.
• Софтуерните инженери разглеждат софтуера като съставен от програми, документи и данни,
необходими за проектирането и изграждането на системата.
• Потребителите на софтуер се интересуват само дали софтуерните продукти удовлетворяват
техните очаквания и дали улесняват изпълнението на задачите им.
ЕН, 2018/2019 3
II. Софтуерно инженерство
1. Какво е инженерство?
• Инженерството е анализ, проектиране, конструиране, верифициране и управление на
технически (или социални) единици.
• С какви въпроси се занимава инженерството?
a. Какъв е проблемът, който трябва да се реши?
b. Какви са характеристиките на единицата, която се използва за решаване на проблема?
c. Как единицата (или решението) ще се реализират и конструират?
d. Какъв подход ще се използва за откриване на грешки, които са направени по време на
проектирането и конструирането?
e. Как единицата ще се поддържа във времето?
2. Какво е софтуерно инженерство?
• Дисциплина, която се занимава с всички
аспекти на проектирането и
разработването на висококачествен
софтуер.
• Занимава се с разбирането и анализирането
на даден проблем.
• Конструиране на решението от части,
които засягат различни аспекти на
проблема.
• Прилагането на систематичен,
дисциплиниран, количестено измерим подход
към разработването, функционирането и
поддръжката на софтуера. Изследване на
тези подходи.
• Решаване на проблема с използване на
различни:
a. Методи или техники (формална процедура
за произвеждане на някакъв резултат).
b. Средства (инструмент или автоматизирана система).
c. Процедури (комбинация от средства и
техники).
d. Парадигми (определен подход или
философия).
• Може да се разглежда като технология на нива
(от ниско към високо):
a. Фокус към качеството.
b. Софтуерен модел на процес.
c. Методи.
d. Средства.
• Кои са основните предизвикателства пред СИ?
a. Справяне с наследените системи, с нарастващо разнообразие и с изисквания за намалено
време за доставка.
b. Наследени системи – стари, ценни системи трябва да се поддържат и обновяват.
ЕН, 2018/2019 4
c. Хетерогенност – разработване на техники за изграждане на отказоустойчив софтуер, който е
достатъчно гъвкав, за да се справи с хетерогенността.
d. Доставяне на софтуер – има нарастващ натиск за по-бързо доставяне на големи и сложни
системи без да се прави компромис с качеството им.
3. Разлика между СИ и Компютърни науки
• КН се занимават с теория и фундаментални знания.
• СИ се занимава с практическите въпроси за разработване и
доставяне на полезен софтуер.
• Теориите на КН не са достатъчни, за да служат като
изчерпателна основа за СИ.
4. Разлика между СИ и Системно инженерство
• Системното инженерство се занимава с всики аспекти на компютърно базираните системи
включващи хардуер, софтуер и процес. Софтуерното инженерство е част от този процес.
• Системните инженери са включени в спецификация на системата, архитектурен дизайн,
интеграция и внедряване.
5. Цена на софтуера
• Често цената на софтуера доминира цената на системата.
• Цената за поддръжката на софтуера е повисока от цената за разработването.
• Софтуерното инженерство се занимава с ефективно по отношение на цената разработване на
софтуер.
6. Какво е добър софтуер?
• Гледни точки към качеството
a. Абстрактен поглед – качеството се разпознава, но не може да се дефинира.
b. Потребителска гледна точка – качеството е съответствието на поставената цел.
c. Гледна точка на разработчиците – качеството е съответствието на спецификацията.
d. Гледна точка на продукта – качеството е свързано е с характеристиките на продукт.
e. Гледна точка на цената – качеството е свързано със сумата, която е готов да плати клиента.
• Качество на продукт и качество на процес – връзката не е директна.
• Атрибути на добрия софтуер
a. Възможност за поддръжка – да е написан по такъв начин, че да може да се развива, за да
задоволи променящите се нужди на клиентите.
b. Отказоустойчивост – надеждност, сигурност, защита.
c. Ефикасност – време за отговор, време за обработка, използване на паметта.
d. Използваемост – подходящ потребителски интерфейс и адекватна документация.
7. Софтуерен процес
• Последователност от предвидими стъпки – план, който следвате, за да създадете продукт или
система в срок и с високо качество.
• Рамка на задачите, които е необходимо да се изпълнят, за да се изгради висококачествен
софтуер.
• Последователност от стъпки, включващи дейности, ограничения и ресурси, които осигуряват
постигането на някакъв вид резултат.
ЕН, 2018/2019 5
• Процесът е повече от процедура – процесът е съвкупност от процедури, организирани така, че да
се изграждат продукти, задоволяващи определени цели и стандарти.
• Установяващ базата за управление на софтуерния проект и контекста, в който се прилагат
техническите методи, създават се работните продукти, осигурява се качество.
• Процес – хора – технология.
• Етапи при разработването на софтуер
a. Анализиране и дефиниране на
изискванията.
b. Проектиране на системата.
c. Проектиране на програмата.
d. Кодиране на програмата.
e. Тестване на единиците (unit testing).
f. Тестване на интегрираните единици.
g. Тестване на системата.
h. Доставяне на системата.
i. Поддръжка.
• Основни цели (процесът е нищо vs процесът е всичко)
a. Ефикасност – способност за постигане на дадена цел, не е количествено понятия
(!= ефективност).
b. Възможност за поддръжка –
непредвидими обстоятелства.
c. Предсказуемост – предватително
планиране и заделяне на ресурси.
d. Повторяемост – използвай нещо готово
пак.
e. Качество – съответствие между продукта и
неговата цел.
f. Усъвършенстване – трябва да може да се
адаптира.
g. Проследяване – да се следи състоянието на продукта.
• Характеристики
a. Описва всички важни основни дейсности.
b. Използва ресурси, които са най-често ограничени.
c. Създава междинни и крайни работни продукти.
d. Може да бъде композиран от подпроцеси с йерархии и връзки между тях.
e. Представлява последователност от дейности.
f. Съществуват входни и изходни критерии за всяка дейност и така е ясно кога започва и кога
свършва определена дейност.
g. Съществуват ръководни принципи, включително цели на всяка дейност.
h. Съществуват ограничения за всяка дейност, били те по отношение на ресурсите или на
очаквания работен продукт.
• Рамка на процес – всяка дейност на рамката се състои от действия. Действието е съвкупност от
свързани задачи, които произвеждат работен продукт. Всяко действие се състои от отделни
работни задачи, които изпълняват част от цялото действие.
A. Основни дейности (Framework activities) – малък брой, които са приложими за всички
софтуерни проекти.
ЕН, 2018/2019 6
a. Комуникация (Communication) – интензивно взаимодействие и сътрудничесто с клиента.
Събиране и разбиране на изисквания за функционалността и на ограниченията върху
работата и разработката на продукта.
b. Планиране (Planning) – създава план за бъдещата работа по разработка на софтуера.
Описва техническите рискове, които трябва да се имат предвид, потенциалните рискове,
необходимите ресурси, работните продукти, които ще се произведат, и времеви график на
работата.
c. Моделиране (Modeling) – създаване на модели, които са на различно ниво на
абстракция. Създава се софтуерният дизайн – описание на структурата, на данните, на
интерфейсите. Имаш анализ (събиране на изисквания, уточняване, договаряне,
специфициране, валидиране) и проектиране (дизайн на данните, дизайн на
архитектурата, дизайн на интерфейс, дизайн на ниво компоненти), съответно се
получава като краен резултат модел на анализа и модел на дизайна. Важен работен
продукт – софтуерната архитектура.
d. Конструиране (Construction) – съчетава генерирането на код и тестването - тестване на
самостоятелни компоненти, тестване на интегрираната система от компоненти (тестване
на модули, тестване на подсистема и тестване на система) и потребителско тестване (бетатестване).
e. Внедряване (Deployment) – предоставя се на клиента готовият продукт. Клиента оценява
продукта.
B. Допълнителни дейности (Umbrella activities) – приложими по време на целия софтуерен
процес.
a. Следене и управление на софтуерния проект – оценява се напредъка в сравнение с
плана на проекта.
b. Управление на риска – оценяват се рисковете.
c. Осигуряване на качество
d. Формални технически прегледи – оценява работните продукти.
e. Измерване – дефинира и измерва мерки за процес, проект и продукт.
f. Управление на софтуерната конфигурация – управлява последици от промени.
g. Управление на повторното използване
h. Подготовка и генериране на работни продукти
• Модел на софтуерен процес – опростено описание на начина на разработване на софтуера,
представено от определена гледна точка. Абстракция на действителния процес.
A. Цели
a. Формиране на общо разбиране у участниците в разработването на софтуер за дейностите,
ресурсите и ограниченията.
b. Намиране на несъответствия, излишества и пропуски в процеса от разработващия екип,
което подпомага подобряването на процеса.
c. Намиране и оценяване на подходящи дейности за постигане на целите на процеса.
d. Адаптиране на общ процес към отделна ситуация, в която ще се приложи.
B. Видове модели спрямо гледната точка
a. Модел на потока от дейности (workflow model) – описва последователност от дейности,
които се описват в процеса на разработка. Отделните дейности се описват със своите
входни и изходни параметри.
b. Модел на потока от данни (dataflow model) – описва множеството от дейности, които
се извършват от гледна точка на преобразуване на данни.
ЕН, 2018/2019 7
c. Модел на роля/действие (role/action model) – описва отделните роли на хората, които
участват в процеса на разработка и дейностите, които всяка от тези роли трябва да
извърши.
C. Разлики между моделите на процеси
a. Общият поток от дейности и задачи и зависимостите между тях.
b. Степента, до която са дефинирани работните задачи в рамките на всяка основна дейност.
c. Степента, до която са дефинирани и изисквани работни продукти.
d. Общата степен на детайлност и строгост, с които процеса е описан.
e. Степента, до която купувачът и другите заинтересовани лица са включени в проекта.
f. Степента, до която са описани структурата на екипа и отделните роли.
D. Разграничаване на моделите на процеси
a. По обратната връзка (feedback).
b. Използваните методи за управление/контрол по време на разработването.
c. Времетраенето на дейностите (Timing of activities).
• Ad-hoc development
a. Възможностите на процеса са непредвидими.
b. Обикновено графиците, бюджетите, функционалността и качеството на продукта не са
съгласувани.
c. Производителността зависи от способностите на отделните хора и се променя с промяната на
техните умения, знания и мотивация.
Софтуерните модели на процеси могат да са описателни – описват историята как е протекло
разработането на софтуерната система или предписателни – предписват как би трябвало да се
разработи нова софтуерна система. Предписателните модели на процеси дефинират специално
множество от задачи и работни продукти, които са необходими за създаването на софтуер с високо
качество. Предписват работен поток – начина, по който елементите на процеса се съотнасят помежду си.
Видове предписателни:
• Каскаден (водопад)
A. Същност – най-старият метод на структурирано разбратоване на софтуер. Предлага
систематизиран, последователен подход към разработването на софтуер. Моделът налага поскоро структура на управление на проект за разработване на софтуер, отколкото да дава
насоки как да се извършват отделните дейности.
B. Дейности (основните)
a. Събиране на софтуерните изисквания.
b. Оценяване, изготвяне
на график,
проследяване.
c. Анализ и проектиране.
d. Генериране на код и
тестване.
e. Доставяне и поддръжка.
C. Характеристики
a. Ясно разграничен процес, който е лесен за разбиране.
b. Всяка стъпка в модела завършва със създаване на множество от документи.
c. Всяка дейност трябва да бъде напълно завършена преди преминаване към следващата,
тоест след одобряване на множеството документи.
ЕН, 2018/2019 8
d. Ясно са дефинирани входовете и изходите на дейностите, както и интерфейсите между
отделните стъпки.
e. Ясно са дефинирани ролите на разработчиците на софтуер.
D. Проблеми
a. Реалните проекти рядко следват последователния поток на разработка, който се предлага
от модела.
b. Моделът налага по-скоро структура на управление на проект за разработване на софтуер,
отколкото да дава насоки как да се извършват отделните дейности.
c. Трудно е за потребителя да формулира всичките си изисквания в началото.
d. Клиентът трябва да е търпелив, тъй като няма достъп между отделните модули.
e. Разделянето на проекта на отделни етапи не е гъвкаво.
f. Трудно е да се реагира на променящите се изисквания на клиента.
E. Използване – когато изискванията са осъзнати и ясно формулирани още в началото и когато
проектите са ясно организирани в смисъл на ясно дефинирани роли. Още, при големи проекти,
за които времето и бюджета не са критични.
• Модел на бързата разработка (RAD)
A. Същност – високоскоростна адаптация на модела на водопада. Целта му е кратък цикъл на
разработка (60-90 дена). За постигането й се разчита на използването на различни средства
за бърза разработка.
B. Дейности
a. Комуникация.
b. Планиране – няколко софтуерни екипа работят паралелно.
c. Моделиране – всеки екип извършва отделно моделиране на своя модул. Има три вида –
бизнес модел, модел на данните и модел на процес.
d. Конструиране – най-често се използват предварително съществуващи софтуерни
компоненти, които се интегрират, и средства за автоматично генериране на код.
e. Внедряване.
C. Проблеми
a. За големи приложения,
подлежащи на разделяне на
модули – не е подходящо,
трябват много хора.
b. Когато функционалността на
софтуера не може да бъде
разделена на отделни модули
(различна времетраеност на
всеки модул).
c. Когато е важна високата
производителност на
софтуерното приложение.
d. Когато за разработката на
приложението се разчита на все
още нови и неусвоени
технологии.
D. Използване – при проекти, чиято функционалност може да се разпредели в отделни модули,
така че да могат да се реализират в рамките на 60-90 дни.
ЕН, 2018/2019 9
Видове фазови (еволюционни) модели:
• Инкрементателен
A. Същност – не доставя системата
като едно цяло, а вместо това
процесът на разработка и
доставянето са разделени на
стъпки, като всяка стъпка доставя
само част от цялята
функционалност. След като
започне разработването на една
стъпка изискванията не се променят. С всеки доставен следващ инкремент постепенно се
осигурява все повече функционалност на клиента. Комбинира елементи на модела на
водопада, но приложени на отделни стъпки.
• Итеративен
A. Същност – още в началото доставя цялостната система, макар и част от функционалността
да е в примитивна форма. При всяка следваща итерация не се добавя нова функционалност,
а само се усъвършенства съществуващата.
B. Проблеми и на двата еволюционни модели
a. Необходимостта от активно участие на клиентите по време на изпълнение на проекта
може да доведе до закъснения.
b. Уменията за комуникация и координация са от особено голямо значение при разработката
и ако не са на достатъчно добро ниво, водят до проблеми.
c. Неформалните заявки за подобрения след завършването на всяка стъпка могат да доведат
до объркване.
d. Този модел може да доведе до т. нар. “scope creep” – бавно и постепенно разширяване на
обхвата на приложението, без процесът да е сходящ.
C. Предимства и на двата еволюционни модели
a. Клиентът може да използва системата, преди да е готов целият продукт.
b. Първите стъпки могат да служат като прототип, за да помогнат за извличане и изясняване
на изискванията към следващите стъпки.
c. По-малък риск от неуспех на целия проект.
d. Функционалностите от цялата система, които са с най-висок приоритет, са тествани наймного.
D. Използване - когато организацията няма достатъчно човешки ресурс за цялостната
реализация в определен срок или когато с итерациите може да се управляват технологичните
рискове.
• Прототипен модел
A. Същност - два типа – еволюционен прототип – да достави работеща система на крайния
потребител и хвърлен прототип – да подпомогне специфицирането на изискванията към
софтуера. Основната цел на прототипния модел е изграждане на прототип, който да извлече
или валидира системните изисквания. Могат да се оценят рисковете на процеса.
ЕН, 2018/2019 10
B. Подходи
a. Създаване на основните потребителски
интерфейси, без да има някакво
значително кодиране.
b. Разработване на съкратена версия на
системата, която изпълнява
ограничено подмножество от
функции.
c. Използване на съществуваща система
или компоненти от система, за да се
демонстрират някои функции, които
ще бъдат включени в разработваната
система.
C. Проблеми
a. Прототипният модел може да използва значителни ресурси, а като резултат прототипът да
не успее да удовлетвори очакванията.
b. Прототипът може да доведе до лошо проектирана система, ако самият той стане част от
крайния продукт.
c. Прототипният модел не е подходящ за използване при разработване на софтуерни
системи, където проблемът е добре разбран и интерфейсът е ясен и прост.
D. Използване – в проекти, където не са достатъчно ясни потребителските изисквания и дизайнът
на софтуерната система. Може да се използва както самостоятелно, така и с други модели на
процеси.
• Спираловиден модел
A. Същност – еволюционен модел на
софтуерен процес, който съчетава
прототипния модел и модела на
водопада. Движещият се фактор е
анализ на риска. Основни
характеристики са
итеративен/цикличен подход и че
има множество от точки на прогреса.
B. Сектори – при всяко завъртане на
спиралата се преминава през
следните сектори:
a. Установяване на целите –
определят се целите,
алтернативите и ограниченията на текущата фаза от разботката.
b. Оценка на рисковете и намаляването им – идентифицират се и се анализират
потенциалните рискове и се предприемат действия за намаляването или елиминирането
им.
c. Разработване и валидиране – избира се модел за разработване на текущата фаза.
d. Планиране – преглежда се и се анализира текущото състояние и се планира следващото
завъртане по спиралата.
C. Проблеми
ЕН, 2018/2019 11
a. Може да се окаже трудно да се убедят клиентите, че процесът на разработка е
контролируем, а не е безкраен цикъл.
b. Изисква се участието на разработчици с компетентност за оценка на рисковете.
c. Ако не се идентифицира и открие някой основен риск, това може да доведе до неуспех.
D. Използване – при разработване на големи (large-scale) софтуерни системи. Може да се
адаптира и да се прилага през целия жизнен цикъл на софтуера.
• Метод на формалната трансформация – скъп и бавен процес. Основава се на математическо
трансформиране на спецификацията на системните изисквания до изпълнима програма.
Дейностите моделиране и конструиране са заменени с разработване и прилагане на
трансформации. При трансформирането трябва да се запази коректността и ясно да се покаже, че
изпълнимата програма съответства на спецификацията. Използва се при разработването на
софтуерни системи, които са свързани с поддръжката на човешки живот и за които трябва да са
гарантирани сигурността и отказоустойчивостта на софтуера, преди да започне реалното му
използване.
Как да изберем нашия модел?
• Постоянна среда – изискванията към софтуерната система не се променят и могат да бъдат
формулирани ясно и изчерпателно. Модел на водопада или спираловиден.
• Бурна среда – непрекъснато и организацията претърпява промени, и изискванията към системата
се променят. Модел на бързата разработка или прототипен модел.
• Несигурна среда – изискванията към системата са неясни или несигурни. Когато системата е нова
и не е решаван подобен проблем или решава проблеми по нов начин. Нови модели, които да
включват елементи на прототипния модел и модела на бързата разработка.
• Адаптивна среда – средата може да се променя като реакция на системата, която е била
разработена и това води до промяна на изискванията.
8. Шаблони
• Шаблон – описание на общо решение на общ проблем или въпрос, на базата на което може да се
извлече детайлно решение на специфичен проблем.
• Шаблон на процес – шаблон, който описва доказан, успешен подход и/или последователност от
действия за разработване на софтуер. Важна характеристика на шаблон на процес е, че той описва
какво трябва да се направи, а не точни детайли как трябва да се направи. Шаблоните могат да
бъдат дефинирани на различни нива на абстракция.
9. Методи на софтуерното инженерство
• Структуриран подход към разработването на софтуер, чиято цел е да улесни създаването
на рентабилен софтуер с високо качество.
• Компоненти
a. Описания на отделните модели на системата.
b. Правила.
c. Препоръки.
d. Упътване на процеса.
10. Софтуерни средства
• CASE средства са софтуерни системи, които са проектирани да поддържат рутинни активности от
софтуерния процес.
ЕН, 2018/2019 12
• Различни типове програми, които се използват да поддържат дейностите от софтуерния
процес.
• Осигуряват автоматична или полуавтоматична поддържа на софтуерните процеси и методи.
Улесняват дейностите, които се извършват в рамките на процеса на разработка.
• CASE (Computer-Aided Software Engineering) – система, поддържаща разработката на
софтуер, която е изградена на базата на интегриране на отделни средства, така че
информацията да се използва от едно място на друго.
a. UPPER-CASE средства – поддържат началните фази – анализ и проектиране.
b. LOWER-CASE средства – поддържат фазите на реализация и тестване.
Изводи
• Софтуерното инженерство е дисциплина, която интегрира процеси, методи и средства за
разработване на софтуер.
• Софтуерният процес се състои от активности, които се извършват при разработването на
софтуер.
• Методите са организиран начин за създаване на софтуер.
Предписателни модели на софтуерен процес
• Различен поток на процес.
• Еднакво множество от основни дейности.
Всички модели на процеси дефинират:
• Множество от основни дейности.
• Съвкупност от задачи, които водят до завършване на всяка дейност.
• Работни продукти, като следствие от задачите.
• Множество от допълнителни дейности, които обхващат целия процес.
ЕН, 2018/2019 13
III. Гъвкаво разработване на софтуер
1. Философия на гъвкавото разработване
• Отделните хора и итерации са по-важни, отколкото процесите и средствата – хората са най-важния
елемент на успеха.
• Работещият процес е по-важен от изчерпателната документация – твърде много документация е
по-зле от твърде малко.
• Сътрудничеството с клиентите е по-важно от формалните клаузи в сключения договор – важно е
да има обратна връзка.
• Реагиране на възникнали промени е по-важно от стриктното следване на плана – детайлен план
за следващите седмици, общ план за следващите месеци и ориентировъчно за по-нататък.
2. Rapid software development
• Businesses operate in a fast –changing requirement and it is practically impossible to produce a set of
stable software requirements.
• Software has to evolve quickly to reflect changing business needs.
• Specification, design and implementation are inter-leaved.
• System is developed as a series of versions with stakeholders involved in version evaluation.
• User interfaces are often developed using an IDE and graphical toolset.
3. Гъвкави методологии – поставянето на хората като основен фактор за успеха на проекта и
фoкусирането върху ефективността и маневреността на процеса на разработка.
• Agile methods are incremental development methods that focus on rapid development, frequent
releases of the software, reducing process overheads and producing high-quality code. They involve the
customer directly in the development process.
• Общи черти за практиките
a. Разработването се извършва на
къси итерации (1 седмица до 1
месец).
b. Клиентът итеративно получава
работещи версии на системата.
c. Качеството е първи приоритет.
d. Обикновено целият екип е
събран на едно място, за
улесняване на неформалната
комуникация.
e. Информацията за развитието на
проекта е на общодостъпно място.
f. Постоянно обучение.
g. Промяната дори и на работещата подсистема се възприема като нещо нормално.
• Проблеми
a. Да държиш интереса на клиентите си.
b. Подреждането на приоритетите.
c. Старанието всичко да е „много просто“ изисква повече работа.
d. Екипът не се разбира.
e. Договаряне.
• Приложимост
ЕН, 2018/2019 14
a. Product development where a software company is developing a small or medium-sized product for
sale.
b. Custom system development within an organization, where there is a clear commitment from the
customer to become involved in the development process and where there are not a lot of external
rules and regulations that affect the software.
• Поддръжка
a. Most organizations spend more on maintaining existing software than they do on new software
development. So, if agile methods are to be successful, they have to support maintenance as well
as original development.
4. Plan-driven and agile development
• Plan-driven development
a. A plan-driven approach to software
engineering is based around separate
development stages with the outputs to be
produced at each of these stages planned in
advance.
b. Not necessarily waterfall model – plan-driven,
incremental development is possible.
c. Iteration occurs within activities.
• Agile development
a. Specification, design, implementation and
testing are interleaved and the outputs from
the development process are decided through a process of negotiation during the software
development process.
• Как да изберем?
a. Is it important to have a very detailed specification and design before moving to implementation?
If so, you probably need to use a plan-driven approach.
b. Is an incremental delivery strategy, where you deliver the software to customers and get rapid
feedback from them, realistic? If so, consider using agile methods.
c. How large is the system that is being developed? Agile methods are most effective when the system
can be developed with a small co-located team who can communicate informally. This may not be
possible for large systems that require larger development teams so a plan-driven approach may
have to be used.
d. Plan-driven approaches may be required for systems that require a lot of analysis before
implementation (e.g. real-time system with complex timing requirements).
5. Extreme programming
• Най-често използваната гъвкава методология.
• Четири основни ценности – комуникация,
простота, кураж и обратна връзка.
a. New versions may be built several times per day.
b. Increments are delivered to customers every 2
weeks.
c. All tests must be run for every build and the
build is only accepted if tests run successfully.
d. In XP, a customer or user is part of the XP team and is responsible for making decisions on
requirements. Customer involvement means full-time customer engagement with the team.
ЕН, 2018/2019 15
e. Maintaining simplicity through constant refactoring of code.
f. Extreme programming is a well-known agile method that integrates a range of good programming
practices such as frequent releases of the software, continuous software improvement and
customer participation in the development team.
• Фази
a. На проучване.
b. На планиране.
c. На итерациите.
d. На готовия продукт.
e. На поддръжка.
f. На смърт – готов продукт.
• Практики
a. Планиране.
b. Кратки версии.
c. Опростен дизайн.
d. Тестване преди програмиране.
e. Рефакторинг.
f. Програмиране по двойки.
g. Колективна собственост.
h. Постоянна интеграция.
i. 40-часова работна седмица.
j. Клиент при разработчиците.
• Testing (Test-driven development)
a. Writing tests before code clarifies the
requirements to be implemented.
b. Tests are written as programs rather than data so that they can be executed automatically. The test
includes a check that it has executed correctly.
c. All previous and new tests are run automatically when new functionality is added, thus checking
that the new functionality has not introduced errors.
d. The role of the customer in the testing process is to help develop acceptance tests for the stories
that are to be implemented in the next release of the system.
e. The customer who is part of the team writes tests as development proceeds. All new code is
therefore validated to ensure that it is what the customer needs.
f. Programmers prefer programming to testing and sometimes they take short cuts when writing tests.
For example, they may write incomplete tests that do not check for all possible exceptions that may
occur.
g. It’s difficult to judge the completeness of a set of tests. Although you may have a lot of system tests,
your test set may not provide complete coverage.
• Refactoring
a. Programming team looks for possible software improvements and make these improvements even
where there is no immediate need for them.
b. This improves the understandability of the software and so reduces the need for documentation.
c. Changes are easier to make because the code is well structured and clear.
d. However, some changes require architecture refactoring and this is much more expensive.
e. Re-organization of a class hierarchy to remove duplicate code.
f. Tidying up and renaming attributes and methods to make them easier to understand.
ЕН, 2018/2019 16
• Pair programming
a. In XP, programmers work in pairs, sitting together to develop code.
b. This helps develop common ownership of code and spreads knowledge across the team.
c. It serves as an informal review process as each line of code is looked at by more than 1 person.
d. It encourages refactoring as the whole team can benefit from this.
e. Measurements suggest that development productivity with pair programming is similar to that of
two people working independently.
f. Pairs are created dynamically so that all team members work with each other during the
development process.
g. The sharing of knowledge that happens during pair programming is very important as it reduces the
overall risks to a project when team members leave.
h. Pair programming is not necessarily inefficient and there is evidence that a pair working together is
more efficient than 2 programmers working separately.
i. It supports the idea of collective ownership and responsibility for the system.
j. It helps support refactoring, which is a process of software improvement.
• Използване – приложим при малки и средни екипи ( 3 – 20 души). Методологията е подходяща
за разработването както на софтуерни приложения, решаващи специфични бизнес проблеми,
така и на уеб-базирани системи.
6. Agile project management
• The principal responsibility of software project managers is to manage the project so that the software
is delivered on time and within the planned budget for the project.
• Agile project management requires a different approach, which is adapted to incremental development
and the particular strengths of agile methods.
7. Scrum
• Разработката на една система се обуславя от различни променливи като изисквания към
продукта, време за разработка, налични ресурси и технологии, които има вероятност да бъдат
променени.
• Процесът на разработка е непредвидим от самото начало, изискващ гъвкавост от използвания
процес, за да бъде в състояние да отговори на тези промени.
• Предимства
a. The product is broken down into a set of manageable and understandable chunks.
b. Unstable requirements do not hold up progress.
c. The whole team have visibility of everything and consequently team communication is improved.
d. Customers see on-time delivery of increments and gain feedback on how the product works.
e. Trust between customers and developers is established and a positive culture is created in which
everyone expects the project to succeed.
f. The whole team attends short daily meetings where all team members share information, describe
their progress since the last meeting, problems that have arisen and what is planned for the
following day
• Фази – три фази
A. Предварителна.
a. Планиране – дефиниране на
системата преди началото на
разработка.
b. Дизайн и архитектура на
високо ниво – системата се
ЕН, 2018/2019 17
проектира на най-високо ниво, създава се архитектурата на базата на текущите елементи
в списъка с изискванията на продукта.
B. Фаза на развитие – разработка (всичко непредвидимо може да се случи). Системата се
разработва на спринтове – 30-дневни итеративни цикли.During this stage the team is isolated
from the customer and the organization, with all communications channelled through the socalled ‘Scrum master’. The starting point for planning is the product backlog, which is the list of
work to be done on the project. Разработва се нова функционалност за системата или се
подобрява вече съществуваща. The selection phase involves all of the project team who work
with the customer to select the features and functionality to be developed during the sprint.
Всеки спринт има фиксирана дължина от 2 до 4 седмици. В разработката на дадена система
е препоръчително да се включат между 3 и 8 спринта.
C. Заключителна фаза – приключване на проекта и създаване на готова версия на системата.
• Екипна работа
a. The ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the backlog of work to be
done, records decisions, measures progress against the backlog and communicates with customers
and management outside of the team.
b. The whole team attends short daily meetings where all team members share information, describe
their progress since the last meeting, problems that have arisen and what is planned for the
following day.
• Практики
a. Списък с изисквания за продукта. (Product backlog)
b. Оценяване на количеството работа.
c. Спринт.
d. Среща за планиране преди всеки спринт.
e. Списък с изискванията за спринт.
f. Дневни срещи.
g. Среща за преглед на спринта.
• Използване – концентрира се върху това как да работят членовете на екипа, за да придадат
гъвкавост на разработвания продукт при постоянно променящи се изисквания. Два начина на
приложение – при създаване на нов продукт или при подобряването и надграждането на вече
съществуващ продукт. Може да се приложи и по време на изпълнение на вече съществуващ
проект. Обикновено се преминава към Scrum при често появяване на проблеми поради
постоянно променяща се среда при вече запознал проект. Екип от 5 до 9 души.
8. Scaling agile methods
• Agile methods have proved to be successful for small and medium sized projects that can be developed
by a small co-located team.
• It is sometimes argued that the success of these methods comes because of improved communications
which is possible when everyone is working together.
• Scaling up agile methods involves changing these to cope with larger, longer projects where there are
multiple development teams, perhaps working in different locations.
• ‘Scaling up’ is concerned with using agile methods for developing large software systems that cannot be
developed by a small team.
• ‘Scaling out’ is concerned with how agile methods can be introduced across a large organization with
many years of software development experience.
• Scaling agile methods for large systems is difficult. Large systems need up-front design and some
documentation.
ЕН, 2018/2019 18
IV. Софтуерни изисквания
1. Инженеринг на изискванията.
• Процес на установяване на услугите, които даден клиент изисква от системата, както и
ограниченията на работа и разработване.
• Сами по себе си изискванията са описание на системните функции и ограниченията, които се
установяват по време на инженеринга на изискванията.
• Дисциплина от софтуерното/ системното инженерство, която обхваща дейностите по
специфициране на продукта/системата.
• ИИ е изключително важна част от процеса на системно разработване, която направлява всички
останали дейности към постигане на резултатите, за които системата е предназначена.
• ИИ оказва влияние на целия жизнен цикъл на дадена система.
• Какво е изискване?
a. Изискванията са спецификации на това, което трябва да бъде разработено. Те са описание на
начина на поведение на система. Могат да представляват също и ограничения върху процеса
на разработване.
b. Изискванията спомагат да се дефинира – стойността на и необходимостта от дадена система,
общото разбиране за системната функционалност, какво трябва да прави дадена система, но
не и как да го прави.
c. Изискванията са зависими от гледните точки на различните участници в процеса на
разработване.
d. Изискванията могат да варират от много абстрактни описания на дадена системна
функционалност или ограничения до много точни и детайлни математически функционални
спецификации.
e. Могат да послужат като заявка за търг – следователно тряба да са отворени за интерпретация.
f. Могат да бъдат и база за договор – следователно тряба да бъдат детайлно дефинирани.
• “Да пишем и да поправяме" или да въведем дисциплиниран подход при разработването на
софтуер?
• Основни дейности на ИИ
a. Идентифициране на изискванията.
b. Анализ на изискванията.
c. Валидиране на изикванията.
d. Управление на изискванията.
• Пълнота и консистентност на изискванията
a. Пълни – трябва да включват описание на всички изисквани функции.
b. Консистентни – не трябва да има конфликти или противоречия при описанието на системните
функции.
c. Малко е невъзможно да са и двете на практика.
2. Видове изисквания
• Потребителски изисквания – описват функционални и нефункционални изисквания, по начин
разбираем за системните потребители, които нямат технически познания. Потребителските
изисквания се описват на естествен език с таблици и диаграми, които биха били разбираеми за
всички потребители. Написани за клиентите, системни потребители, технолози при клиента,
специалисти по договори, системни архитекти.
• Системни изисквания – структуриран документ с детайлно описание на системните функции,
услуги и оперативни ограничения. Предназначени са да послужат като основа на дизайна на
ЕН, 2018/2019 19
системата. Определят какво трябва да се имплементира и може да бъде част от договора между
клиента и разработчика. Системните изисквания могат да бъдат дефинирани и илюстрирани като
се използват различни системни модели. Написани за системните потребители, технолози при
клиента, системни архитекти, разработчиците.
• Функционални изисквания
a. Oписание на услугите, които системата трябва да предоставя, начинът, по който системата
трябва да реагира на конкретни входни данни и поведението и в конкретни ситуации.
b. Детайлно твърдение за поведението на системата от гледна точка на крайния потребител.
c. Зависят от типа на софтуера, потенциалните потребители и типа на системата, в която ще бъде
използван софтуера.
d. Функционалните потребителски изисквания могат да бъдат описания на високо ниво на
това какво трябва да прави системата, но функционалните системните изисквания трябва
да описват системната функционалност в детайли.
• Нефункционални изисквания
A. Oграничения върху услугите или функционалността на системата като времеви ограничения,
ограничения върху процеса на разработване, използваните стандарти и др.
B. Изисквания към процеса могат също да бъдат специфицирани – например конкретна CASE
система, програмен език или метод на разработване.
C. Нефункционалните изисквания могат да бъдат по-критични от функционалните и от тях може
да зависи пригодността на системата.
D. Трудно е да се специфицират прецизно нефункционалните изисквания, а непрецизните
изисквания трудно се верифицират.
E. Определят системни характеристики и ограничения като надежност, време за отговор и др.
F. Видове
a. Продуктови изисквания – изисквания, които определят поведението на продукта, като
време за изпълнение, надежност и др.
b. Организационни изисквания – изисквания, които са следствие на практиката и
процедурите в дадена организация, като прилаганите стандарти при процеса на
разработване, изисквания към имплементцията, доставка и др.
c. Външни изисквания – изисквания породени от външни за системата и процеса на
разработване фактори, като изисквания за оперативна съвместимост и нормативни
(законодателни) изисквания, етични и др.
G. Цели и изисквания
a. Основно виждане на потребителя като лесно ползване.
b. Верифицируеми нефункционални изискваня – основават се на мерки, които могат да
бъдат обективно тествани.
c. Целите са полезни на разрабочтчиците, защото представят виждането на системните
потребители.
• Изисквания на приложната област
a. Oписват характеристики и особености на системата, отразяващи спецификите на областта.
b. Могат да бъдат нови функционални изисквания, ограничения върху вече съществуващи
изисквания или да дефинират специфични изчисления.
c. Изискванията са изразени на езика на приложната област. Това често ги прави неразбираеми
за софтуерните инженери, разработващи системата.
d. Имплицитност – специалистите от приложната област познават областта толкова добре, че те
не могат да определят изискванията експлицитно/явно.
ЕН, 2018/2019 20
3. Спецификация на софтуерните изисквания
• Спецификацията на софтуерните изисквания е официално становище за това какво се изисква от
разработчиците на системата.
• Включва едновременно дефиниция на потребителските изисквания и спецификация на
системните изисквания.
• Да се опише валидирането на изискванията и ролята на ревютата на изисквания.
• Не е дизайн документ. До колкото това е възможно трябва да се наблегне на това КАКВО трябва
да прави системата, отколкото на това КАК да го прави.
• „Участници“
a. Клиенти - специфицират изискванията и ги четат за да са сигурни, че отговарят на техните
нужди. Специфицират промени в изискванията.
b. Менажери - използват документа за да планират разработването на системата.
c. Системни инженери - използват документа за да разберат какво трябва да се разработва.
d. Системни тест инженери - използват документа за да разработят тестовете за валидиране на
системата.
e. Инженери по поддръжката на системата - използват документа за да разберат системата и
връзките между нейните части.
• Видове гледни точки
a. Гледни точки на взаимодействие – хора или други системи, които си взаимодействат пряко
със системата.
b. Индиректни гледни точки – заинтересованите лица, които не са преки потребители на
системата, но влияят на изискванията.
c. Гледни точки на приложната област – спецификите и ограниченията на приложната област,
които влияят на изискванията.
• Процес
a. Откриване на изискванията – взаимдействия със заинтересованите лица, за да се установят
изискванията. На този етап се определят и изискванията на приложната област.
b. Организиране и класификация на изискванията – свързаните изисквания могат да бъдат
класифицирани и организирани в съгласувани групи (клъстери).
c. Приоритизация и договаряне – приоритизиране на изискванията и разрешаване на
конфликтите.
d. Документиране на изискванията – изискванията за документирани и се тръгва по следващия
цикъл на спиралата.
• Проучвания за осъществимост - проучване за осъществимост се прави с цел да се докаже че
разработването на системата си струва. Базирано на оценка на информацията (какво е
необходимо), събиране на информация и писане на доклад.
• Интервюта
a. Във формални или неформални интервюта екипът по определяне на изисквнията задава
въпроси на заинтересованите лица за системата, коато използват и за тази, която ще бъде
разработена.
b. Затворени интервюта, при които се задават предварително дефинирани въпроси.
c. Отворени интервюта, при които няма предефиниран план и се провежда отворена дискусия.
d. Най-често смесени затворени и отворени интервюта.
e. Интервютата са добра практика за придобиване на цялостна представа за това какво правят
заинтересованите лица и как ще си взаимодействат със системата.
f. Интервютата не са удачни за разбиране на изискванията на приложната област.
ЕН, 2018/2019 21
• Социални и организационни фактори
a. Софтуерните системи се използват в социален и организационен контекст. Това може да
повлияе и дори да е доминиращо при определяне на системните изисквания.
• Етнография
a. Социалният изследовател отделя много време да наблюдава и анализира поведението на
хората по време на работа.
b. Не се налага хората да обясняват и анализират начина си на работа.
c. Етнографските изследвания са показали, че най-често работата е много по-сложна отколкото
предполагат опростените системните модели.
4. IEEE стандарт за изисквания
• Дефинира основна структура за спецификацията на софтуерните изисквания, която да бъде
инстанциирана за всяка специфична система.
• Въведение. – Основно описание. – Специфични изисквания. – Приложения. – Индекс.
5. Валидиране на изискванията (при спецификацията на изисквания)
• Целта е да се демонстрира, че изискванията определят системата, която клиентът наистина иска.
• Поправяне на грешка допусната при определяне на изискванията след доставянето на системата
може да струва до 100 пъти повече, отколкото поправянето на грешка от имплементацията.
• Грешките при определяне на изискванията струват много скъпо и за това валидирането е особено
важно.
• Проверка на изискванията
a. Валидност - дали системата наистина предоставя функциите, които да отговорят най-добре на
нуждите на клиента?
b. Консистентност - има ли противоречиви изисквания?
c. Пълнота - включени ли са всички функции, изискани от клиента?
d. Реалистичност - могат ли изискванията да бъдат реализирани предвид наличните бюджет и
технологии?
e. Верифицируемост - могат ли изискванията да бъдат променени?
• Ревюта на изисквнията
A. Периодични ревюта трябва да бъдат провеждани, при процеса на дефиниране на
изискванията.
B. В ревютата трябва да бъдат включени хора както от страна на клиента, така и специалисти от
страна на разработващата организация.
C. Проверява:
a. Верифицируемост. Дали изискванията могат да бъдат реалистично верифицирани/
тествани?
b. Понятност. Дали изискването е правилно разбрано?
c. Проследяемост. Дали произхода на изискването е ясно дефиниран?
d. Адаптивност. Може ли изискването да бъде променено, без това да повлияе силно на
останалите изисквания?
• Прототипиране
a. Използване на работещ модел на системата, за да се проверят изискванията.
• Генериране на тестови случаи
6. Управление на изискванията
• Управлението на изискванията е процес на управление на променящите се изисквания по време
на определянето на изискванията и системното разработване.
ЕН, 2018/2019 22
• Постоянни и променливи изисквания.
• Планиране на управлението на изискванията
a. Идентифицирането на изискванията.
b. Процеса на управление на промените при изискванията.
c. Политиката на проследяемост.
d. Използване на CASE системи.
• Управление на промените при изискванията
a. Анализ на проблема. Дискутиране на проблема с изискванията и предложение за промяна.
b. Анализ на промените и цената им. Оценка на влиянието на промяната върху други изисквания.
c. Реализиране на промяната. Промяна на документа с изискванията и другите документи за да
се отрази промяната.
7. Класификация на изискванията
• Мутиращи изисквания - изисквания, които се променят, поради помени в средата, в която работи
организацията.
• Появяващи се изисквания - изисквания, които се появяват вледствие на по-доброто разбиране за
системата, което клиентът придобива по време на системното разрботване. Дизайн процесът
може да разкрие нови изисквания.
• Последстващи изисквания - изисквания, произтичащи от въвеждането на компютърната система
– това може да промени процесите в организацията и да открие нови начини на работа, които да
генерират нови изисквания.
• Съвместими изисквания - изисквания, които зависят от конкретна система или бизнес процес в
организацята. Ако те се променят, възникват изисквния за съвместимост.
8. Изисквания и дизайн
• Изискванията определят какво трябва да прави системата, а дизайнът описва как ще го прави.
• Изискванията и дизайна са неразделни – системната архитектура и дизайн структурират
изискванията.
9. Графични модели
• Графичните модели са най-полезни, когато се налага да се опише как се променят състояния или
конкретна последователност от действия.
10. Диаграми на последователност
• Показват последователност от събития, които се случват докато потребителят си взаимодейства
със системата.
Изводи
• Изискванията определят какво трябва да прави системата и дефинират ограниченията върху
нейната работа и имплементация.
• Функционалните изисквания определят услугите, които системата трябва да предоставя.
• Нефункционалните изисквания ограничават разработваната система и процеса на
разработване.
• Потребителските изисквания са твърдения на високо ниво, за това какво трябва да прави
системата. Те трябва да бъдат описани на естествен език и чрез таблици и диаграми.
• Системните изисквания са предназначени да комуникират функциите, които системата трябва
да предостави.
• Спецификацията на софтуерните изисквания е съгласувано споразумение за системните
изисквания.
ЕН, 2018/2019 23
• IEEE стандартът е полезен като отправна точка за дефиниране на по-детайлни специфични
стандарти за изисквания.
Процесът на инженеринг на изискванията включва:
• Проучване за осъществимост.
• Идентифициране и анализ на изискванията.
• Специфициране на изискванията.
• Валидиране на изискванията.
• Управление на изискванията.
Идентифицирането и анализът на изискванията са итеративни и включват:
• Разбиране за приложната област
• Събиране на изискванията.
• Класифициране, структуриране, приоритизиране и валидиране.
• Системите имат много заинересовани лица с различни изисквания.
• Изискванията се влияят от социални и организационни фактори.
• Валидирането на изскванията цели да провери дали изискванията са валидни, консистентни,
пълни, реалистични и верифицируеми.
• Промените в бизнес средата водят до промени в изискванията.
• Управлението на изискванията включва планиране и управление на промените.