Софтверско инженерство – вадена теорија

Магдалена Силјаноска
Topic 02 - Критериуми за квалитет на софтверски производи

 КОРЕКТНОСТ – програмата се однесува според барањата, односно програма

спецификација на барања
 НАДЕЖНОСТ – во програмата грешките се ретки и имаат слаб ефект
 РОБУСНОСТ – еден софтверски систем е робусен ако има способност да се справи со
ефекетите од околината со грешки
 СКАЛАБИЛНОСТ – можност за проширување со фокус на неколку параметри: поголеми
податочни множества, поголем број на корисници, ...
 ПОРТАБИЛНОСТ – степен на независност на софтверот и оперативниот систем
o Софтверот е портабилен кога напорот за промена на трансфер е значително помал
отколку за нова имплементација на истиот
o Со други зборови: Колку е едноставен трансферот на софтверот на компјутери со
различни оперативни системи
 ОДРЖУВАЊЕ – еден софтверски производ има можност за одржување, ако е лесен за
модифицирање со цел: дебагирање, подобрување, трансфер
 USER-FRIENDLINESS

Класификација на кретериумите за квалитет на софтвер

1. НАДВОРЕШНИ 2. ВНАТРЕШНИ
(што може корисникот да опслужи) (само компјтерски експерт може да
опслужи)
 Коректност  Одржување
 Надежност  Читливост
 Скалабилност  Портабилност
 Робусност  Реискористливост
 Ефикасност  Модуларност
 Компатибилност  Тестирање

Заеднички критериуми и за одржувачот и за корисникот и за продавачот се: надежност и

коректност.
Најважни кретериуми за квалитет од индустриска гледна точка
 Надежност
 Ефикасност
 Скалабилност
 User-friendliness
 Реискористување

1
 Topic 03 - Процесни модели

 Дефиниција:Процесен модел е развоен план кој го специфицира генералниот процес за

развој на продуктот или попрецизно:
 Процесен моделе дефиниција која дефинира кои активности треба да се остварат, од која
личност, делувајќи во која улога, по кој редослед ќе се остваруваат активностите и кои
производи ќе се развиваат и како да ги еволуираме.
 Дефиниција: Улога – Член на проектниот тим кој извршува некоја активност

Видови на процесни модели

 Класичен модел во фази (Waterfall model)
 Rational Development Process (RUP) (Incremental – модел)
 Итеративен фазен модел (животен циклус)
 Агилен развој на софтвер
 V модел
 Prototyping
 Спирален модел

1. Waterfall модел

Анализа на проблемот + дефиниција на барањата, интензивна кооперација:

Анализа на клиент договарач
барањата и Резултат: спецификација на барања, производен модел...

дефиниција
(II по приоритет) - Спецификација на структурата на
НАЈВАЖЕН софтверот, спецификација на компоненти и нивни врски

ЧЕКОР!!! ДИЗАЈН Резултат: софтверска архитектура, детализиран дизајн и

друго...
(Iпоприоритет)

Програмирање на
(Најскапи се грешките кои Имплемен компонтентите
настануваат во првиот чекор) тација Резултат: код

(III по приоритет)
Тестирање на компоненти Тестирање
Резултат: тест – случаи, тест – протоколи

2
 Употреба и
(IV по приоритет) – НАЈСКАП ЧЕКОР
одржување

2. Iterative and incremental development (Итеративен и инкрементирачки развој)

a. Итеративен – развојд во чекори, степенско подобрување на крајниот производ
b. Инкрементирачки – развој во чекори, независни делови од производот се развиваат
одделно
RUP (Rational Development Process) промовира итеративен развој и го организира развојот на
софтвер
4 фази, секоја се содржи од една или повеќе извршувачки итерации на софтверот во таа состојба на
развој. 4те фази се:
 Inception
 Elaboration (Елаборација)
 Construction (Конструкција)
 Transition (Транзиција)

