Аа. метод реком СРС МДК 05.01. Проект и диз ИС веб. Методические рекомендации к выполнению срс мдк 05. 01. Проектирование и дизайн информационных систем угсн
 Скачать 1.54 Mb.
|
|
Дополнительная литература 1. Грекул, В. И. Проектирование информационных систем. Курс лекций : учебное пособиеnдля студентов вузов, обучающихся по специальностям в области информационных технологий / В. И. Грекул, Г. Н. Денищенко, Н. Л. Коровкина. — Москва, Саратов : Интернет-Университет Информационных Технологий (ИНТУИТ), Вузовское образование, 2017. — 303 c. 2. Проектирование информационных систем. Проектный практикум : учебное пособие для студентов дневного и заочного отделений, изучающих курсы «Проектирование информационных систем», «Проектный практикум», обучающихся по направлению 230700.62 (09.03.03) / А. В. Платёнкин, И. П. Рак, А. В. Терехов, В. Н. Чернышов. — Тамбов : Тамбовский государственный технический университет, ЭБС АСВ, 2015. — 80 c. 3. Лоскутов, В. И. Разработка информационных систем для Windows Store / В. И. Лоскутов, И. Л. Коробова. — 2-е изд. — Москва : Интернет-Университет Информационных Технологий (ИНТУИТ), 2016. — 179 c. 4. Червяков, В.М. Метрология, стандартизация и сертификация : учебное пособие / В.М. Червяков, А.О. Пилягина, П.А. Галкин ; Министерство образования и науки Российской Федерации, Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Тамбовский государственный технический университет». – Тамбов : Издательство ФГБОУ ВПО «ТГТУ», 2015. – 113 с. Самостоятельная работа № 5 Тема: «Примеры CASE-средств и их характеристики» 9 ч. Цель: - закрепить полученные теоретические знания по изученной теме. Ознакомиться с назначением CASE-технологии на примере BPWin, предназначенного для построения функциональных моделей существующих бизнес-процессов, проведения анализа и реорганизации бизнес-процессов предприятий.. Способствовать формированию соответствующих общих и профессиональных компетенций: ОК 01, ОК 02, ОК 03, ОК 04, ПК 5.3., ПК 5.4., ПК 5.6, ПК 5.7. Средства для выполнения работы: аппаратные: ПК или ноутбук; программные: OS Windows, MS Office, BPWin; СЭДО СВФУ (Moodle) – Портал электронного обучения СВФУ Теоретические сведения: Под технологией проектирования (создания) информационных систем (ИС) понимают упорядоченный в логической последовательности набор методических приемов, технических средств и проектировочных методов, нацеленных на реализацию общей концепции создания или доработки проекта системы и ее компонентов. Для разработки ИС управления большое значение имеют качество и состав базы проектирования. Создание современных информационных систем представляет собой сложнейшую задачу, решение которой требует применения специальных методик и инструментов. Неудивительно, что в последнее время среди системных аналитиков и разработчиков значительно вырос интерес к CASE-технологиям и инструментальным CASE-средствам, позволяющим максимально систематизировать и автоматизировать все этапы разработки программного обеспечения. Технология создания информационных систем предъявляет особые требования к методикам реализации и программным инструментальным средствам, а именно: 1. Реализацию проектов по созданию ИС принято разбивать на стадии анализа (прежде чем создавать ИС, необходимо понять и описать бизнес-логику предметной области), проектирования (необходимо определить модули и архитектуру будущей системы), непосредственного кодирования, тестирования и сопровождения. Известно, то исправление ошибок, допущенных на предыдущей стадии, обходится примерно в 10 раз дороже, чем на текущей; откуда следует, что наиболее критическими являются первые стадии проекта. Поэтому крайне важно иметь эффективные средства автоматизации ранних этапов реализации проекта. 2. Проект по созданию сложной ИС невозможно реализовать в одиночку. Коллективная работа существенно отличается от индивидуальной, поэтому при реализации крупных проектов необходимо иметь средства координации и управления коллективом разработчиков. 3. Жизненный цикл создания сложной ИС сопоставим с ожидаемым временем ее эксплуатации. Другими словами, в современных условиях компании перестраивают свои бизнес-процессы примерно раз в два года, столько же требуется (если работать по традиционной технологии) для создания ИС. Может оказаться, что к моменту сдачи ИС она уже никому не нужна, поскольку компания, ее заказавшая, вынуждена перейти на новую технологию работы. Следовательно, для создания ИС необходим инструмент значительно (в несколько раз) уменьшающий время разработки ИС. 4. Вследствие значительного жизненного цикла может оказаться, что в процессе создания системы внешние условия изменились. Обычно внесение изменений в проект на поздних этапах создания ИС весьма трудоемкий и дорогостоящий процесс. Поэтому для успешной реализации крупного проекта необходимо, чтобы инструментальные средства, на которых он реализуется, были достаточно гибкими к изменяющимся требованиям. На начальных этапах создания информационной системы необходимо понять, как работает организация, которую собираются автоматизировать. Никто в организации не знает, как она работает в той мере подробности, которая необходима для создания информационной системы. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в работу каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но плохо знает, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области, следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации. CASE-cредство BPWin предназначено для проведения анализа и реорганизации бизнес-процессов. BPWin поддерживает методологию IDEF0 (функциональная модель). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии или идеального положения вещей – того, к чему нужно стремиться. Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной – функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. Такая технология построения модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и, в левой части экрана, навигатор модели (иерархическая структура модели). Модель BPWin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные - в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого- либо свойства объекта. Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, «Изготовление детали», «Прием заказа» и т.д.). При создании новой модели возникает диалог, в котором следует указать имя модели, которая будет создана, выбрать методологию моделирования Business Process (IDEF0) и нажать ОК. Рисунок 1 – Создание новой модели При создании новой модели автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом. Рисунок 2 - Контекстная диаграмма с единственной работой, изображающей систему в целом Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Рисунок 3 – Внесение имени работы Чтобы отобразить дочерние работы, т.е. осуществить декомпозицию работы, необходимо щелкнуть по кнопке Возникает диалог Activity Box Count, в котором следует указать количество работ на этом уровне декомпозиции. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме. Рисунок 4 – Декомпозиция работы Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему. Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу располагается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое расположение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ. Рисунок 5 – Диаграмма декомпозиции После каждого сеанса декомпозиции поводятся сеансы экспертизы – эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после этого можно приступать к следующему этапу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, «Заготовка», «Изделие», «Заказ» и т.д.). В IDEF0 различают 5 типов стрелок. Рассмотрим более подробно 4 из них. Вход (Input) – материал или информация, которые используются работой для получения результата (выхода). Стрелка входа рисуется как входящая в левую грань работы. Вход – это нечто, что преобразуется/ изменяется работой. Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Стрелка управления рисуется как входящая в верхнюю грань работы. Управление влияет на работу, но не преобразуется работой. Каждая работа должна иметь хотя бы одну стрелку управления. Выход (Output) - материал, или информация, которые производятся работой. Стрелка рисуется как исходящая из правой грани работы. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Механизм (Mechanism) – ресурсы, которые выполняют работу, например, персонал предприятия, станки, устройства и т.д. стрелка механизма рисуется как входящая в нижнюю грань работы. Для внесения стрелок необходимо нажать на кнопку с символом Внесение стрелок необходимо начинать с контекстной диаграммы. Стрелки, нарисованные на диаграмме декомпозиции нижнего уровня не появляются на диаграмме верхнего уровня. Такие стрелки называются неразрешенными и воспринимаются программой как синтаксическая ошибка. Рисунок 6- Пример внесения стрелок Словарь стрелок редактируется с помощью специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий. Рисунок 7 – Редактор стрелок При декомпозиции работы входящие в нее и исходящие из нее стрелки автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPWin как синтаксическая ошибка. Рисунок 8 - Пример несвязных стрелок Для связывания стрелок необходимо перейти в режим редактирования стрелок для устранения всех несвязанных стрелок. Потом необходимо дорисовать все стрелки между отдельными работами. Такие стрелки называются внутренними, они начинаются у одной и кончаются у другой работы. Ниже приведен пример отредактированной диаграммы декомпозиции. Рисунок 9 - Отредактированная диаграмма декомпозиции По окончании рисования стрелок для перехода в режим редактирования модели необходимо нажать кнопку Далее каждая работа может быть разбита на более мелкие работы, до требуемого уровня детализации. Для проверки синтаксиса модели следует вызвать диалог Tools/Reports/Model Consistency Report. После чего появится диалоговое окно. Затем следует выбрать пункт Preview для предварительного просмотра списка синтаксических ошибок модели. Список синтаксических ошибок может включать: - неименованные функциональные блоки и стрелки (unnamed arrows, unnamed activities); - несвязанные стрелки (unconnected border arrow); - неразрешенные стрелки (unresolved (square tunneled) arrow connection); - блоки, не имеющие по крайней мере одной стрелки выхода и одной стрелки управления (activity “Наименование функционального блока” has no Control) и т.д. Для наглядного представления количества уровней декомпозиции и отношений между родительскими и дочерними диаграммами следует сформировать отчет Node Tree. Для этого нужно вызвать диалог Diagram/Add Node Tree.После чего появится диалоговое окно, где будет предложено название отчета (можно написать другое) – Node Tree Name, верхний уровень диаграммы, с которого следует начать строить отчет – Top level activity, и выбрать количество уровней который будет иметь отчет – Number of levels. Рисунок 10 – Окно построения отчета Node Tree При нажатии кнопки далее можно изменить, либо оставить прежними параметры отчета. Затем следует нажать кнопку готово и появится сформированный отчет. Отчет имеет древовидную структуру. Рисунок 11 – Пример отчета Node Tree Пример 1. Создание модели процесса изготовления изделия. Рисунок 12 – Контекстная диаграмма Рисунок 13 – Пример несвязанных стрелок Рисунок 14 – Диаграмма декомпозиции Пример 2. Создание модели исследования методом социологического опроса. Рисунок 15 – Диаграмма декомпозиции Задания: Задание 1. Создать группу из 3-х студентов. Составить план работы и сделать проект: «Разработка функциональной модели любого процесса». Каждый член группы выбирает отдельную индивидуальную предметную область ИС, где будут проектировать функциональные модели через BPWin. Темы предметных областей искать в пространстве сети Интернет. Раскрыть суть и определить основные моменты. Обосновать выбор области. Также каждый из членов группы будет работать над одной конкретной диаграммой данной модели ИС. Следовать примерам (с 1-го по 15-ый). Каждый этап работы самостоятельно организовать и обосновать, сделав отчет проделанной работы. Задание 2. Отобразить эту модель в среде BPWin. При выполнении задания 1 подготовить мультимедийную презентацию, раскрыв в ней свой отчет, с иллюстративными материалами (конкретно, с диаграммами). Задание 3. Выявить друг у друга ошибки и составить краткий план собственного профессионального и личностного развития. Методические указания к выполнению работы 1. Найти в поисковых системах информацию по теме самостоятельной работы и анализировать, выбрать необходимую для выполнения данной работы. Грамотно использовать оптимальные, эффективные методы поиска, анализа и оценки информации в поисковой системе или в СЭДО СВФУ (Moodle). 2. Защитить выполненную СРС по выбранной группой форме. Подготовленную мультимедийную презентацию использовать при защите работы. Самостоятельная работа № 6 Тема: «Состав и содержание технического задания » 8 ч. Цель: - закрепить полученные теоретические знания по изученной теме. Ознакомиться с процедурой разработки технического задания на создание программного продукта (ПП) с применением ГОСТ 19.102-77 «Стадии разработки программ и программной документации» и ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Способствовать формированию соответствующих общих и профессиональных компетенций: ОК 01, ОК 02, ОК 03, ОК 04, ПК 5.3., ПК 5.4., ПК 5.6, ПК 5.7. Средства для выполнения работы: аппаратные: ПК или ноутбук; программные: OS Windows, MS Office; СЭДО СВФУ (Moodle) – Портал электронного обучения СВФУ Теоретические сведения: Техническое задание — это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления. Техническое задание представляет собой документ, в котором сформулированы основные цели разработки, требования к программному продукту, определены сроки и этапы разработки и регламентирован процесс приемо-сдаточных испытаний. В разработке технического задания участвуют как представители заказчика, так и представители исполнителя. В основе этого документа лежат исходные требования заказчика, анализ передовых достижений техники, результаты выполнения научно-исследова-тельских работ, предпроектных исследований, научного прогнозирования и т.п. При разработке технического задания (ТЗ) необходимо решить следующие задачи: установить общую цель создания АИС; установить общие требования к проектируемой системе; разработать и обосновать требования, предъявляемые к информационному, математическому, программному, техническому и технологическому обеспечению; определить состав подсистем и функциональных задач; разработать и обосновать требования, предъявляемые к подсистемам; определить этапы создания системы и сроки их выполнения; провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения; определить состав исполнителей. В Российской Федерации действует ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы», также на техническое задание существует стандарт ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам устанавливает общие требования к оформлению программных документов. Программный документ должен состоять из следующих частей: Титульной; Информационной; Основной. Титульная часть оформляется согласно ГОСТ 19.104-78 ЕСПД. Основные надписи. Информационная часть должна состоять из аннотации и содержания. В аннотации приводят сведения о назначении документа и краткое изложение основной части. |