2 noit errors_all

Често срещани грешки

• Липса на:– оригиналност

напр. темата е разглеждана многократно (самоцелни проекти) и/или нейното представяне в проекта не се отличава от съществуващите

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

– отношениенапр. липсва отношение към разработката(влияе негативно върху цялостното въздействие)

ФаталниФатални

27.6.2013 г.Национален квалификационен семинар

за учители по ИТ, Пампорово 26 – 28.06.2013

2

• Липса на стилнапример:– има недобра подредба и именуване на файлове– всички файлове в една папка на диска, няма дори

яснота кой файл да се стартира– използване на имена на обекти по подразбиране

(напр. var1, var2, var3)– смесване на прекалено много различни графични

стилове като цветове, форми, шрифтове

При всичкивсички направленияПри всичкивсички направления



3

• Липса на етиканапример: - Използват се чужди материали / код без правилно цитиране.Текстово описание, което е 1:1 копирано от друго място. Буквално копиране се допуска само при цитиране.- Не е упоменато в документацията кои елементи са авторски и кои са адаптирани от чужди готови компоненти, програми, съдържание и т.н.

НЕ Е ГРЕШКА, НО БУДИ СЪМНЕНИЕ!• Масово използване на trial версии• Правени за няколко месеца с trial на продукта е 30 дена

При всичкивсички направленияПри всичкивсички направления



4

• Пресрочване на времето• Липса на контакт с аудиторията

например: поглед само към екрана, чете от слайдовете

• Стъписване при възникване на технически проблем

• Невъзможност за отговор на елементарни въпроси

Често срещани грешки при представяне

Често срещани грешки при представяне



5

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

• Масово използване на trial софтуер

• Деклариране, че е ползван trial софтуер, а всъщност не е ползван такъв

Препоръка:• Да се намират алтернативи (включително и

безплатни) за създаване на съответното съдържание



6

Документация

• Сгрешени данни в придружаващата документация (имена, подписи, и т.н.)

• Еднотипни документации, в които само имената са подменени

• Непълно и неточно описание на проекта и ползваните ресурси

• Ползване на документация от друго състезание (напр. УС на УчИМИ)



7

Документация – препоръки

• Да се проверява документацията, дори и за нещата, в които човек е абсолютно сигурен

• Да се създава документация към проекта, а не да се адаптира от друг проект

• Да се създава документация за конкретното състезание по приложения образец/изисквания



8

Външни компоненти

• Самоцелно използване на компоненти – кръстословици, лабиринти, тестове

• Компоненти, които е неясно как се ползват

• Необходимост от инсталиране или конфигуриране на допълнителен софтуер



9

Препоръки

• Да се използват компоненти, които се интегрират добре в проекта и не биха изисквали инсталация в масовия случай

• Да се включват само компоненти, които са наистина необходими за проекта



10

Файлове

• Липсващи файлове

• Файлове с имена на кирилица, шльокавица или с неподходящо съдържание

• Натрупване на много и различни файлове в една директория



11

Препоръки

• По възможност да се изпробват проектите на различни компютри

• Да се подсигури, че след копиране на друго място, проектът пак работи

• За имена на файлове да се избират такива, които са допустими за различни ОС



12

МУЛТИМЕДИЯ, УЕБ-САЙТМУЛТИМЕДИЙНИ ПРИЛОЖЕНИЯ



13

Навигация и бутони

• Неработещи бутони, липсващи връзки и дори липса на нужна навигация

• Бутони, които трудно се различават от околните елементи

• Интерактивни елементи с прекалено малка или с отместена активна зона



14

Препоръки

• Всички връзки да се проверяват

• Проектът да се изпробва с хора, които не са участвали и наблюдавали създаване му



15

Текстово съдържание

• Монументално количество правописни и граматически грешки

• Грешки в излагането на факти и твърдения

• Несъразмерно обемни текстове



16

Препоръки

• Да се проверяват текстовете, ако трябва бавно и детайлно. При съмнение, да се пита по-опитен приятел или учител

• В кадър да няма повече текст, отколкото би било добре да се въведе в ... два SMS-а

• По-добре лаконични, отколкото локумични



17

Графика и ефекти

• Несъгласувани цветове между текст и фон

• Графични ефекти, които са уморително бавни или прекалено различни

• Ниска резолюция на изображения, ръбести контури, неподходяща подмяна на фон



18



19

Препоръки

• Да се проверява доколко хармонични са избраните цветове

• Да се обработват картинките добре – както контурите им, така и “вътрешността”

• Да се “тестват” проектите с други хора. Ако те неволно поискат да прескочат някоя анимация, вероятно тя е прекалено бавна



