В конкурсе может участвовать любой желающий, чья разработка соответствует параметрам по юзабилити и техническим требованиям, заявленным организаторами. С полным перечнем критериев оценки работы можно ознакомиться на сайте academy.infotecs.ru/ в разделе «Соревнование». На конкурс участникам необходимо представить техническое описание собственного решения и скомпилированный код с инсталлятором, позволяющим автоматически установить приложение.
Максимальный приз составляет 350 000 рублей, размер денежного вознаграждения зависит от количества критериев, которому отвечает присланная на конкурс работа.
Заявки и конкурсные работы будут приниматься до 15 июля 2014 года включительно путем регистрации в Личном кабинете и заполнения заявки на сайте academy.infotecs.ru/ либо по e-mail academy@infotecs.ru
Решаемая задача: разработка универсального кроссплатформенного программного кода для создания отчетов (генератор отчётов) на основе БД.
Передаваемые участнику материалы: дамп БД.
Подаваемые участником материалы: скомпилированный код с инсталлятором, позволяющим автоматически установить приложение, техническое описание особенностей реализации, заявка на участие по выбранной задаче в рамках формата «Соревнование» – подаётся через Личный кабинет.
Требования: генератор отчетов должен использовать не более 300 МБ оперативной памяти, переключение между страницами отчёта должно занимать менее 3 секунд, (оценка скорости переключения будет проводиться опытным путем). Генератор отчетов должен работать в двух режимах: в режиме дизайна отчета и в режиме отображения отчета. В режиме отображения отчёта на основе шаблона должна быть реализована возможность сохранения отчёта в форматах PDF, RTF; виды отчётов – группировка данных по признаку, выделение (highlight) значений по условию. Простой отчет без группировки, состоящий из 5 колонок и 10 тысяч строк, должен формироваться менее, чем за 5 секунд, а с группировкой по одному признаку – менее, чем за 10 секунд.
Условия реализации: x64/x86, используется СУБД, поддерживающая SQL-92 (желательно Postgres 9.1), допускается использование сторонних open source-библиотек. Запросы к базе данных должны поддерживать стандарт SQL-92. Генератор отчета должен быть построен на клиент-серверной технологии. Серверная часть, ответственная за соединение с базой данных и формирование отчетов, должна быть построена на Java и должна поддерживать функционирование под управлением Apache Tomcat. Клиентская часть должна иметь веб-интерфейс, использующий JavaScript, и функционировать в следующих браузерах: Internet Explorer 9+, FireFox 24+, Google Chrome 28+. В качестве БД (серверная часть) должен использоваться дамп БД, полученный от Организаторов.
Функциональные требования: Модуль отчета должен иметь веб-интерфейс и для доступа к базе данных использовать Connection String, применяя наборы view для получения информации о наборах данных, доступных для работы, и их составе.
Наборы view:
TABLE_VIEW
| Имя поля | Тип поля | Примечание |
| ID | integer | Идентификатор таблицы |
| TABLE_NAME | Varchar(255) | Имя таблицы |
FIELD_VIEW
| Имя поля | Тип поля | Примечание |
| ID | integer | Идентификатор поля |
| FIELD_NAME | Varchar(255) | Имя поля |
| FIELD_TYPE | Varchar(255) | Тип поля |
| IS_NULL | boolean | Признак обязательности |
RELATIONS_VIEW
| Имя поля | Тип поля | Примечание |
| ID | integer | Идентификатор связи |
| PARENT_TABLE_ID | integer | Родительская таблица |
| CHILD_TABLE_ID | integer | Дочерняя таблица |
| PARENT_FIELD_ID | integer | Родительское поле |
| CHILD_FIELD_ID | integer | Дочернее поле |
Режим дизайна отчёта
В режиме дизайна отчета генератор отчета должен позволять создавать WYSIWYG-шаблоны, по которым будет строиться отчет. Пользователь должен иметь возможность создавать шаблон на основе данных из набора данных, предоставленных базой данных. Созданные шаблоны должны быть сохранены локально в формате XML. В отчете должна быть возможность использовать шапки, подвалы, панели данных, метки, изображения.
Режим отображения отчета
В данном режиме должна быть реализована возможность отображения отчета на основе ранее созданных шаблонов, а также сохранения сформированного отчета в различных форматах (PDF, RTF – основное требование; XLSX, XML – дополнительное; см. разделы: «Требования» и «Дополнительные требования»). Так же должна быть реализована возможность отображения WYSIWYG-отчета в отдельном окне для вывода на печать.
Критерии оценки: участники предоставляют на конкурс техническое описание и скомпилированный код с инсталлятором, позволяющим автоматически установить приложение. Тестирование проводится на стороне Организаторов (параметры стенда: Windows Server 2008 R2 64bit, Intel Core i7 3Ghz, 8Gb RAM), результаты фиксируются и публикуются в общем зачёте. Оценка параметров реализации каждого из участников доступна публично.
В качестве результата берётся средневзвешенное значение всех критериев оценки (см. разделы: «Требования», «Условия реализации»), например, подсчитывается количество видов отчетов, поддерживаемых приложением, оценивается минимальное время переключения между отчётами (страницами отчёта). Аналогичным образом участникам засчитываются бонусные очки за выполнение наибольшего количества дополнительных требований, включая юзабилити.
Дополнительные требования (общие)
Дополнительные требования добавляют очки участникам при условии выполнения основных требований и включают следующее:
- Виды отчётов:
- Группировка по диапазону;
- Кросс-таблица;
- Многоколоночный отчет;
- Отчет в виде карточек;
- Master-detail-отчет;
- Сохранение отчёта в форматах: XLSX, XML.
- Поддержка математических функций, функций работы со строками и датами, счетчика страниц.
- Сортировка по табличным параметрам.
- Поиск по отчету.
Дополнительные требования (юзабилити)
Дополнительные требования, относящиеся к требованиям юзабилити, также добавляет очки участникам при условии выполнения основных требований. Оценка юзабилити-программы проводится на основе следующих критериев (рассматривается как бальная оценка эквивалентными позициями):
1. Рекомендуется использовать стиль «Metro Style».
2. Всегда должна быть возможностьопределить, в каком состоянии находится система.
3. Должно быть легко понять, какая информация доступна в данном месте.
4. Должно быть очевидно, какие элементы являются «операбельными».
5. Должно быть ясно, что будет происходить при взаимодействии с элементом.
6. Представленная информация должна соответстввовать ожиданиям.
7. Должно быть понятно, куда можно перейти из текущего места.
8. Все функции должны быть четко и понятно обозначены.
9. Не должны использоваться «лишние» технологии.
10. Назначение элементов управления, их расположение и наименования должны быть согласованы во всем интерфейсе.
11. Ссылки и меню должны использоваться и отображаться согласно принятым веб-стандартам.
12. Сайт должен корректно отображаться во всех основных браузерах.
13. Названия ссылок должны соответствовать заголовкам страниц, на которые они ведут.
14. Поведение программы должно соответствовать ожиданиям.
15. Программа должна минимальное использовать помощь, подсказик, инструкции.
16. Поля форм должны создавать представление о вводимой информации или содержать краткие подсказки.
17. Не должно требоваться запоминание всех действий, объектов и опций, видимых на экране, для того, чтобы ими воспользоваться.
18. По внешнему виду элементов из прошлого опыта должно быть легко установить, как с ними взаимодействовать.
19. Все возможные действия должны быть четко обозначены.
20. Метки и ссылки должны иметь наглядные и понятные описания.
21. Ключевые функции программы должны быть доступны во всех экранах.
22. Визуальные решения сайта должны быть лаконичными и читаемыми.
23. Абзацы должны быть короткими.
24. На странице должно быть достаточное количество свободного пространства – «воздуха».
25. Сайт не должен содержать лишней анимации и не несущих нагрузку изображений.
26. Графический дизайн должен соответствовать контексту.
27. Страницы должны быть организованы по четко читаемой структуре и содержать необходимые детали.
28. Интерфейс должен давать пользователю возможность восстановления после ошибки.
29. Сообщения об ошибках должны быть показаны на языке, понятном пользователю.
30. Сообщение об ошибке должно максимально точно описывать проблему и предлагать решение.
31. Формы и поля ввода должны восстанавливать значения после сбоя или ошибочного принятия (submit).
32. Интерфейс должен содержать систему помощи.
33. Помощь должна быть сфокусирована на задачах пользователя и содержать список конкретных шагов.
34. Помощь не должна быть большой.
35. Подсказки в интерфейсе должны быть информативными.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий