Оценочный лист для члена гак

№	Ф.И.О. студента	Средний рейтинг за весь период обучения)	Оценка руководителя	Оценка за систему	Показатели работы	Показатели защиты	Итоговая оценка работы члена ГАК	Вопросы и замечания члена ГАК
Актуальность работы (до 15)	Оригинальность и новизна полученных результатов (до 15)	Практическая ценность (до 20)	Качество представления работы в т.ч. в ПЗ (до 20)	Качество доклада (до 15)	Уровень ответов на вопросы (до 15)
1	2	3	4	5	6	7	8	9	10	11	12	13

Ф.И.О. члена ГАК ___________________________________ Подпись: ________________ Дата: _______________

Оценка программных систем, представляемых к защите

 

Для оценки реализации системы студент должен предъявить:

1) комплект документации: ТЗ, ТП, РП с необходимыми приложениями (в т.ч. Руководство оператора (пользователя), Руководство системного программиста, Спецификация);

2) работающую программу;

3) исходный код программы.

Каждая работа оценивается минимум 2-мя уполномоченными экспертами из состава преподавателей и аспирантов кафедры, имеющих опыт в реализации коммерческого программного обеспечения.

Демонстрация работы программы может осуществляться как на компьютере университета (в этом случае студент должен самостоятельно принести установочные версии всех необходимых библиотек и программ), так и на собственном компьютере студента.

Содержание документации должно соответствовать требованиям настоящих методических указаний, соответствующим ГОСТ, текст должен соответствовать требованиям технического языка. Критерии оценки программных систем соответствуют ГОСТ Р ИСО/МЭК 9126-93.

Оценка программ является обязательной для допуска к защите. Минимальная оценка для допуска к защите – 61 балл.

Критерии оценки программных систем

Функциональные возможности

Учитывается степень реализации основных и дополнительных функций системы в соответствии с техническим заданием. При этом учитывается функциональная сложность системы.

Форматы используемых данных и протоколы работы с устройствами и библиотеками должны соответствовать требованиям, описанным в документации.

 

Надежность

Все вводимые данные должны проверяться на соответствие требованиям, заявленным в документации. При ошибках ввода должны выдаваться предупреждения (либо производиться коррекция введенных значений). Для строк, передаваемых в запросах к СУБД, должны применяться преобразования защиты от SQL-инжекции.

Программа не должна «вылетать». Все исключения должны обрабатываться программно. При сбоях выполнения системных функций (например, работа с файлами, соединение с БД и т.п.) должны выдаваться соответствующие сообщения. Завершение работы программы при сбоях не должно приводить к повреждению открытых файлов или невозможности повторного запуска программы.

Практичность и эргономичность

Интерфейс программы должен соответствовать общепринятым принципам построения пользовательского интерфейса (класса систем) либо прототипу или быть интуитивно понятным.

В интерфейсе системы и ее информационном наполнении не должно содержаться орфографических ошибок. Элементы управления должны быть выровнены и подписаны в соответствии с выполняемой функцией. Выравнивание должно сохраняться при изменении размеров окон.

Оценивается возможность пользователя оперативно управлять программой (наличие "быстрых клавиш", удобство меню и панелей инструментов), возможность настройки интерфейса под себя.

Оценивается наличие и полнота справочной системы (или руководства пользователя), контекстные подсказки.

Эффективность

Программа не должны использовать больше ресурсов (памяти, дискового пространства, устройств), чем необходимо для выполнения ее функций. Все используемые ресурсы должны освобождаться после окончания использования. Для критичных ко времени участков кода должны использоваться более быстрые алгоритмы.

Время реакции на действия пользователя должно удовлетворять требованиям документации и здравого смысла.

Сопровождаемость

Оценивается качество и полнота руководства программиста и технического проекта, а так же оформление исходного кода программы.

Архитектура системы и структура БД должны соответствовать заявленным в документации.

Качество исходного кода программы:

- Исходный код должен быть модульным, форматирован отступами, размер функций (методов) обозримый (не более 50 строк). В исходном коде должны быть обозначены модули и подсистемы в соответствии с архитектурой, описанной в документации.

- Имена переменных, классов, файлов, элементов управления должны быть описательными.

- В коде должны быть комментарии (описания назначения и параметров функций, классов, пояснения к алгоритмам работы). В БД поля таблиц должны содержать комментарии.

- В коде по возможности должны использоваться структуры данных и алгоритмы из стандартной библиотеки языка (кроме случаев, когда они не удовлетворяют требованиям к системе)

Если используется соглашение об оформлении кода (coding standards), необходимо сослаться на документ, в котором оно описано.

Мобильность

В руководстве администратора должны быть подробно описаны процедуры внедрения (установки), конфигурирования и тестирования системы.

В комплекте поставки программы должны присутствовать инсталляторы все используемых ей библиотек и сторонних программ (если это не нарушает их лицензии).

Если процесс внедрения (установки) системы требует внесения изменений в файлы и каталоги операционной системы, необходимо наличие программы-инсталлятора.

Конфигурирование должно осуществляться либо через интерфейс основной программы (или специальной программы-конфигуратора) либо с помощью конфигурационных файлов. Все настройки должны быть описаны в руководстве администратора.

Используемые системой форматы хранения и передачи данных, а так же протоколы взаимодействия с внешними программами и устройствами должны соответствовать существующим стандартам (либо обосновать создание собственных). На оценку системы влияет требования к тиражируемости согласно ТЗ.