1. РАЧУНАРСТВО ИЗМЕЂУ ПРАКСЕ И ИСТРАЖИВАЊА
Давор Шутић

2. Зашто?
Шта?
Како?

3. Schneider Electric DMS NS
Главна делатност: развој софтвера за управљање електро-енергетским системима
Акценат на „паметној мрежи“ (тзв. Smart grid)
Производ: АДМС
Тим од око 800 инжењера различитих специјализација
Интензивна сарадња са Универзитетом у Новом Саду

4. Schneider Electric DMS NS

5. Schneider Electric DMS NS

6. SCADA - појам Supervisory Control And Data Acquisition
Систем за даљинско управљање и надзор
Критичан систем за рад у реалном времену
Инфраструктура на којој се заснивају функције АДМС

7. SCADA - изазови Комуникација с тереном (телеметрија) База података
Стабилна мрежна инфраструктура
Индустријски протоколи (DNP3, Modbus, IEC104)
База података
Брз приступ без изгладњивања за мноштво процеса
Капацитет (неколико милиона тачака)
Опоравак од квара
Прелазак на помоћни систем
Одржавање конзистентности
Презентовање кориснику
Мноштво догађаја, који траже акцију

8. SCADA – преглед функционалности

9. SCADA – значај критичности
Испади и кашњења могу довести до великих материјалних трошкова и угрозити животе
Велики број тачака (државе/градови до гранулације појединачног дома)
Систем ради без престанка (24 часа/365 дана)
Прелазак на резервни систем
Константна репликација података
Кратак временски период (неколико секунди)
Људски фактор
Аларми и догађаји изискују реакцију
Поузданост команди

10. Развојни процеси – Модел водопада
Секвенцијални процес
Преузет из „физичких“ индустрија и примењен на развој софтвера
Претпоставка: накнадне измене су изузетно скупе
Користи се још од 1950-их

11. Развојни процеси – Модел водопада
Фазе развоја:
Захтеви продукта (документи)
Анализа (модели, шеме, ...)
Дизајн (архитектура решења)
Писање кода (развој, системска интеграција, ...)
Тестирање (проналажење и уклањање дефеката)
Подршка (инсталација, одржавање, ...)

12. Развојни процеси – Агилни приступ
Итеративни процес
Одговор на „традиционални“ инжењеринг
Примена на комплексне и динамичне пројекте
Тешко се долази до тачних процена и стабилних планова
Детаљан дизајн на почетку доводи до губитака
Циљеви:
Прилагодљивост пре предвидивости
Итерације пре секвенцијалног развоја
Код пре документације
Мулти-функционалан тим

13. Развојни процеси – Агилни приступ
Принципи:
Задовољни клијенти и континуална испорука
Прихватити промене захтева
Функционалан продукт се често испоручује
Блиска сарадња менаџмента и развојних тимова
Поверење у индивидуалне и мотивисане особе
Ко-локација људи
Функционалан продукт је мера успеха
Одржив развој – константна брзина
Добар дизајн и техничка вештина
Једноставност – максимум не-одрађеног посла
Само-организација тимова
Ретроспектива и само-унапређивање тимова

14. Развојни процеси – Агилни приступ

15. Тестирање
У традиционалном моделу водопада, тестирање је остављано за крај пројекта
Углавном засебна група људи
Реалност: то време се користи за компензацију кашњења у „главном“ пројекту
Већ је касно за откривене недостатке
Исправљање одузима време од тестирања
Када ће се тестирати исправљени код?
А исправљени исправљени код?

16. Тестирање Агилно тестирање није посебна фаза, већ саставни део развоја
Агилно тестирање није посебна фаза, већ саставни део развоја
Активност целог тима, не само посвећених тестера
Временом пружа чврсту базу за стабилност производа
Инкременти не смеју да нарушавају постојеће тестове
Служе као доказ функционалности
Штеде време, јер се могу аутоматизовати (нпр. извршавање пре сваке промоције кода, ноћу, итд.)

17. Тестирање Модуларно тестирање – Unit testing
Фокус на једном модулу – обично функција
Циљ је да се тествима прођу све путање извршавања
Покривеност кода
Тежи се да се занемари утицај других компоненти (тзв mocking, faking, итд.)
Одатле долази и огромни значај интерфејса у развоју

18. Тестирање

19. Тестирање

20. Развој вођен тестирањем
TDD – Test Driven Development
„Ово не може да се тестира“
Приступ да се прво пише тест, па код
Циклус:
„црвено“ – тест који тестира жељену функционалност, али тренутно не пролази
„зелено“ – изменити код да сви тестови пролазе
„рефактор“ – чишћење кода (промена хијерархије, реорганизација јединица кода, додатна функционалност, итд.)
Мали број измена између тестова (<10)
Нови код треба брзо и минимално да задовољи тестове

21. Развој вођен тестирањем
Структура теста:
Припрема окружење
Извршење функционалност која се тестира (позив методе)
Валидација резултата
Тестови треба да буду кратки и брзи
Идеално се извршавају при сваком компајлирању пројекта
Идеално се валидира само један резултат (више резултата → више тестова)
Идеално се тестовима посвећује исто толико пажње колико и продукционом коду

22. Развој вођен тестирањем
Предности:
Брз одзив
Стабилни инкременти – „гаранција“ исправности
Велика покривеност кода тестовима (до 100%)
Фокусира програмера на дизајн и на то како ће клијенти да користе његов код
Мане:
Не дозвољава импровизацију
Не замењује друге врсте тестова (функционалне)
Троши додатно време за имплементацију и одржавање
Проблем лоших тестова – лажна сигурност
Више уметност него наука

23. Значај истраживања Рачунарство је наука која се брзо мења
Праћење трендова:
Академско (нпр. нови алгоритам)
Технолошко (нпр. нови развојни пакет)
Научни метод даје резултате истраживања
Резултати се објављују у научним часописима и конференцијама
Поступак рецензије потврђује резултате
Проблем: Практична примена резултата касни и представља изазов за себе

24. Шта је докторат?

25. Захтеви за SCADA-у на облаку
Изоловане три целине:
Принцип претплате и објављивања
Безбедност у облаку
Репликација у облаку
Закључци:
Потребан је развој међуслоја, који би чувао систем и апстраховао облак
Постоји безбедносни ризик – критичан систем у туђој надлежности
Настанак додатних трошкова одржавања

26. Захтеви за SCADA-у на облаку

27. Управљање нитима на вишем нивоу
SCADA систем има велики број процеса (>100)
Критичан ресурс: база података
Оперативни систем наивно додељује ресурсе и преузима ток извршавања нити
Може да дође до чекања или изгладњивања критичних секција при приступу бази
Карактеристично је да се процеси углавном врло дуго извршавају

28. Управљање нитима на вишем нивоу
Идеја:
Алгоритам који би пратио нити специфичне за SCADA систем на вишем нивоу
Прикупља податке о томе колико се која нит такмичи с другим које се у исто време извршавају
Доноси одлуку на крају критичне секције једне нити о томе која ће следећа нит да се извршава:
Следећа нит мора имати минимум дељених критичних ресурса с нитима које се тренутно извршавају
Не сме доћи до изгладњивања спорих или захтевних нити
Главни изазов: алгоритам мора бити ефикасан, а довољно брз

29. Закључак

30. Хвала на пажњи