task_16012x

Содержание
стр.
1. Цель и задачи курсового проектирования ................................... 2
2. Содержание курсового проекта ..................................................... 2
2.1. Организация выполнения курсового проекта ....................... 2
2.2. Краткая справка о методологии моделирования UML ........ 3
2.3. Содержание пояснительной записки ..................................... 5
3. Рекомендации по выполнению курсового проекта ................... 27
4. Типовые задания на курсовой проект ......................................... 29
5. Указания к заданиям ..................................................................... 30
6. Критерии оценки курсового проекта .......................................... 30
Библиография .................................................................................... 33
Основная литература ..................................................................... 33
Дополнительная литература ......................................................... 33
1. Цель и задачи курсового проектирования
Курсовой проект является составной частью учебной
дисциплины «Программная инженерия» и предназначен для
практического
закрепления
и
расширения
полученных
теоретических знаний. Целью курсового проекта является
приобретение студентом навыков по созданию формализованных
требований к информационным технологиям.
Задачей проекта является формирование у студентов навыков
применения:
 языка UML;
 правил формирования требований;
 принципов проектирования программных средств;
 стандартов по оформлению программных документов.
2. Содержание курсового проекта
2.1. Организация выполнения курсового проекта
Продолжительность выполнения курсового проекта – десять
недель. Проект выполняется группами, но при этом каждый
студент выполняет индивидуальное задание, связанное со своей
частью. Список типовых заданий на курсовой проект приведен в
главе 3. Каждый студент обязан посетить не менее 5
консультаций по вопросам выполнения курсового проекта,
предъявляя на предварительный просмотр преподавателю
отдельные результаты курсового проектирования или проект
пояснительной записки. По результатам курсового проекта
студентом в соответствии с требованиями, изложенными в
параграфе 2.2, оформляется пояснительная записка и сдается
преподавателю на проверку. Если все недочёты, выявленные при
консультациях, устранены, студент защищает курсовую работу,
по результатам защиты выставляется итоговая оценка. Если
пояснительная записка не удовлетворяет поставленным
требованиям, то она возвращается студенту на доработку.
При выполнении курсового проекта студент обязан посетить
консультации и зачесть у руководителя, как минимум, следующие
этапы работы:
1) разработка входных, внутренних и выходных данных
решаемой задачи и её общего описания с использованием UML и
обоснование выбора метода разработки, языка программирования и
СУБД;
2) формирование
логической структуры программного
средства с использованием UML;
3) формирование
физической структуры программного
средства с использованием UML;
4) разработка
экранного
представления программного
средства и определение тестовых наборов данных.
Каждый этап, кроме первого, может представляться на
проверку преподавателю по частям во время консультаций.
Консультации проводятся не чаще чем 2 раза в неделю.
2.2. Краткая справка о методологии моделирования UML
Язык UML ориентирован для применения в качестве языка
моделирования различными пользователями и научными
сообществами для решения широкого класса задач объектноориентированнного анализа и проектирования (ООАП). При этом
термин "унифицированный" в названии UML не является
случайным и имеет два аспекта. С одной стороны, он фактически
устраняет многие из несущественных различий между известными
ранее языками моделирования и методиками построения диаграмм.
С другой стороны, создает предпосылки для унификации
различных моделей и этапов их разработки для широкого класса
систем, не только программного обеспечения, но и бизнеспроцессов. Семантика языка UML определена таким образом, что
она
не
является
препятствием
для
последующих
усовершенствований
при
появлении
новых
концепций
моделирования.
В настоящее время разработаны средства визуального
программирования на основе UML, обеспечивающие интеграцию,
включая прямую и обратную генерацию кода программ, с наиболее
распространенными языками и средами программирования, такими
как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS
Visual Basic, Forte, Ada, Smalltalk. Поскольку при разработке языка
UML были приняты во внимание многие передовые идеи и методы,
можно ожидать, что на очередные версии языка UML также окажут
влияние и другие перспективные технологии и концепции. Кроме
того, на основе языка UML могут быть определены многие новые
перспективные методы. Язык UML может быть расширен без
переопределения его ядра.
Язык UML предназначен для решения следующих задач:
1. Поддержка легко воспринимаемого выразительного языка
визуального моделирования, предназначенного для разработки и
документирования моделей сложных систем самого различного
целевого назначения.
2. Обеспечение возможностью расширения исходных понятий
языка UML и специализации для более точного представления
моделей систем в конкретной предметной области.
3. Описание языка UML, поддерживающее не зависящую от
конкретных языков программирования и инструментальных
средств проектирования программных систем, спецификацию
моделей.
4. Описание языка UML, включающее в себя семантический
базис для понимания общих особенностей ООАП.
5. Развитие рынка объектных инструментальных средств.
6. Распространение
объектных
технологий
и
соответствующих понятий ООАП.
7. Интеграция новейших достижения практики ООАП.
Из перечисленных выше диаграмм некоторые служат для
обозначения двух и более других подвидов диаграмм. При этом в
качестве самостоятельных представлений в языке UML
используются следующие диаграммы:
В качестве самостоятельных представлений в языке UML
используются следующие диаграммы:
 диаграмма вариантов использования;