3. Агилен развој на софтвер  Agile manifesto (12 принципи зад Agile Manifesto)
4. V модел – подобрување од Waterfall модел. Сигурност за квалитет (тестирање) е вклучен во
текот на целиот развоен процес.
5. Prototyping – Runnable софтверски системи (некои услови од системот се веќе завршени, а
други се уште треба да се извршуваат.
6. Спирален модел

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

проблемот
Цели
Алтернативи

Анализа на
ризик
Евалуација на
алтернативи

Конструкција на производ
Реализација Реализација на производ

3
 Планирање
(следни чекори
во проектот)

Преглед

Topic 03a - Агилен развој

 Што е АГИЛНОСТ?
o Ефективен одговор на промена. Ефективна комуникација помеѓу сите членови во
тимот. Внесување на корисникот во тимот. Нагласок на инкрементирачка
доставувачка стратегија
o Добро дизајниран агилен процес може да ја зарамни кривата на „трошок од
промена“ со инкрементирачка достава со агилни методи како што се:
континуирано единечно тестирање и програмирање во пар.
 ЕКСТРЕМНО ПРОГРАМИРАЊЕ (ХР)
o Најупотребуван агилен процес. Користи објектно-ориентиран пристап.
o ХР планирање
 Започнува со сослушување на корисникот кој објаснува (кажува „приказни“)
баран излез, можности, карактеристики и функционалност.
 Корисникот кажува вредност (приоритет) на секоја приказна, а агилниот тим
доделува „трошок“ на секоја од приказните.
 Стратегија е направена со видови на приказни:
 Сите приказни да се имплементираат во неколку седмици;
 Приказните со висок приоритет – ПРВИ;
 Најризичните приказни – ПРВИ;
o ХР дизајн (се случува и пред и после кодирањето)
 Го следи KIS принципот (Keep It Simple). Ни повеќе ни помалку од
прикажаното. Користи Refactoring
o ХР кодирање
 „Програмирање во пар“, односно двајца да работат заедно на една работна
станица, со сосем малку различни улоги.
o ХР тестирање
 Сите поединечни тестови се извршени и идеално треба да се
автоматизираат
 АДАПТИВЕН СОФТВЕРСКИ РАЗВОЈ (ASD)
4
 o Oд Jim Highsmith (2000), фокусирајќи се на човечка колаборација и тимска
самоорганизираност, како техника за градење на сложен софтвер и систем.
Составен е од три фази: Шпекулација, Колаборација и Учење.
o Шпекулација
 Проектот е инцииран и адаптирачки планирачки циклус е оформен.
 Тој користи проектна иницирачка информација која ја дефинира
корисничката мисија, противречностите на проектот и основни барања за
дефинирање на множеството од инкременти кои ќе бидат потребни за
проектот.
o Колаборација
 Ги величи комуникацијата и тимската работа, но исто така го нагласува
индивидуализмот, бидејќи индивидуалната креативност, игра важна улога
во колаборативносто размислување.

o Учење
 Развојувачите на софтвер често го преценуваат нивното познавање на
технологијата, процесот и проектот, па затоа учењето ќе им помогне да го
подобрат нивото на реално познавање.
 МЕТОД ЗА РАЗВОЈ НА ДИНАМИЧКИ СИСТЕМИ (DSDM) – многу сличен на ХР и/или ASD
 SCRUM
o Развојната работа е поделена на „пакети“. Тестирањето и документацијата се
прават како што се развива производот. Состаноците се многу кратки. Се
доставуваат demos до корисникот и тој дава feedback.
 CRYSTAL
o Всушност фамилија од процеси што овозможуваат управување и очи-во-очи
комуникација.
 FEATURE DRIVEN DEVELOPMENT (FDD)
o Нагласокот е на дефинирањето на карактеристики кои можат да бидат
организирани хиерархиски. Користи темплејт.

Topic 05 - Резултати од „Analysis and Definition“ фазата

 Се прави анализа на проблемот за да се реши, се дефинираат барањата од гледна точка на
корисникот.
o Всушност претставува опис на надворешното однесување на системот.
 Фазата се дели на две подфази кои генерираат 8 поединечни документи. Подфази се:
ПЛАНИРАЧКА и ДЕФИНИЦИОНА.
 Во ПЛАНИРАЧКАТА спаѓаат следните документи:
o Glossary (ги дефинира термините осигурувајќи унифицирање)
o Прелиминарна спецификација на барања

5
 o Одредување на трошоци
o Проект-план
 Во ДЕФИНИЦИОНАТА спаѓаат следните документи:
o Спецификација на барања СРЦЕТО НА AAD phase
o Продукт – модел (производен модел)
o Кориснички интерфејс
o User manual (прирачник за користење)
 Содржина на спецификацијата на барања:
o Функционални барања (функционалност, кориснички интерфејс)
o Барања за околина на апликација
o Технички барања (имплементациски јазик, оперативен систем, хардвер)
o Перформансни барања (ефикасност, количество на податоци)
o Валидирачки барања
o Квалитативни барања (user-friendliness, надежност)
 Реализирачки барања (процесен модел, документација, регулации, рокови, трошоци..)
 USE CASE дијаграм
o USE CASE = фундаментална функција на системот со вредност за корисникот,
реализирана од секвенца на интеракции помеѓу корисникот и системот.
o Релации помеѓу Use cases (UML): extend; include; generalize;
Topic 06 - Проценка на трошоци (Cost Estimation)

 Мерни единици за проценка на трошоците

o ММ (MY) – ManMonth (ManYear) – Луѓе-месеци (луѓе-години)
o LOC – Lines of Code – линии код
o Функциски точки
 Оптимално време за развој на сфтер
o Оптимално време за развој на софтвер = 2.5 * (Напор во ММ)ѕкаде што
 s = 0.35 за online системи
 s = 0.32за real time системи
o Број на вработени = MMs/време
 Влијателни фактор за проценка на трошоците
o Трошоците зависат од
 Големината на проблемот што треба да се реши (LOC)
 Барањата за квалитет
 Квалитетот на развојувачите (продуктивност)
 Искуството на компанијата со слични задачи
 Време на проценка на трошоците
o Трошоците треба да бидат проценети колку што е можно порано, односно на
почетокот на првата фаза (Analysis and Definition phase – AAD) и да бидат базирани
на првата пецификација на побарување или после првата фаза – базирани на
финалната функционална спецификација
 Основни пристапи за проценка на трошоци
6
o Метода на аналогија: Споредба на развојот за да се направи проценка на веќе
завршен развој на производ врз основа на критериуми за сличност
 Критериуми за сличност се:
 Иста или слична област на апликација
 Иста или слична големина на производ
 Ист или приближен степен на комплексност
 Ист програмски јазик итн..
o Метод на мултипликатор:
 Делење на системот на подсистеми
 Проценка на трошоците за подсистемите
 Вклучување на тежински фактори за комплексност
o Тежински метод:
 Одредување на фактор за проценка
 Реискористливост е важен атрибут, алгоритмите се малку сложени
 Пресметка со формула (тежински фактор)
 Метод на Функциски Точки
o Процентуален метод:
 Анализа на претходни проекти на компанијата
 Распределба на трошоци помеѓу посебни фази
 Трошокот на една фаза мора да е познат или треба да се процена со
различен метод екстраполација на целиот проект

o Метод на функциски точки

 Го измислил Allan J. Albercht
 Карактеристики:
 Релативно прецизен
 Субјективен
 Потребно е искуство за методот да се аплицира
 Индустриски стандард во методите за проценка на трошоци
 Предуслов: комерцијални апликации

o Генерален пристап (чекори)

 Чекор 1: Категоризирање на секое барање
 Чекор 2: Одредување на комплексност
 Секое барање се поставува во една од класите на комплексност
o Едноставно
o Средно или
o Комплексно
 Чекор 3: Пополнување на пресметковна форма
 Чекор 4: Евалуирање на барањето со оглед на влијателните фактори
 Чекор 5: Пресметување на тежински функциски точки
 Чекор 6: Поглед на трошоците во ММ

7
  Чекор 7: Надградба на практичните податоци

Topic 07 – Моделирање и модели на продукти

 Product model е сместен во AAD – Analysis and Definition фазата

 Product model ги прави текстуалните спецификации од барањата попрецизни, користејќи
основни пристапи
 Модел е идеализирана апстрактна репрезентација на еден дел од оригиналот (реалноста)
 Постојат два основни пристапи на Product model:
o Структурна анализа
o Објектно-ориентирана анализа
 Структурни методи
o Од крајот на 70тите
o Се уште широко распространети
o Функциски – ориентиран поглед (алгоритамски, процедурален)
 Податоците и функциите како независни единици
 Подточните текови опишани како трансформациско однесување на функциите
 Централна точка: дијаграми на податочен тек
 Објектно – ориентирани методи
o Од почетокот на 90тите
o Објектно – ориентиран поглед
o Објект: семантичка единица на податоци и функции
o Централна точка: класи како описни механизми за множества од слични објекти
Topic 08 - Основни концепти на функционалниот поглед

 USE CASE ДИЈАГРАМ

o Го објаснува интегритетот на use cases (бизнис процеси) и нивните врски, еден со друг
use case, како и со актерите.
 Актер е човек или друг систем надвор од предложениот систем
o Use case дијаграмот се користи за да го визуелизира, специфицира, конструира и да го
документира планираното однесување на системот, во текот на забележувањето и
анализирањето на барањата.
o Use case го специфицира посакуваното однесување. Претставува опис на множество од
секвенци на активности, вклучувајќи варијанти кои што системот ги врши за да
придонеси опслужлив резултат од вредност за актерот.
o Секоја секвенца репрезентира интеракција на актерите со системот.
o Специфицирање на однесувањето на еден use case значи:
 Опис на текот на настаните во рамките на use case-от може да се направи на
природен јазик, формален јазик или псевдо код.

8
  Тој вклучува: како и кога use case–от започнува и завршува; кога use case –от
има интеракција со актери и кои објекти се разменуваат; основниот тек и
алтернативните текови на однесувањето!
o Aктери:
 Еден актер репрезентира множество од улоги кои корисниците на use case-от ги
играат кога имаат интеракција со овие use case-ови.
 Актерите можат да бидат луѓе или автоматизирани системи.
 Тие се ентитети кои бараат помош од системот за да ја извршат нивната задача
или се потребни за да ги извршат функциите на системот.
 Актерите не се дел од системот.
o Use case-ови и Актери:
 Од перспектива на даден актер, еден use case прави нешто што е од вредност за
актерот. Актерите ги дефинираат околините во кои системот живее.
o Врски помеѓу Use cases (UML):
 GENERALIZEврска: use cases што се специјализирани верзии од други use-cases
 Детето-use case го наследува однесувањето и знаењето од родителот-use
cas, но може да додаде или да го преклопи однесувањето на неговиот
родител.
 INCLUDEврска: use case-ови што се вклучени како делови од други use cases
 Основниот (BASE) use case никогаш не останува сам. Тоа единствено се
случува како дел од некоја поголема база што го вклучува.
 Include врската овозможува да се избегне опишување на ист тек на
настани повеќе пати со поставување на заедничкото однесување во
засебен use case.

 EXTEND врска: use case-oви што го прошируваат однесувањето на други основни

use case-ови.
 Основниот (BASE) use case имплицитно го вклучува однесувањето на друг
use case во одредени точки наречени екстензивни (проширувачки) точки.
 Основниот (BASE) use case може да остане сам, но под одредени услови
неговото однесување може да биде проширено од однесување на друг
use case.
 Extend овозможува да го моделира опционалното однесување или
разгранување под услови
o Врски помеѓу use cases и актери:
 Актерите може да бидат поврзани со use cases со помош на асоцијации,
укажувајќи дека актерот и use case-от комуницираат еден со друг, со пораки.
o Use case во UML:

9
  Use case = фундаментална подфункција на системот (сервис на системот) со
вредност за корисникот, реализирана со секвенца од интеракции помеѓу
корисникот и системот.
 Функционален опис на системот = множеството на сите use cases
o Use case-овите можат да се опишат на неколку начини
 Текстуално
 со колаборациски дијаграм
 со секвенцијален дијаграм
 со дијаграм на активности
 со дијаграм на состојби
 петри мрежи

 Unified Modeling Language (UML)

o UML e индустриски стандарден јазик за специфицирање, конструкција, визуелизација
и документација на софтверски и хардверски системи.
o UML вклучува 9 вида на дијаграми:
 Use case дијаграм
 Класен дијаграм
 Интеракциски дијаграми:
 Секвенцен дијаграм
 Колаборациски дијаграм
 Дијаграм на состојби
 Објектен дијаграм
 Дијаграм на активности
 Компонентен дијаграм
 Распоредувачки дијаграм

o Use case дијаграм

 Покажува множество од use cases а актери и нивни врски, го адресира
статичкиот use case – поглед на систем, важен е во формирањето и
организирањето на однесувањето на системот.
o Класен дијаграм
 Покажува множество од класи, интерфејси и колаборации и нивни врски. Тој е
најопшт дијаграм користен во моделирање на објектно-ориентирани системи.
Го одресира статичкиот дизајнерски поглед на системот.
o Интеракциски дијаграм
 Го адресира динамичкиот поглед на системот. Постојат 2 типови на
интеракциски дијаграми:
10
  Секвенцијален дијаграм кој го потенцира времето на подредување на
пораки помеѓу објекти во системот.
 Колаборациски дијаграм кој ја потенцира структурната организација на
објектите кои праќаат и примаат пораки.
o Дијаграм на состојби
 Покажува машина на состојби која се состои од:
 Состојби
 Транзиции
 Настани
 Активности
 Овој дијаграм го адресира динамичкиот поглед на системот, го потенцира
однесувањето по настани на еден објект, и е посебно важен во моделирањето
на однесувањето на:
 Интерфејс
 Класа
 Колаборација
o Објектен дијаграм
 Покажува множество на објекти и нивните врски. Тој се фокусира на одредено
множество на објектни инстанци и атрибути, и врските меѓу инстанците
 Овој дијаграм е поконкретен од класниот дијаграм
o Дијаграм на активности
 Специјален тип на дијаграмот на состојби и го покажува текот од активност до
активност во рамките на еден систем.
o Компонентен дијаграм
 Ги покажува организационите зависности во склоп на м-во компоненти.
 Отсликува како компонентите се поврзани меѓусебно за да формираат
поголеми компоненти и/или софтверски системи.
 Се користи за да ја илустрира структурата на произволно комплексни системи
o Распоредувачки дијаграм
 Ја покажува конфигурацијата на run-time процесирачките јазли и компонентите
кои живеат во нив
 Го покажува хардверот за системот, софтверот кој е инсталиран на тој хардвер и
интерфејсот (middleware) кој се користи за поврзување на неспоредливи
машини

11