- •Оглавление
- •Введение
- •Общие требования к программным продуктам
- •1. Требования к программам
- •2. Требования к Web-документам
- •Тематика дипломных проектов
- •Руководство дипломным проектом
- •Рубрикация дипломного проекта
- •Требования к дипломному проекту
- •Структура дипломного проекта
- •Характеристика разделов дипломного проекта
- •1.1 Сравнительный анализ существующих информационных систем
- •1.2 Техническое задание
- •1.3 Описание и исследование предметной области
- •1.4 Проектирование системы
- •1.5 Выбор и обоснование инструментальных средств разработки аис
- •2. Разработка автоматизированной информационной системы
- •2.1. Разработка таблиц базы данных
- •2.2. Разработка запросов к базе данных
- •2.3. Разработка форм ввода данных
- •2.4. Разработка отчетов
- •2.5. Разработка меню пользователя
- •3. Безопасность информационной системы
- •4. Экономическая эффективность проекта
- •4.1. Выбор и обоснование методики расчета экономической эффективности
- •4.2. Расчет показателей экономической эффективности проекта
- •4.2.1. Стоимость разработки программного продукта
- •4.2.2 Расчет текущих затрат
- •1Рекомендации по процедуре защиты дипломного проекта
- •2Рецензирование выпускных квалификационных работ
- •Список рекомендуемой литературы
Общие требования к программным продуктам
1. Требования к программам
Независимо от конкретности проблемы, можно выделить некоторые формальные требования, на которых защищается квалификация разработчика программ.
Устойчивость программы. Программа не должна терять работоспособности ни при каких даже некорректных действиях пользователя. Всякие действия, грозящие потерей информации, выполняются только после повторного подтверждения. Вводимая информация там, где возможно, подвергается логическому контролю.
Обеспечение целостности баз данных. При любых действиях пользователя базы не должны терять целостности.
Функциональная полнота. В рамках согласованного с преподавателем или заказчиком подмножества функций все они должны быть реализованы.
Терминологическая среда и интерфейс. В диалоговых средствах используются только термины, понятные пользователю, и не используются термины разработчика («запись», «индексация» и т. д.). Появление служебных англоязычных сообщений СУБД недопустимо. Язык диалога — с соблюдением норм вежливости, цветовая гамма — по общепринятым рекомендациям.
Использование клавиатуры. На любом этапе нажатие любой клавиши (особенно функциональных) должно игнорироваться или вызывать предусмотренные действия (описанные в средствах помощи). Привязка действий к клавишам должна быть общепринятой: F1 — помощь; Enter — согласие, завершение ввода; Esc — отказ, возврат к предыдущему узлу ветви алгоритма (с восстановлением экранной формы); Tab — переход к следующему полю, окну и т. д.; Shift-Tab — возврат к предыдущему полю и т. д.
Порядок движения. Движение по дереву алгоритма «сверху вниз» сопровождается заголовками всех пройденных вершин; возврат возможен только на предыдущий уровень с сохранением введенной информации, выбранных пунктов меню и указателей записей.
Средства помощи и реклама. При запуске программы появляется рекламная заставка, отражающая суть и возможности программного средства, а также сведения об авторе. В любой точке алгоритма в строке подсказки должны высвечиваться все активные в данный момент горячие клавиши; в любой момент при нажатии клавиши F1 должен выдаваться контекстно-зависимый (зависящий от ситуации) текст помощи.
Входные и выходные документы. Экранные формы для ввода и корректировки должны быть максимально «похожими» на привычные для пользователя документы; результаты работы не только отображаются на экране, но и выводятся в текстовый файл в привычной для пользователя форме с возможностью корректировки и распечатки.
Средства документации. Программы снабжаются внутренней документацией в виде комментариев, средств меню и диалога, средств помощи, а также (по требованию преподавателя или заказчика) внешней документацией в виде отчета, содержащего, как минимум, постановку задачи, структуру баз данных, инструкцию для пользователя с элементами рекламы, описанием алгоритма, экранных форм, примеры входных и выходных документов.
2. Требования к Web-документам
Проекты, созданные в виде Web-страниц должны выполняться в соответствии с заказом руководителя и подчиняться общепринятым правилам Web-дизайна и Web-этикета:
Каждый HTML документ должен быть хорошо структурирован и содержать основную информацию о его происхождении: Автор, Дата создания, Контекст документа и его статус, Адрес (URL) документа.
Стиль оформления. Проект выполняется в едином стиле (то есть при создании должны быть использованы шаблоны или CSS). Текст должен быть контрастным и прекрасно читаться.
Фон сайта. При выборе цвета фона необходимо учитывать, как он будет гармонировать со следующими элементами: цветом текста, цветом гиперссылок, с логотипами или фирменными эмблемами.
Элементы навигации. Необходимо обеспечить достаточный цветовой и яркостный контраст между навигационными элементами и фоном. Система навигации не должна отягощать страницу, не должна отвлекать от ее содержимого, но должна быть легко доступна. Элементы локальной навигации желательно визуально отделять от элементов глобальной.
Гиперссылки. При указании перекрестных ссылок в документе необходимо проверить работоспособность каждой ссылки.
Синтаксис и семантика. Содержательное наполнение сайта должно соответствовать заявленному объему. Уровень синтаксических и семантических ошибок необходимо сводить к минимуму.
Использование графики. Графические объекты и элементы анимации необходимо гармонично встраивать в соответствии с текстом. Наличие каждого элемента должно быть логически оправданным.
Желательно чтобы сайт нормально выглядел как в различных программах просмотра и в разных режимах монитора (640X480, 800X600, 1024X784).
Сайт должен быть разработан без использования HTML-редакторов.
Объем и сложность проекта должны быть на уровне программных разработок.
