2 График выполнения курсового проекта

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

Задание на курсовой проект выдается на установочных заданиях.

Оформление пояснительной записки курсового проекта осуществляется в соответствие со «Стандартом предприятия ВГТУ». Работы, в которых содержание и оформление, как в целом, так и разделов, не соответствуют выданной теме и требованиям, описанным в данных методических указаниях и предъявляемым руководителем, к защите не допускаются и должны быть переработаны.

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

Порядок защиты курсового проекта:

1. доклад студента, рассчитанный на 5–10 минут;

2. демонстрация программного средства;

3. ответы на вопросы, задаваемые руководителем;

4. обсуждение курсового проекта;

5. ответы студента на замечания по проекту.

Оценка «отлично» выставляется за курсовые проекты, выполненные в соответствии с заданием и вышеизложенными требованиями, выполненные самостоятельно, имеющие оригинальные технические решения. При оценке проекта важную роль играют четкие ответы на поставленные вопросы в процессе защиты проекта. Повышает ценность курсовой работы его практическое использование на производстве или в учебном процессе. Наиболее удачные программные системы могут быть рекомендованы к регистрации в Фонде алгоритмов и программ.

Оценка «хорошо» выставляется за курсовые проекты, имеющие частные недостатки в реализации программного средства, некоторые пробелы в проработке отдельных вопросов в расчетно–пояснительной записке, неполные ответы на вопросы при защите проекта.

Оценка «удовлетворительно» выставляется за курсовые проекты, имеющие существенные недостатки в реализации программного средства, слабую проработку ключевых вопросов в расчетно–пояснительной записке, недостаточно аргументированные ответы на вопросы.

3 Методические указания по выполнению курсового проекта

3.1 Формирование требований к программному средству

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

В соответствии со стандартом IEEE 830-1998 Recommended Practice for Software Requirements Specifications (рекомендуемые методы спецификации требований к ПО) правильно составленный набор требований должен обладать следующими характеристиками:

• корректность или адекватность (соответствие реальным потребностям);

• недвусмысленность (однозначность понимания);

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

• непротиворечивость (согласованность между различными элементами);

• упорядоченность по важности и стабильности;

• проверяемость (выполнение каждого требования нужно уметь проверять некоторым достаточно эффективным способом — непроверяемые требования должны быть удалены из рассмотрения или сведены к проверяемым вариантам);

• модифицируемость (оформление в удобных для внесения изменений структуре и стилях);

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

В стандарте IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications (руководство по разработке спецификаций требований к системам) рассмотрены основные типы требований к программным системам:

• требования на входные данные;

• требования на выходные данные;

• надежность (reliability, например, среднее время работы между отказами);

• работоспособность (availability, например, необходимое отношение времени функционирования к полному времени работы);

• удобство сопровождения (maintainability, например, удобство замены компонента);

• производительность (performance, например, среднее время ожидания ответа);

• доступность (accessibility, например, разные способы доступа для новичков и опытных пользователей);

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

• эргономичность (ergonomic, например, использование набора цветов, понижающих утомляемость глаз);

• безопасность (safety, например, допустимые уровни электромагнитного излучения различных частот);

• защищенность (security, например, ограничения доступа для разных пользователей);

• требования к оборудованию (например, использование обычной электросети);

• транспортируемость (transportability, например, ограничения веса);

• удобство обучения (например, включение обучающих материалов);

• документированность (например, наличие встроенной документации);

• внешние интерфейсы (например, поддержка стандартных форматов документов);

• тестируемость (например, поддержка удаленной диагностики);

• условия необходимого качества (например, максимально допустимая погрешность производимых измерений);

• следование корпоративным и законодательным нормам (например, законам об охране труда);

• совместимость с известными системами;

• следование стандартам и технологическим нормам;

• конвертация данных (например, из старой версии системы);

• возможности роста (например, возможное увеличение числа пользователей);

• удобство развертывания (например, время, необходимое для приведения в работоспособное состояние).

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

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

Эта модель определяет требования к ПО — то, что система должна делать — в виде набора вариантов использования. Каждый вариант использования задает сценарий взаимодействия системы с действующими лицами или ролями, дающий в итоге значимый для них результат. Действующими лицами могут быть не только люди, но и другие системы, взаимодействующие с рассматриваемой. Вариант использования определяет основной ход событий, развивающийся в нормальной ситуации, а также может включать несколько альтернативных сценариев, которые начинают работать только при специфических условиях.

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

Модель вариантов использования выносится в приложение к РПЗ.