Добавлен: 25.10.2018
Просмотров: 4544
Скачиваний: 12
6
Студентам, по согласованию, могут быть предложены индивидуальные, нестандартные зада-
ния по теме данной дисциплины, связанные с выполнением госбюджетных и хоздоговорных НИР и
ОКР, проводимых на кафедре, включая разработку лабораторных стендов и товаров народного по-
требления. В свою очередь, студент может самостоятельно предложить тему КП, отличающуюся по-
вышенной актуальностью, связанную с выполнением НИРС или предстоящей выпускной квалифика-
ционной работы. Тема КП утверждается руководителем в установленные кафедрой сроки.
3. СОДЕРЖАНИЕ И ОБЪЕМ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ ПО КУРСОВОМУ ПРОЕКТУ
На страницах пояснительной записки (ПЗ) проводят анализ предметной области и объекта ав-
томатизации, анализ требований к проектируемой системе, разрабатывают концепцию системы и эс-
кизный проект. Выбор каждого проектно-технологическое решение должен проводиться из несколь-
ких альтернатив и должен быть тщательно обоснован. При этом рекомендуется на страницах ПЗ про-
водить анализ альтернативных вариантов архитектуры системы, программно-технологических плат-
форм и подходов, а результаты проведенного анализа помещать в тот или иной раздел соответст-
вующего приложения.
Содержание ПЗ по КП должно отражать результаты создания АСОИУ до стадии «4. Эскиз-
ный проект» включительно по ГОСТ 34.601-90. ПЗ должна включать в свой состав (в скобках указан
рекомендуемый объем в страницах):
• титульный лист (1 стр.);
• аннотацию (0,5 стр.);
• задание на курсовой проект (1 стр.);
• содержание (1 стр.);
• список принятых сокращений (при необходимости) (1 стр.);
• введение (2-3 стр.);
• проведение обследования объекта автоматизации (5-10 стр.);
• формирование требований к проектируемой системе (10-15 стр.);
• разработку концепции АСОИУ (10-20 стр.);
• техническое задание (3-7 стр.);
• эскизный проект (10-15 стр.);
• заключение (1 стр.);
• список литературы (1 стр.);
• приложения.
Рекомендуемый объем пояснительной записки составляет 45-60 страниц печатного текста на
листах писчей бумаги формата А4 (210x297 мм), на одной стороне листа. При необходимости, в при-
ложениях допускается применение листов формата А3 (297x420 мм).
4. МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО ВЫПОЛНЕНИЮ ОСНОВНЫХ РАЗДЕЛОВ КУРСОВОГО
ПРОЕКТА
4.1. ТИТУЛЬНЫЙ ЛИСТ
Титульный лист является первым листом пояснительной записки. Образец его оформления
приведен в приложении А.
4.2. ЗАДАНИЕ НА КУРСОВОЙ ПРОЕКТ
Задание на курсовой проект является исходным документом для проектирования. Оно состав-
ляется на специальном бланке (см. приложение Б) и содержит следующие данные:
− тему курсового проекта;
− исходные данные: назначение проектируемой АСОИУ и ее основные характеристики;
− указания по содержанию пояснительной записки;
− сроки выдачи задания и представления выполненной работы.
7
4.3. АННОТАЦИЯ
Аннотация содержит сведения об объеме ПЗ, количестве иллюстраций, таблиц, использован-
ных литературных источников и отражает: объект проектирования; предмет проектирования; исполь-
зуемые в ходе проектирования методы; краткое содержание разделов пояснительной записки с указа-
нием отличительных особенностей работы; полученные результаты и их оценку. Необходимо отме-
тить, что под объектом курсового проекта, как правило, понимается автоматизация технологического
процесса, рассматриваемого в работе. Предмет курсового проекта представляет собой приложение
информационных технологий к решению конкретной прикладной задачи, относящейся к объекту
проектирования, и обуславливающей актуальность заданной темы.
Аннотация составляется на заключительном этапе оформления ПЗ и снабжается основной
надписью для текстовых документов по ГОСТ 2.104-2006 (Форма 2) [64]. Пример оформления анно-
тации приведен в приложении В.
4.4. СОДЕРЖАНИЕ
Содержание приводится в пояснительной записке после аннотации и включает наименования
всех разделов и подразделов с указанием номера листа, с которого начинается каждый из них. Пер-
вый лист содержания необходимо снабдить основной надписью для текстовых документов (ГОСТ
2.104-2006 последующие листы – Форма 2а [64]). Пример оформления первого листа содержания
(номера страниц намеренно не проставлены) приведен в приложении Г. Структура содержания, при-
веденная в приложении Г, при необходимости может быть детализирована путем введения дополни-
тельных подразделов в ту или иную главу.
4.5. ВВЕДЕНИЕ
Во введении необходимо сформулировать проблему, цель и задачи курсового проекта, акту-
альность, провести краткий обзор известных программно-технологических решений по теме курсово-
го проекта.
В обзоре основное внимание следует уделить типовым структурным, архитектур-
ным и программным решениям, используемым в системах, аналогичных проектируемой;
уровню развития технологий проектирования, включающих в свой состав методологию
проектирования и системы управления проектом.
Основными литературными источниками, рекомендуемыми для обзора, являются: [10, 12, 14,
15, 26, 27, 28, 29, 30, 34, 38, 41, 44, 46, 48, 55, 56, 62, 79, 82, 83, 91, 94, 98, 103] (типовые структурные,
архитектурные и программные решения); [18, 23, 93] (системы управления проектом); [2, 4, 9, 11, 17,
47, 61, 88] (проектирование систем доступа к данным), а также сборники международных конферен-
ций: «Advanced Software Engineering: Expanding the Frontiers of Software Technology» [1], «Empirical
Software Engineering Issues Critical Assessment and Future Directions» [5], «Fundamental Approaches to
Software Engineering» [6], «Information Systems Development» [7], «Programming Languages and Sys-
tems» [8], «Web Information Systems Engineering» [9] за последние 5-7 лет, в которых, как правило,
публикуется описание новейших разработок и технологий в области создания АСОИУ. Вопросам
проектирования современных информационно-управляющих и моделирующих систем промышлен-
ного назначения посвящена обширная литература, наиболее полно перечисленная в [16, 19, 49].
При обосновании актуальности разработки следует сравнить основные характеристики из-
вестных аналогов с требованиями задания на курсовой проект и на основании этого сравнения сде-
лать заключение о целесообразности разработки системы.
Следует заметить, что, как правило, введение составляется в конце работы над курсовым про-
ектом, когда известны основные результаты, что позволяет конкретизировать цель и задачи.
4.6. ПРОВЕДЕНИЕ ОБСЛЕДОВАНИЯ ОБЪЕКТА АВТОМАТИЗАЦИИ
4.6.1. Сбор и анализ данных об объекте автоматизации
Сбор и анализ данных об объекте автоматизации, включая документооборот, осуществляется
посредством составления и описания различных структурных схем, отличающихся типами элементов
и связей между ними. ГОСТ 24.103-84 [66] предусматривает использование следующих видов струк-
тур: (i) функциональная (элементы - функции, задачи, операции; связи - информационные); (ii) тех-
8
ническая (элементы-устройства; связи - линии связи); (iii) организационная (элементы - коллективы
людей и отдельные исполнители; связи - информационные, соподчинения и взаимодействия); (iv) ал-
горитмическая (элементы - алгоритмы; связи - информационные); (v) программная (элементы - про-
граммные модули; связи - информационные и управляющие); (vi) информационная (элементы - фор-
мы существования и представления информации в системе; связи - операции преобразования инфор-
мации в системе).
В процессе сбора и анализа данных об объекте автоматизации необходимо использовать тех-
нологии системного анализа, позволяющие с обобщенных позиций изучить проблемную ситуацию,
требующую для своего решения привлечения информационных технологий. Согласно концепции
системного анализа решение проблемы в большинстве случаев связывается с реализацией «улуч-
шающего вмешательства», т.е. воздействия, которое положительно оценивается хотя бы одним
субъектом и неотрицательно всеми остальными [96]. Под субъектами проблемной ситуации понима-
ются все ее участники (в терминологии системного анализа - «стейкхолдеры»): организации, пред-
приятия, учреждения. Изменения будут вноситься в интересах одних из них («проблемосодержа-
щих»), осуществляться за счет ресурсов других («проблеморазрешащих») и как-то сказываться на
остальных. В этой связи, при проведении обследования объекта автоматизации составляется по воз-
можности полный список стейкхолдеров, опрос которых впоследствии позволит учесть все многооб-
разие требований к системе.
Кроме того, на первом шаге обследования необходимо построить и описать мо-
дель «черного ящика» системы, представляющую собой перечень входов и вы-
ходов системы, и, предназначенную, с одной стороны, для указания границ про-
ектируемой системы, с другой стороны, для фиксирования значимых с точки
зрения заказчика входных и выходных каналов передачи данных.
Необходимо указать какими данными и в каком формате пользователь должен
располагать для полноценного взаимодействия с системой, а также, какие дан-
ные, и в каком формате проектируемая система должна возвращать в виде ре-
зультата в соответствии с заданием.
Например, если проектируемая система предназначена, кроме всего прочего, для формирования от-
четов, то необходимо, поместив типовую форму отчета в приложение к ПЗ, описать его поля, указав
их тип и назначение.
Затем модель «черного ящика» подвергают декомпозиции, получая иерархическое дерево
подсистем или модель состава системы.
В ПЗ необходимо провести описание декомпозиции проектируемой системы со-
гласно методологии структурного анализа и проектирования SADT (Structured
Analysis & Design Technique) до уровня подсистем, выполняющих отдельно взя-
тые функции.
При этом рекомендуется структурно-функциональные IDEF0-диаграммы верхнего уровня декомпо-
зировать с применением диаграммам IDEF3, которые позволяют представить не только информаци-
онные потоки и взаимоотношения между процессами обработки информации, но и объекты, являю-
щиеся частью этих процессов и, следовательно, обладают более богатой по сравнению с IDEF0 нота-
цией [84]. Построение структурно-функциональных диаграмм необходимо выполнять с использова-
нием той или иной CASE-системы (например, AllFusion Process Modeler (BPWin), входящей в состав
пакета AllFusion Modeling Suite (Computer Associates) [84]).
Вопросам анализа предметной области и предварительного моделирования ИС посвящен ши-
рокий спектр литературных источников, однако в рамках курсового проекта достаточно воспользо-
ваться методиками, изложенными в [31, 37, 87]. Базовые концепции и приемы системного анализа
изложены в двух классических работах [90, 96].
Комплект IDEF0(IDEF3)-диаграмм, оформленных согласно Р 50.1.028-2001 [92], приводят в
приложении к ПЗ. Пример оформления контекстной IDEF0-диаграммы и одной диаграммы декомпо-
зиции приведен в приложении Д методических указаний.
4.6.2. Разработка обоснования на создание АСОИУ (ИМС)
4.6.2.1 Формулирование цели и задач создания АСОИУ (ИМС)
В подразделе «Формулирование цели и задач создания АСОИУ (ИМС)» приводят разверну-
тую формулировку цели создания системы, а также наименования и требуемые значения техниче-
ских, технологических, производственно-экономических или других показателей объекта автомати-
9
зации, которые должны быть достигнуты в результате создания системы с указанием критериев
оценки достижения цели [71].
Здесь же приводят подробный перечень задач, которые необходимо решить для
достижения поставленной цели, а также описывают выбор и обоснование состава
процессов, подлежащих автоматизации.
Для этого все функции проектируемой системы, перечисленные в разделе «Сбор и анализ данных об
объекте автоматизации», разделяют на две группы: (i) функции, которые будут автоматизированы в
ходе выполнения проекта; (ii) функции, которые останутся неавтоматизированными с обоснованием
причин.
Каждая функция системы, подлежащая автоматизации, в соответствии с заданием на КП,
должна снабжаться исчерпывающим описанием, включающим в свой состав расширенное определе-
ние ее назначения, а также анализ входных и выходных данных.
Для формулирования цели создания рассматриваемой системы полезно провести системати-
зацию данных, полученных в результате опроса стейкхолдеров. При этом необходимо учесть сле-
дующее:
• существует опасность неполного перечисления целей;
• цели, объявленные стейкхолдером, могут отличаться от его истинных целей;
• цели могут быть подменены средствами. Цели имеют древовидную структуру и каждый элемент
является целью для более низкого уровня и средством для более высокого. Цель самого высокого
уровня формулируют как миссию, которая отражает интересы всех стейкхолдеров. Далее опре-
деляют идеалы – результаты, которые считаются недостижимыми, но приближение к которым
возможно, затем цели – результаты, которые не предполагается достичь в рамках курсового про-
екта, но к которым рассчитывают приблизиться и задачи – результаты, которые предполагается
получить по завершению работы над проектом.
При формулировании цели необходимо придерживаться следующих рекомендаций:
1. цель должна быть достижимой при наличии финансовых, материальных и временных ресурсов;
2. цель должна быть конкретной, т.е. любое продвижение к цели должно вносить вклад в решение
именно данной проблемы, а не какой-нибудь другой;
3. цель должна быть измеримой, т.е. формулировка цели должна предполагать возможность отсле-
живать процесс движения к цели путем измерений.
Рекомендации по формулированию целей в достаточном для выполнения курсового проекта
объеме изложены в работе [96].
4.6.2.2 Предварительный выбор и обоснование состава автоматизируемых функций системы
В данном разделе функции проектируемой системы, которые планируется автоматизировать в
рамках проекта, анализируются с точки зрения пользователя. Цель такого анализа состоит в том, что-
бы, с одной стороны, прояснить взаимосвязи между функциями проектируемой системы, с другой
стороны подготовить исходные данные для предварительного расчета затрат на создание системы.
Международная группа пользователей функционального измерения (IFPUG – International
Function Point Users Group) [25] опубликовала критерии, по которым все функции системы разделяют
на пять групп в зависимости от принадлежности к одной из следующих информационных характери-
стик:
• Внешний ввод – элементарный процесс, перемещающий данные из внешней среды в приложе-
ние. Данные могут поступать по каналам связи, от пользователя с экрана ввода или из другого
приложения. Данные могут использоваться для обновления внутренних логических файлов и мо-
гут содержать как управляющую, так и деловую информацию. Управляющие данные не должны
модифицировать внутренний логический файл.
• Внешний вывод – элементарный процесс, перемещающий данные, вычисленные в приложении,
во внешнюю среду. Кроме того, в этом процессе могут обновляться внутренние логические фай-
лы. Данные создают отчеты или выходные файлы, посылаемые другим приложениям. Отчеты и
файлы создаются на основе внутренних логических файлов и внешних интерфейсных файлов.
Дополнительно этот процесс может использовать вводимые данные, их образуют критерии поис-
ка и параметры, не поддерживаемые внутренними логическими файлами. Вводимые данные по-
ступают извне, но носят временный характер и не сохраняются во внутреннем логическом файле.
• Внешний запрос – элементарный процесс, работающий как с вводимыми, так и с выводимыми
данными. Его результат – данные, возвращаемые из внутренних логических файлов и внешних
10
интерфейсных файлов. Входная часть процесса не модифицирует внутренние логические файлы,
а выходная часть не несет данных, вычисляемых приложением (в этом состоит отличие запроса
от вывода).
• Внутренний логический файл – распознаваемая пользователем группа логически связанных дан-
ных, которая размещена внутри приложения и обслуживается через внешние вводы.
• Внешний интерфейсный файл – распознаваемая пользователем группа логически связанных дан-
ных, которая размещена внутри другого приложения и поддерживается им. Внешний файл дан-
ного приложения является внутренним логическим файлом в другом приложении.
Вводы, выводы и запросы относят к категории транзакций. В данном контексте согласно оп-
ределению IFPUG под транзакцией понимается элементарный процесс, различаемый пользователем и
перемещающий данные между внешней средой и программным приложением. В своей работе тран-
закции используют внутренние и внешние файлы [55, 89].
Каждой информационной характеристике ставится в соответствие сложность. Для этого ха-
рактеристике назначается низкий, средний или высокий ранг с соответствующей числовой оценкой.
Для транзакций ранжирование основано на количестве ссылок на файлы и количестве типов элемен-
тов данных. Для файлов ранжирование основано на количестве типов элементов-записей и элементов
данных, входящих в файл. Тип элемента-записи — подгруппа элементов данных, распознаваемая
пользователем в пределах файла. Тип элемента данных — уникальное не рекурсивное (неповторяе-
мое) поле, распознаваемое пользователем.
Под элементами данных, как правило, понимают: для внешних вводов – поля ввода данных,
сообщения об ошибках, вычисляемые значения, кнопки; для внешний выводов – поля данных в отче-
тах, вычисляемые значения, сообщения об ошибках, заголовки столбцов, которые читаются из внут-
реннего файла; для внешних запросов – вводимые элементы: поле, используемое для поиска, щелчок
мыши, – выводимые элементы: отображаемые на экране поля.
Дополнительные примеры элементов данных, правила учета элементов графического пользо-
вательского интерфейса, а также порядок учета сообщений приведены в [55:139-140, 89:24-25].
В данном разделе на страницах ПЗ каждую функцию системы, выделенную в
главе «Сбор и анализ данных об объекте автоматизации», необходимо сопоста-
вить с той или иной информационной характеристикой.
С этой целью диаграмму декомпозиции, полученную при проведении сбора и анализа данных об объ-
екте автоматизации, рекомендуется представить в виде диаграммы потоков данных (Data Flow
Diagrams – DFD), поскольку именно DFD позволяет отражать функции обработки информации (рабо-
ты); объекты (документы, сотрудники и проч.), участвующие в обработке информации; внешние
ссылки (external reference), обеспечивающие интерфейс с внешними объектами, и таблицы для хране-
ния данных (data store).
Результаты проведенного анализа будут использоваться далее в разделе «Оценка затрат и
предварительный расчет ожидаемой эффективности АСОИУ».
4.6.2.3 Оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ (ИМС)
Заказчика на протяжении всего процесса работы над проектом интересует его стоимость.
Процесс оценки стоимости, как правило, начинается одновременно со стартом проекта и продолжа-
ется даже на стадии написания программного кода. На ранних стадиях проекта необходимо делать
оценку несколькими разными способами независимо, а затем сравнивать результаты.
В рамках курсового проекта предлагается воспользоваться хорошо зарекомендовавшей себя
методологией оценивания функционального размера (FP – Functional Points), которая заключается в
единообразном измерении всех возможностей приложения и выражении размера приложения в виде
числа, которое затем можно использовать для определения числа строк кода, стоимости и сроков
проекта.
Для вычисления функционального размера определяют ранг для каждой информационной ха-
рактеристики, описанной в разделе «Предварительный выбор и обоснование состава автоматизируе-
мых функций системы». В частности, в табл. 1 приведены данные для определения ранга и оценки
сложности внешних вводов (числовая оценка указана в круглых скобках). Из данных, приведенных в
табл. 1, следует, что, например, внешнему вводу, который ссылается на 2 файла и имеет 7 элементов
данных, назначается средний ранг и оценка сложности – 4).
Таблицы для определения рангов прочих информационных характеристик приведены в [55,
89].