диаграмма классов;
диаграмма состояний;
диаграмма деятельности;
диаграмма последовательности;
диаграмма кооперации;
диаграмма компонентов;
диаграмма развертывания.
Рис. 1 Интегрированная модель сложной системы в нотации UML
2.3. Содержание пояснительной записки
Пояснительная записка оформляется на листах формата А4 в
соответствии с требованиями ЕСКД и должна содержать:
Титульный лист.
Введение.
Глава 1. Анализ предметной области проектирования.
Глава 2. Выбор и обоснование средств и методов разработки.
Глава 3. Проектирование логической структуры программного
средства.
Глава 4. Разработка физической структуры программного средства.
Глава 5. Разработка интерфейсных компонентов программного
средства.
Глава 6. Формирование тестовых наборов данных.
Заключение.
Приложения.
Список литературы.
Титульный лист должен содержать название темы курсового
проекта, указание фамилии и инициалов, номера группы и номера
зачётки студента.
Между титульным листом и Введением следует подшивать
задание на курсовое проектирование, полученное у преподавателя.
При нумерации параграфов каждой главы в номер следует
включать номер главы. Например, для второго параграфа второй
главы должен формироваться номер «2.2».
2.3.1. Введение
Во введении необходимо дать краткое описание предметной
области, сформулировать цель проекта и показать актуальность
решаемой в проекте задачи (не более 1 стр.).
2.3.2. Постановка задачи
В главе 1 необходимо описать стандарты, которые
применяются для оформления программных документов и
осуществить обоснованный выбор наиболее приемлемых из них
для задачи, для решения которой разрабатывается программное
средство. На этом этапе формируется описание существующего
процесса, являющегося базой для последующих этапов.
Содержание главы:
1) Входные, выходные и внутренние данные процесса,
включающие
документы,
сведения,
информационные
и
управляющие воздействия, которые поступают в процесс,
формируются в процессе или передаются из процесса в другие
процессы. Следует отметить, что перечень документов данного
параграфа должен соответствовать документам, передаваемым в
мнемосхеме, выводам по главе 1, схеме модулей и алгоритма.
Пример 1:
Тип данных
Входные
Выходные
Внутренние
Перечень данных
проспекты и прайс-листы поставщиков, дела поставщиков, договора
на закупку, заявки, указания руководства, планы производства,
сведения о наличии средств для оплаты поставок
сведения о платежах поставщикам, данные о состоянии запасов для
производства, сведения о закупленных материалах, накладные
внутренние: копии договоров, лицензии, сертификаты, журналы
прихода материалов на склад, журналы по контролю условий хранения
Рис. 2 Пример таблицы входных, выходных и внутренних
данных процесса
2) Нормативные документы, устанавливающие требования к
процессу.
Пример 2:
Налоговый кодекс РФ, кодекс РФ об административных
правонарушениях, закон РФ «О защите прав потребителя»,
трудовой кодекс РФ, закон «О товарных знаках»;
3) Участников процесса, структуру их подчинённости и
описание основных функций, представляющие собой схему
подчинённости и перечень функций участников.
Пример 3:
Директор
Отдел снабжения:
1 начальник
2 инженер (2 чел.)
3 кладовщик (3 чел.)
4 грузчик (2 чел.)
Бухгалтерия:
1 главный бухгалтер
2 бухгалтер (5 чел.)
Другие
службы
Рис. 3 Пример структуры участников процесса
Пример 4:
Начальник отдела снабжения выполняет следующие функции:
 принятие решения о выборе поставщика;
 администрирование работ отдела;
 согласование договоров;
 решение сложных вопросов с поставщиками.
Инженер отдела снабжения выполняет следующие функции:
 обсуждение с поставщиками условий поставки;
 организация согласования договоров на закупку;
 контроль по целостности упаковок материалов при
внешнем осмотре;
 контроль за хранением материалов на складе.
4) Формирование пирамиды требований, содержащей уровень
потребностей
и
уровень
функциональных
особенностей
проектируемой системы.
На данном этапе формируется, как минимум, 3 потребности
заказчика, для реализации которых предназначена разрабатываемая
система. Для каждой потребности формируется 2 – 4
функциональные особенности. Всего их должно быть не менее 9.
Пример
В качестве первой потребности заказчик выдвинул…
Последняя
потребность
связана
с
необходимостью
формирования
печатного
отчёта
о
затратах
проекта.
Функциональные особенности показаны в таблице:
Потребность
…
Наличие отчёта о
затратах
Функциональные особенности
…
14) Работа с принтером
15) Загрузка данных из таблиц в текстовый редактор по заранее
определённому алгоритму в определённые разделы
16) Формирование на экране диалога по настройке отчёта перед
печатью
…
5) Вербальное и графическое описание функционального
назначения системы, включающее графическую схему (диаграмму
вариантов использования) и текстовых комментариев, поясняющих
на схеме как выполняется процесс. Следует учесть в диаграмме в
виде актёров всех участников, перечисленных в структуре
участников процесса.
Пример 5:
Рис. 4 Пример диаграммы вариантов использования для
примера
системы продажи товаров по каталогу
Покупатель обращается к продавцу и совместно с ним
оформляет заказ на покупку товара. При этом продавец
обеспечивает покупателя информацией, согласовывает условия
оплаты, заказывает товар со склада. Заказ на покупку товаров
осуществляется после выбора покупателем товара из каталога
товаров, запрошенного продавцом.
Рекомендации по выполнению диаграммы вариантов
использования:
 вариантов использования должно быть несколько (не менее
5);
 следите за логикой процесса: графическое отображение
должно быть исчерпывающим, понятным и соответствующим
текстовому описанию;
 диаграмма должна быть связана с пирамидой требований,
сформированной на предыдущем уровне: функциональные
особенности должны быть раскрыты вариантами использования
диаграммы вариантов;
 диаграмма вариантов использования должна содержать
актёров, варианты использования, интерфейсы, примечания и
отношения.
6) Формирование диаграммы кооперации.
Диаграмма кооперации предназначена для спецификации
структурных аспектов взаимодействия. Главная особенность
диаграммы кооперации заключается в возможности графически
представить не только последовательность взаимодействия, но и
все структурные отношения между объектами, участвующими в
этом взаимодействии.
На диаграмме кооперации в виде прямоугольников
изображаются участвующие во взаимодействии объекты,
содержащие имя объекта, его класс и, возможно, значения
атрибутов. Далее указываются ассоциации между объектами в виде
различных соединительных линий. При этом можно явно указать
имена ассоциации и ролей, которые играют объекты в данной
ассоциации. Дополнительно могут быть изображены динамические
связи — потоки сообщений. Они представляются также в виде
соединительных линий между объектами, над которыми
располагается стрелка с указанием направления, имени сообщения
и порядкового номера в общей последовательности инициализации
сообщений.
Пример 6:
Рис. 5 Пример диаграммы кооперации для моделирования
телефонного разговора
Следует отметить, что основная задача диаграммы
кооперации – показать роли и функции участников.
В рамках поставленной задачи необходимо построить не
менее 5 диаграмм кооперации для различных вариантов
использования.
7) Выводы о недостатках в рамках выполняемой задачи и
предложения по
преодоления.
разработке
программных
средств
для
их
Пример 7:
Анализ процесса показал, что важнейшими недостатками
являются:
 недостаточная эффективность использующейся технологии
учёта информации при помощи бумажного журнала;
 …
Для устранения недостатков предлагается разработать
программное средство, реализующее следующие функции:
 хранение сведений о ежедневных отгрузках с товарного
склада;
 …
При этом необходимо создать следующие объекты,
обладающие поведением:
 формы ввода (функция ввода информации):
 ввод отгруженной продукции;
 …
 отчётные формы (функция вывода информации на
принтер):
 справка об отгрузке поставщику;
 …
 вычислительные модули (функция расчёта параметров):
 процедура расчёта остатков на складе:
 …
 прочие объекты (…):
 …
Примечание:
 Форм ввода и отчётных форм должно быть не менее, чем по
3. Необходим хотя бы один вычислительный модуль.
 Форма авторизация не является формой ввода информации
документа, но должна присутствовать в проектируемом
программном средстве.
2.3.3. Выбор и обоснование средств и методов разработки
В главе 2 необходимо обосновать выбор метода разработки,
языка программирования и СУБД, используемой для хранения
промежуточных результатов.
Содержание главы:
1) Выбор метода разработки
В данном разделе студент должен указать обоснование и
причины использования UML в данном проекте.
2) Выбор и обоснование языка программирования
На этом этапе экспертными или расчётными методами
выбирается язык или среда программирования.
Пример 8:
Для
выбора
языка
программирования
методом
морфологического анализа произведён выбор из следующих
альтернатив:
Язык
программирования
Дороговизна лицензии
Сложность освоения
Оптимальность кода
…
Суммарный
приоритет
Вес
критерия
Язык 1
Язык 2
Язык 3
3
2
1
3
2
2
2
…
1
…
-
15
Суммарный приоритет рассчитывается методом построчного
суммирования произведений значений ячеек и соответствующих
весов.
3) Описание языка программирования или среды разработки,
включающее наименование языка (среды), основные особенности и
причины выбора.
Пример 9:
Для автоматизации процесса снабжения использован язык
программирования Visual Basic for Application, входящий в состав
СУБД Microsoft Access, представляющий собой алгоритмический
язык программирования …
Пример 10:
Для выбора
альтернатив:
Вид СУБД
Сложность освоения
Аппаратные требования
Скорость работы
…
Суммарный
приоритет
СУБД
произведён
выбор
из
следующих
Вес
критерия
СУБД 1
СУБД 2
СУБД 3
1
3
3
…
…
…
…
4) Описание СУБД, содержащее
наименование СУБД и
причины её выбора.
На этом этапе экспертными или расчётными методами
выбирается СУБД, либо доказывается отсутствие необходимости в
её использовании.
Пример 11:
Для автоматизации процесса снабжения выбрана СУБД
Microsoft Access 2003, которая позволяет создать персональную
базу данных и формы для работы с ней. Выбор СУБД обусловлен
…
2.3.4. Проектирование логической структуры программного
средства
В главе 3 на основе диаграммы использования и диаграммы
кооперации определяется логическая структура программного
средства, заданного темой проекта.
Содержание главы:
1) Разработка диаграммы классов, описывающей логическую
модель системы.
Диаграмма классов служит для представления статической
структуры модели системы в терминологии классов объектноориентированного программирования. Диаграмма классов может
отражать, в частности, различные взаимосвязи между отдельными
сущностями предметной области, такими как объекты и
подсистемы, а также описывает их внутреннюю структуру и типы
отношений.
В рамках проекта следует разработать логическую структуру
информации в виде диаграммы классов. Хранимая в базе данных
информация обычно также представляется в виде диаграммы
классов.
Пример 12:
Рис. 6 Пример диаграммы классов кадрового учёта
2) Список
вводимых
реквизитов
и
ограничений,
представляющих собой таблицы, в которых содержится
информация о наименовании, типе и ограничениях на значения
полей сущностей, упомянутых в диаграмме классов. В таблицах
должны быть выделены ключевые реквизиты.
Пример 13:
 Ведомость материалов:
Название реквизита Обозначение
Табельный номер (PK)
ФИО составителя
Материал
Срок хранения
ID
A_Name
Matirial
CondData
Тип
Размерность
Счётчик
Текст
Текст
Дата
8 симв.
50 симв.
50 симв.
8 симв.
…
Рис. 7 Пример фрагмента таблицы реквизитов входящего
документа «ведомость материалов»
3) Разработка диаграммы состояний
Главное предназначение этой диаграммы — описать
возможные последовательности состояний и переходов, которые в
совокупности характеризуют поведение элемента модели в течение
его жизненного цикла. Диаграмма состояний представляет
динамическое поведение сущностей, на основе спецификации их
реакции на восприятие некоторых конкретных событий. Системы,
которые реагируют на внешние действия от других систем или от
пользователей, иногда называют реактивными. Если такие действия
инициируются в произвольные случайные моменты времени, то
говорят об асинхронном поведении модели.
Рис. 8 Простейший пример диаграммы состояний
При проектировании следует выявить все возможные
состояния и варианты их возникновения, а также построить
диаграмму состояний для жизненного цикла одного из
разрабатываемых объектов.
Пример 14:
Рис. 9 Пример диаграммы состояний жизненного цикла
объекта «телефона»
Следует учитывать, что в некоторых вариантах логично
использовать диаграмму состояний с переходами, построенную на
основе сетей Петри как, например, показано на рисунке:
Рис. 10 Пример диаграммы состояний подготовки
строительного участка
При разработке диаграммы состояний нужно постоянно
следить, чтобы объект в каждый момент мог находиться только в
единственном состоянии.
Диаграмма строится для отдельного класса, варианта
использования, отдельной операции класса или целой подсистемы.
В рамках данного проекта необходимо построить диаграмму
состояний для всех выбранных объектов, для которых будет
описано поведение. Для получения удовлетворительной оценки их
должно быть не менее 5.
4) Разработка
алгоритма работы программного средства,
представляющего
собой
последовательность
выполняемых
программой команд. Алгоритм оформляется по ГОСТ 19.701-90.
Следует использовать схему работы программы.
Пример 15:
Начало
1 Расчёт дефицита и
формирование заявки
и договора
2 Ввод поставщика
3 Выход
Выбор
функции
материал
ов
2
1
3
Ввести план
производства
материалов
Просмотреть данные
об …
…
…
Конец
Рис. 11 Пример фрагмента алгоритма
Алгоритм должен быть явно увязан с диаграммой
использования, диаграммой классов и диаграммой состояний.
В алгоритме должно быть отражено: как, на каком этапе
заполняются формы ввода и формируются документы для печати,
осуществляются необходимые расчёты, используется база данных
или файловые хранилища для сохранения данных и загрузки их в
печатные отчёты.
Допускается строить общий алгоритм для всех выбранных для
автоматизации функций.
5) Формирование диаграммы деятельности
Графическая нотация диаграммы деятельности во многом
похожа на нотацию диаграммы состояний, поскольку на
диаграммах деятельности также присутствуют обозначения
состояний и переходов. Отличие заключается в семантике
состояний, которые используются для представления не
деятельностей, а действий, и в отсутствии на переходах сигнатуры
событий. Каждое состояние на диаграмме деятельности
соответствует выполнению некоторой элементарной операции, а
переход в следующее состояние срабатывает только при
завершении этой операции в предыдущем состоянии. Графически
диаграмма деятельности представляется в форме графа
деятельности, вершинами которого являются состояния действия, а
дугами — переходы от одного состояния действия к другому.
Рис. 12 Пример фрагмента диаграммы деятельности для
алгоритма нахождения корней квадратного уравнения
Достоинством диаграммы деятельности является возможность
развёртывания её в виде дорожек, т.е. с привязкой к исполнителям
конкретных операций алгоритма.
Пример 16:
Рис. 13 Пример фрагмента диаграммы деятельности для
торговой компании с дорожками
Строится для отдельного класса, варианта использования,
отдельной операции класса или целой подсистемы. В рамках
данного проекта необходимо построить диаграмму деятельности
для всех выбранных функций, которые следует автоматизировать.
6) Разработка диаграммы последовательности
На диаграмме последовательности изображаются объекты,
которые непосредственно участвуют во взаимодействии и не
показываются возможные статические ассоциации с другими
объектами. Для диаграммы последовательности ключевым
моментом является динамика взаимодействия объектов во времени.
Диаграмма последовательности имеет два измерения:
1) Одно – слева направо в виде вертикальных линий, каждая
из которых изображает линию жизни отдельного объекта,
участвующего во взаимодействии. Графически каждый объект
изображается прямоугольником и располагается в верхней части
своей линии жизни.
2) Второе измерение – вертикальная временная ось,
направленная сверху вниз. Начальному моменту времени
соответствует самая верхняя часть диаграммы.
Взаимодействия
объектов
реализуются
посредством
сообщений, которые посылаются одними объектами другим.
Сообщения изображаются в виде горизонтальных стрелок с именем
сообщения и также образуют порядок по времени своего
возникновения. Масштаб на оси времени не указывается, поскольку
диаграмма последовательности моделирует лишь временную
упорядоченность взаимодействий типа «раньше-позже».
Пример 17:
Рис. 14 Пример диаграммы последовательности для
моделирования телефонного разговора
В рамках данного проекта диаграмма последовательности
строится для вычислительного модуля задачи, показывая на каких
этапах и какие объекты выполняют необходимые в проекте
действия.
2.3.5. Проектирование физической структуры программного
средства
В главе 4 на основе логической определяется физическая
структура программного средства, заданного темой проекта.
Содержание главы:
1) Разработка диаграммы компонентов
Диаграмма компонентов описывает особенности физического
представления системы и позволяет определить архитектуру
разрабатываемой системы, установив зависимости между
программными компонентами, в роли которых может выступать
исходный, бинарный и исполняемый код. Во многих средах
разработки модуль или компонент соответствует файлу.
Пунктирные стрелки, соединяющие модули, показывают
отношения взаимозависимости, аналогичные тем, которые имеют
место при компиляции исходных текстов программ. Основными
графическими элементами диаграммы компонентов являются
компоненты, интерфейсы и зависимости между ними.
Диаграмма компонентов разрабатывается для следующих
целей:
 визуализации
общей
структуры
исходного
кода
программной системы;
 спецификации
исполнимого
варианта
программной
системы;
 обеспечения многократного использования отдельных
фрагментов программного кода;
 представления концептуальной и физической схем баз
данных.
Компонент – основной элемент диаграммы компонентов,
реализующий набор интерфейсов и служащий для общего
обозначения элементов физического представления модели. Для
графического представления компонента может использоваться
специальный символ — прямоугольник со вставленными слева
двумя более мелкими прямоугольниками.
Рис. 15 Графическое изображение компонента в языке UML
Зависимости могут отражать связи модулей программы на
этапе компиляции и генерации объектного кода. В другом случае
зависимость может отражать наличие в независимом компоненте
описаний классов, которые используются в зависимом компоненте
для создания соответствующих объектов. Применительно к
диаграмме компонентов зависимости могут связывать компоненты
и импортируемые этим компонентом интерфейсы, а также
различные виды компонентов между собой. Отношения реализации
показывают сплошными стрелками, а зависимости – пунктирными.
Пример 18:
Рис. 16 Пример изображения отношения зависимости между
компонентами в диаграмме компонентов
В данном проекте следует построить диаграмму компонентов
разрабатываемого программного средства и описать каждый её
элемент.
2) Разработка диаграммы развертывания
Физическое представление программной системы не может
быть полным, если отсутствует информация о том, на какой
платформе и на каких вычислительных средствах она реализована.
Диаграмма развертывания применяется для представления общей
конфигурации и топологии распределенной программной системы
и содержит распределение компонентов по отдельным узлам
системы. Кроме того, диаграмма развертывания показывает
наличие физических соединений — маршрутов передачи
информации между аппаратными устройствами, задействованными
в реализации системы. Диаграмма развертывания предназначена
для визуализации элементов и компонентов программы,
существующих лишь на этапе ее исполнения.
Пример 19:
Рис. 17 Пример диаграммы развертывания для системы
удаленного обслуживания клиентов банка
В данном разделе проекта следует определить комплекс
технических средств, которые необходимы для работы системы,
описать их и обобщить в виде диаграммы развёртывания.
2.3.6. Визуальный интерфейс программного средства
В главе 5 описываются элементы визуального интерфейса
программного средства с указанием перечня всех полей для ввода
данных с ограничениями на эти данные, а также перечень
документов, формируемых подсистемой с полным перечнем всех
их реквизитов.
Содержание главы:
3) Проекты экранных форм, которые могут быть как готовыми
экранными формами работающей программы, так и проектами
(шаблонами) документов, представляющих собой графические
схемы, демонстрирующие порядок отображения на экране
различных реквизитов проектируемых документов.
Пример 20:
Рис. 18 Пример экранной формы и шаблона документа
2.3.7. Тестовые наборы
В главе 6 должны анализироваться методы оценки
работоспособности
и
функциональной
пригодности
разрабатываемого программного средства и формироваться для
него тестовые наборы. Тестовые наборы должны быть связаны с
пирамидой требований и выступать в роли тестовых сценариев по
правилу: входные данные – условия на них – результат,
выдаваемый программным средством.
Один из участников проекта должен разработать программуметодику испытаний программного средства.
2.3.8. Заключение
В заключении должны быть подведены итоги проделанной
работы. В качестве итогов указывается объём проделанной работы,
решённая задача и практическая польза, которую принесло её
решение.
Пример 21:
В рамках выполненной курсовой работы на тему «Закупка
материалов для машиностроительной компании»:
 проведён анализ предметной области, сформированы
