Функции руководителя дипломного проекта
Основными функциями руководителя выпускной квалификационной работы являются:
- разработка индивидуальных заданий;
- консультирование по вопросам содержания и последовательности выполнения выпускной квалификационной работы;
- оказание помощи студенту в подборе необходимой литературы;
- контроль хода выполнения выпускной квалификационной работы;
- подготовка письменного отзыва на выпускную квалификационную работу.
Дипломник периодически (по обоюдной договоренности) информирует научного руководителя о ходе подготовки дипломного проекта и консультируется по вызывающим затруднения вопросам.
Следует иметь в виду, что научный руководитель НЕ ЯВЛЯЕТСЯ ни соавтором, ни редактором дипломной работы, и студент НЕ ДОЛЖЕН рассчитывать на то, что руководитель поправит имеющиеся в дипломном проекте теоретические, методологические, стилистические и другие ошибки.
На различных стадиях подготовки и выполнения дипломного проекта задачи научного руководителя изменяются.
На первом этапе научный руководитель консультирует в выборе темы, рассматривает и корректирует план работы и дает рекомендации по списку литературы.
В ходе выполнения работы научный руководитель является оппонентом, указывая дипломнику на недостатки аргументации, композиции, стиля и т.д. и рекомендует, как их лучше устранить.
Законченная пояснительная записка, подписанная дипломником, представляется руководителю, не позднее, чем за 7 дней до защиты.
|
|
|
По завершении студентом выпускной квалификационной работы руководитель подписывает ее и вместе со своим письменным отзывом передает рецензенту.
Общие требования к программным продуктам
Требования к программам
Независимо от конкретности проблемы, можно выделить некоторые формальные требования, которые предъявляются к разработанному программному продукту:
- устойчивость программы: программа не должна терять работоспособности ни при каких даже некорректных действиях пользователя; всякие действия, грозящие потерей информации, выполняются только после повторного подтверждения; вводимая информация там, где возможно, подвергается логическому контролю;
- обеспечение целостности баз данных: при любых действиях пользователя базы не должны терять целостности;
- функциональная полнота: в рамках согласованного с руководителем подмножества функций все они должны быть реализованы;
- терминологическая среда и интерфейс: в диалоговых средствах используются только термины, понятные пользователю, и не используются термины разработчика («запись», «индексация» и т. д.); появление служебных англоязычных сообщений недопустимо; язык диалога — с соблюдением норм вежливости; цветовая гамма — по общепринятым рекомендациям;
|
|
|
- использование клавиатуры: на любом этапе нажатие любой клавиши (особенно функциональных) должно игнорироваться или вызывать предусмотренные действия (описанные в средствах помощи); привязка действий к клавишам должна быть общепринятой: F1 — помощь; Enter — согласие, завершение ввода; Esc — отказ, возврат к предыдущему узлу ветви алгоритма (с восстановлением экранной формы); Tab — переход к следующему полю, окну и т. д.; Shift-Tab — возврат к предыдущему полю и т. д.
- порядок движения: движение по дереву алгоритма «сверху вниз» сопровождается заголовками всех пройденных вершин; возврат возможен только на предыдущий уровень с сохранением введенной информации, выбранных пунктов меню и указателей записей;
- средства помощи и реклама: при запуске программы появляется рекламная заставка, отражающая суть и возможности программного средства, а также сведения об авторе; в любой точке алгоритма в строке подсказки должны высвечиваться все активные в данный момент горячие клавиши; в любой момент при нажатии клавиши F1 должен выдаваться контекстно-зависимый (зависящий от ситуации) текст помощи;
|
|
|
- входные и выходные документы: экранные формы для ввода и корректировки должны быть максимально «похожими» на привычные для пользователя документы; результаты работы не только отображаются на экране, но и выводятся в привычной для пользователя форме на печать;
- средства документации: программный код должен содержать внутреннюю документацию в виде комментариев.
Требования к Web-документам
Проекты, созданные в виде Web-страниц должны выполняться в соответствии с требованием руководителя и подчиняться общепринятым правилам Web-дизайна и Web-этикета:
- каждый HTML документ должен быть хорошо структурирован и содержать основную информацию о его происхождении: автор, дата создания, контекст документа и его статус, адрес (URL) документа;
- стиль оформления: проект выполняется в едином стиле (то есть при создании должны быть использованы шаблоны или CSS);текст должен быть контрастным и прекрасно читаться;
- фон сайта: при выборе цвета фона необходимо учитывать, как он будет гармонировать со следующими элементами: цветом текста, цветом гиперссылок, с логотипами или фирменными эмблемами;
|
|
|
- элементы навигации: необходимо обеспечить достаточный цветовой и яркостный контраст между навигационными элементами и фоном; система навигации не должна отягощать страницу, не должна отвлекать от ее содержимого, но должна быть легко доступна; элементы локальной навигации желательно визуально отделять от элементов глобальной;
- гиперссылки: при указании ссылок в документе необходимо проверить работоспособность каждой ссылки;
- синтаксис и семантика: содержательное наполнение сайта должно соответствовать заявленному объему; уровень синтаксических и семантических ошибок необходимо сводить к минимуму;
- использование графики: графические объекты и элементы анимации необходимо гармонично встраивать в соответствии с текстом; наличие каждого элемента должно быть логически оправданным;
- желательно чтобы сайт нормально выглядел как в различных программах просмотра и в разных режимах монитора (640X480, 800X600, 1024X784);
- объем и сложность проекта должны быть на уровне программных разработок.
Разработанные Web-проекты будут размещены на Web-сервере МКЭиИТ.
Дата добавления: 2018-08-06; просмотров: 300; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!