20

Права на съдържанието

• Буквално копиране на текст от Wikipedia, Pomagalo и други места

• Некоректно използване на изображения, клипове, звукови ефекти

• Незачитане на правата и задълженията, които носят различните лицензи



21

Препоръки

• Сайтове, които предоставят свободно съдържание, имат изисквания, които задължително трябва да се съблюдават

• Да не се приема, че ако нещо е намерено безплатно, значи то е безплатно

• Да се преразказва текст, да не се копира



22

Мултимедия: Презентации и слайдове

• Огромни презентации от над 100 слайда

• Слайдове, които много трудно се разглеждат в режим на дизайн – десетки насложени един над друг елементи

• Невъзможност да се прекъсне или да се прескочи анимация



23

Препоръки

• Да се следи за качество, а не обем

• Слайдовете да се проектират така, че да може лесно да се поддържат и коригират



24

Уеб-сайт

• Неработещи връзки• „Осиротели“ страници – не може да се

стигне до тях• Празни страници



25

Мултимедйни приложения

• Липса на интерактивност,интерактивност,

т.е. НЕ е приложение



26

ИНТЕРНЕТ ПРИЛОЖЕНИЯПРИЛОЖНИ ПРОГРАМИ



27

Спазване на регламента

• Разработки от други състезания със съвсем друг регламент

• В този си вид НЕ са подходящи за Олимпиадата

• Трябва да има създаден реален продукт (система)– напълно функциониращ– предоставящ всички необходими за потребителя

функции

• Прототипи нямат големи шансове на Олимпиадата



28

Заглавия на проекти

• Масово на английски език

• От следващата година ще намаляваме точки за това!!!



29

Цели на проекта

• Приложението изглежда самоцелно• Не е ясно

– Какъв специфичен проблем се разглежда – Коя е целевата група– Какви съществуващи решения са проучени– С какъв проблем се „бори“ приложението



30

Описание на проекта (1)

• Потребители• Има ли подобни системи• Защо се налага да се създаде конкретният

проект• Как точно е проектирана системата• Как са избрани технологиите и защо



31

Описание на проекта (2)

• Какви основни компоненти са разработени• Как са интегрирани• Какво е ползвано и какво е оригинална

разработка на учениците• Как е тествана системата с реални

потребители• Какви са техните мнения и оценки ...



32

Достъпност

• Приложни програми: лесна инсталация и деинсталация

• Интернет приложения: Достъпно в интернет през цялото време!!!

• Тестови акаунти за различните роли• Тестова база от данни



33

Качества на системата

• Да е максимално гъвкава• Да могат лесно да се добавят нови или

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

• Да се избягва задаване на статични стойности на параметри в кода

Да се ползват конфигурационни файлове или модули за настройки.

•Адекватна обработка на грешки



34

Ефективност на кода

• Многократно писане/копиране на един и същи код

Препоръка: Да се организира в подпрограма, клас и т.н.

• Липса на бързодействие



35

Представяне

• Демонстрация на системата – за не повече от 10, максимум до 15 минути

• Ясно, силно, разбрано• По възможност – атрактивно• Готовност за отговор на всякакви въпроси,

включително и подробности около кода, за системата



36

ПРЕПОРЪКИ



37

Фукционалност

• Фокус пред функционалностНе добавяйте излишна

функционалност



38

Качество на кода

• Принципи на ООП – SOLID:– Single responsibility– Open/closed– Liskov substitution– Interface segregation– Dependency inversionhttp://en.wikipedia.org/wiki/SOLID_(object-oriented_design)• Шаблони за дизайн (Design patterns)• Проучване на добри практики



39

http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

Консистентност в кода

• Именуване на програмни единици• Форматиране• Коментари• Спазване на конвенциите



40

База от данни

• Нормализация!



41

Инструменти и трикове

• Правете си план• Версии (Version control)• Добри специализирани редактори• UML диаграми• Ясно отделена отговорност – пример:

конфигурационния файл съдържа само параметри



42

Сигурност

• OWASP• Входните данни се "филтрират" преди да се

работи с тях или да бъдат записани• Изходните данни се "кодират" преди да

бъдат показани.• Ползвайте инструмент за сканиране за

дупки в сигурността – w3af, acunetix



43

Тестове

• Писане на автоматични тестове• Unit тестове• Функционални тестове – Selenium• Тествайте с реални потребители



44

Край

“ Нещо е съвършенно, не когато няма какво да му се добави, а когато няма какво да му се махне”

А. Екзюпери

Education

2 noit errors_all