мнемосхема, функциональные и информационная модели процесса;
 разработана схема взаимодействия модулей, алгоритм
работы и проект выходных экранных форм программы,
реализующих автоматизацию процесса закупки материалов;
 разработаны тестовые наборы для оценки корректности
программы.
В ходе исследования выяснилось, что на данный момент
задача определения дефицита решалась без использования
компьютера по журналу учёта материалов на складе, что приводило
к большим затратам времени и высокой вероятности ошибки. Для
решения этой проблемы был использован язык программирования
VBA и СУБД Microsoft Access, с помощью которых была
разработана локальная программа, позволяющая хранить данные о
материалах на складе, оценивать по вводимым данным их
достаточность для производства в предстоящем году и
формировать заявку на закупку недостающих материалов у
поставщиков.
Ожидаемый эффект по экспертной оценке должен состоять в
сокращении на xxx% времени определения дефицита и на xxx%
вероятности возникновения ошибок.
2.3.9. Приложения
В приложении должны быть приложены следующие
документы, разрабатываемые участниками группы проекта:
 техническое задание, сформированное по ГОСТ 19.201-78;
 программа-методика испытаний, сформированная по ГОСТ
19.301-79;
 руководство оператора ГОСТ 19.505-79.
2.3.10. Список литературы
Список использованной литературы должен содержать ссылки
на основные источники, использованные при выполнении
курсового проекта (8-10 источников, издания – не старше 5 лет от
текущего года). В тексте проекта должны быть ссылки на
использованные источники. Например, в следующей форме – [7],
где 7 – номер источника в списке литературы.
3. Рекомендации и требования по выполнению курсового
проекта
3.1. Требования к организации проектных групп
Проект выполняется группами по 4 человека. Допускается
выполнение проекта группой меньшей численности по разрешению
преподавателя при наличии объективных обстоятельств.
В каждой группе реализуются следующие роли участников:
 системный интегратор (архитектор проекта) – участник,
оформляющий пояснительную записку к проекту и определяющий
общую структуру разрабатываемой системы, физическую часть
проекта;
 разработчик требований – участник, оформляющий
техническое задание и первый раздел пояснительной записки
(диаграмма вариантов использования разрабатывается совместно с
системным интегратором);
 проектировщик логической модели (системный аналитик) –
участник, разрабатывающий руководство оператора и логические
UML модели, такие как диаграмма состояний, диаграмма
деятельности, диаграмма последовательности и т.д. (диаграмма
классов и алгоритм разрабатывается совместно с системным
интегратором);
 проектировщик модели тестирования – участник,
оформляющий программу-методику испытаний, включая тестовые
наборы данных, модель тестирования полей на отказоустойчивость
и интерфейсную часть проекта.
Система оценки личного вклада участника приведена в
разделе 6.
Следует отметить, что высокие результаты одного участника
проекта не дадут ему получить «отлично», если весь проект в
целом выполнен на среднем уровне, поэтому следует тщательно
распределять роли в проекте.
Если число студентов в группе не кратно 4, то:
 допускается формировать 1-2 группы из 3 человек и её
участникам не оформлять программу-методику испытаний
программного средства;
 допускается дополнить 1-2 группы пятым участником и
поручить ему в качестве личного задания – формирование
пирамиды требований, а вся группа должна сформировать и
отладить рабочий программный код в соответствии со своим
заданием.
3.2. Рекомендации
Данный проект требует разработки и документирования
простейшего программного средства, используемого для решения
определённой офисной задачи. При этом не рекомендуется
применять готовые ERP или MRP системы, позволяющие
выполнять эти функции, а попытаться предложить дешевое, но
эффективное решение, созданное при помощи языков
программирования высокого уровня (Java, Object Pascal, Visual
Basic и т.д.), языков сценариев (SQL) или разметок (XML, HTML и
т.д.).
При этом следует учитывать следующие рекомендации:
1. Используйте системный подход. Помните, что методология
UML построена на его основе.
2. Разделите задачи проекта так, чтобы каждый студент был
загружен одинаково.
3. Не пытайтесь воспользоваться ранее сданными курсовыми
проектами. Фрагменты чужих работ отслеживаются. За плагиат
сильно
снижается
оценка,
вплоть
до
выставления
неудовлетворительной оценки. Преподаватель имеет право
направить служебную записку в деканат, со сведениями о попытке
подлога студентом чужой работы вместо своей. В случае признания
руководством представленных преподавателем доказательств
бесспорными, за подлог исключают из вуза без права
восстановления. Не верьте, что заказанные Вами работы кем-то
специально выполняются. Вам предложат старый проект, за
который Вы не получите даже оценки «удовлетворительно».
4. Разработайте рабочий макет проектируемого программного
средства, иначе обеспечить связность различных разделов
курсового проекта будет очень сложно.
5. Сохраняйте логику проекта от постановки задачи до
формирования тестовых заданий: все рисунки и модели должны
быть связаны; функции, попавшие в алгоритм, должны
прослеживаться на мнемосхеме, в функциональной структуре и в
структуре модулей программы; документы с экранных форм
должны фигурировать, как минимум, в перечне документов
проекта, в мнемосхеме и в алгоритме.
6. Используйте Интернет для пополнения сведений об
исследуемом процессе и отраслевой специфике. Пояснительные
записки, более чем на 75% совпадающие с уже оцененными
преподавателем в текущем или прошлые годы, считаются
плагиатом и оцениваются на «неудовлетворительно».
7. Следите за сроками проекта. Потребуется несколько
консультаций для получения положительной оценки.
4. Типовые задания на курсовой проект
Номер задания определяется двумя способами:
 по номерам вариантов, полученных при выполнении
курсовой работы по дисциплине «Информационные системы»;
 по двум последним цифрам (младшие разряды) номера
зачетной книжки, согласно табл. 1.
В течение 5 дней с момента выдачи задания на курсовой
проект студент может поменять тему по согласованию с
преподавателем, для чего он подаёт письменное заявление, в
котором обосновывается причина замены темы.
Таблица 1
Вар
иан
ты
Индивидуальные задания на курсовое проектирование
Название
Зарплатный калькулятор
01
21
Номера
41
61
81
Налоговый калькулятор
Депозитный калькулятор
Кредитный калькулятор
Страховой калькулятор
Расчет планировки
Расчет расхода топлива
Расчет оконной конструкции
Смета для расчёта мебели
Расчет количества символов в тексте
Расчет загрузки принтера
Расчет стоимости тура
Расчет места хранения
Расчет количества дипломных руководителей
Формирование экзаменационных билетов по
дисциплине
Расчет объема памяти для хранения видеозаписей с
камер наблюдения
Формирование элементов регламента доступа к сетевым
ресурсам (папкам)
Расчет номинала предохранителей в электрической цепи
Расчет акустического объема исходя из параметров
динамика
Расчет квартплаты
02
03
04
05
06
07
08
09
10
11
12
13
14
22
23
24
25
26
27
28
29
30
31
32
33
34
42
43
44
45
46
47
48
49
50
51
52
53
54
62
63
64
65
66
67
68
69
70
71
72
73
74
82
83
84
85
86
87
88
89
90
91
92
93
94
15
35
55
75
95
16
36
56
76
96
17
37
57
77
97
18
38
58
78
98
19
39
59
79
99
20
40
60
80
00
5. Указания к заданиям
Каждое задание представляет собой расчётно-учётную задачу,
использующую данные из небольшой базы данных. Для каждой
задачи должны быть определены данные, хранимые в базе данных
– фамилии исполнителей, названия объектов, обозначения
некоторых свойств, даты, сроки и т.д. Автоматизация процесса
должна обеспечивать решение задачи по созданию некоторой
выборки и формирования годного для печати отчёта, содержащего
все необходимые реквизиты.
Результатом работы должна являться пояснительная записка,
содержание которой должно включать этапы, соответствующие п.
2.2. Задание на курсовое проектирование обязательно вшивается в
пояснительную записку после титульного листа.
6. Критерии оценки курсового проекта
Каждый участник проекта получает свою
следующим показателям:
 оценка всего проекта в целом – до 5 баллов;
оценку
по
 оценка качества документа, разработанного лично им – до
10 баллов;
 оценка оригинальности проекта – до 5 баллов;
 оценка качества защиты проекта – до 5 баллов.
Критерии оценки:
1) Оценка всего проекта в целом осуществляется по
показателям:
 своевременность выполнения всех этапов курсового
проекта;
 логическая взаимосвязь между отдельными этапами
проекта;
 соответствие
полученных
при
проектировании
результатов заданию;
 соответствие
полученных
при
проектировании
документов стандартам, приведённым в приложении.
Если все показатели выполнены, то присуждается 5 баллов.
Если сроки выполнения нарушены на не более чем 7 дней или
имеется незначительная ошибка, то засчитывается 4 балла.
Если сроки выполнения нарушены на 8 – 15 дней или имеется
2 – 3 небольших или одна грубая ошибка, то – 3 балла.
Если сроки выполнения нарушены на 15 – 30 дней или
имеется более 3 небольших или 2 грубых ошибки, то присуждается
2 балла.
Если срок задержан на 31 – 60 дней или имеется более 2
грубых ошибок, то засчитывается 1 балл.
При непредставлении части работы, оговоренной заданием,
или задержке выполнения работ на срок более 2 месяцев, или
наличии в нём более 85% плагиата баллов не присуждается.
2) Оценка качества документа, разработанного лично
студентом, определяется по времени разработки и качеству
оформления документа и формируется по следующей шкале:
 если документ представлен в срок и не содержит
ошибок, то студенту засчитывается 10 баллов;
 за каждые 3 дня прострочки или 2 небольших (связанных
с неточностями оформления) или 1 грубую ошибку
вычитается по 1 баллу (например, если студент сдал документ
на 10 дней позже и сделал в нём 5 небольших и 2 грубых
ошибки, то ему будет засчитано 10 – 3 – 2 – 2 = 3 балла);
 если документ по содержанию не отражает своё
основное предназначение, определённое нормативными
документами и настоящими указаниями или он содержит
более 75% плагиата, то преподаватель имеет право не
засчитывать баллы за него.
3) Оценка оригинальности проекта как категория оценки
вводится с тем, чтобы типовой проект, сформированный с
заимствованием отдельных элементов из ранее выполненных
проектов, не мог быть оценен на «отлично».
Критерием оценки является новизна используемых методов
(кроме UML), используемого языка, СУБД, глубины и специфики
проработки отдельных моделей, а также оригинальность выбора
вариантов использования для которых предлагается разработка.
Если проект содержит менее 15% плагиата, то его
оригинальность оценивается в 5 баллов. За каждые 15% плагиата
вычитается по 1 баллу (например, если в работе 50% плагиата, то
студенту будет засчитано 5 – 3 = 2 балла).
4) Качество защиты студентом проекта оценивается по
качеству презентации или раздаточных материалов, уверенности
подачи материала на докладе и ответам на вопросы по сути
проекта.
Баллы
присуждаются
экспертно
преподавателями,
участвующими в приёме курсового проекта по следующим
критериям:
 при высоком качестве раздаточного материала и
презентации, уверенной подаче материала, логически связном
докладе и безошибочных ответах на вопросы присуждается 5
баллов;
 при наличии 1-2 небольших ошибок при ответах на
вопросы или 1-2 небольших недоработках в презентации или
докладе засчитывается 4 балла;
 при наличии 3-4 небольших или 1 грубой ошибки в
ответах, докладе или презентации – 3 балла;
 при большом числе ошибок в ответах, докладе или
презентации, либо отсутствии одного из элементов защиты
(например, раздаточного материала) засчитывается 2 балла;
 в случае если студент не в состоянии ответить ни на один
вопрос, в докладе или презентации имеется 3 и более грубых
ошибок, отсутствует презентация, не подготовлен доклад, то –
1 балл;
 при отказе от защиты баллов не присуждается.
После оценивания баллы суммируются, делятся на 5 и
округляются до ближайшего целого, что и определяет оценку за
курсовой проект студента.
Таким образом, для получения оценки «отлично» студенту
будет необходимо выполнить без ошибок, в срок оригинальный
проект и успешно его защитить. Отказ от защиты автоматически
снижает оценку на 1 балл. Низкая оригинальность работы – также
не позволит получить «отлично». При этом для получения оценки
«удовлетворительно» достаточно полностью в соответствии с
заданием выполнить проект и представить его на защиту.
Библиография
Основная литература
1. Автоматизированные информационные технологии в
экономике: Учебник/под ред. проф. Г.А. Титоренко. - М.: ЮНИТИ,
2005.
2. Гринберг, Информационные технологии управления:
Учебное пособие для вузов / А.С. Гринберг, Н.Н. Горбачев, А.С.
Бондаренко. – М.: ЮНИТИ-ДАНА, 2004.
3. Сергеева, Информатика: учебник / И.И. Сергеева,
А.А. Музалевская, Н. В. Тарасова.-М.: Форум: ИНФРА-М, 2006.335 с.
Дополнительная литература
1. Вендров, CASE – технологии. Современные методы и
средства проектирования информационных систем. / А.М.
Вендров– М.: Финансы и статистика, 1998.
2. Вендров, Проектирование программного обеспечения
экономических информационных систем: Учебник. / А.М. Вендров
– М.: Финансы и статистика, 2000.
3. Куликов,
Автоматизированное
проектирование
информационно-управляющих систем. Системное моделирование
предметной области. / Г.Г. Куликов, А.Н. Набатов, А.В. Речкалов
– Уфа: УГАТУ, 2003. 176 с.
4. Маклаков, Bpwin и Erwin. CASE- средства разработки
информационных систем. / С.В. Маклаков– М.: "ДИАЛОГ-МИФИ",
1999. – 256 с.