Файл «Ответы по дисциплине Проектирование информационных систем» внутри архива находится в папке «Ответы по дисциплине Проектирование информационных систем». Документ из архива «Ответы по дисциплине Проектирование информационных систем», который расположен в категории » «. Всё это находится в предмете «проектирование информационных систем» из 11 семестр (3 семестр магистратуры), которые можно найти в файловом архиве РТУ МИРЭА. Не смотря на прямую связь этого архива с РТУ МИРЭА, его также можно найти и в других разделах. Архив можно найти в разделе «к экзамену/зачёту», в предмете «проектирование информационных систем» в общих файлах.
Онлайн просмотр документа «Ответы по дисциплине Проектирование информационных систем»
Текст 5 страницы из документа «Ответы по дисциплине Проектирование информационных систем»
- Перечисление возможных требований;
- Осознание контекста системы;
- Определение функциональных требований;
- Определение нефункциональных требований.
Перечисление возможных требований
Бизнес-процессы для больших: Обзор модели BPTrends. Часть 2
Первое, что нужно сделать – это начать собирать всевозможные требования и идеи насчет будущей системы. Это будет несистематизированный список, в который должно попасть все, что касается системы и приходит в голову разработчикам, аналитикам и пользователям. Эти идеи будут кандидатами на реализацию в будущих версиях системы и используются для планирования работ.
Каждое предложение в списке должно иметь короткое название и краткое описание, в чем оно состоит, также для дальнейшей работы необходима дополнительная информация для планирования и последующей реализации требований, в которые могут входить:
- состояние предложения (например, предложено, одобрено, включено в план, утверждено);
- трудоемкость в человеко-часах или стоимость реализации;
- приоритет (например, критический, важный или вспомогательный);
- уровень риска, связанного с реализацией предложения (например, критический, значительный или обычный).
Этот список в ходе работ может уменьшаться, когда требования преобразуются в другие артефакты, например – варианты использования или нефункциональные требования, и увеличиваться, когда выдвигаются новые предложения.
Осознание контекста системы
Для того чтобы верно определить требования разработчики системы должны понимать контекст (часть предметной области) в котором работает система. Существует по крайней мере два подхода к описанию контекста системы:
- Моделирование предметной области;
- Бизнес-моделирование.
Модель предметной области
Модель предметной области описывает важные понятия предметной области и их связи между собой. Нельзя путать модель предметной области с логической и физической моделями системы. Модель предметной области описывает только объекты предметной области, но не показывает, как программная система будет с ними работать. Данная модель также позволяет составить глоссарий системы для лучшего ее понимания пользователями и разработчиками.
Описание бизнес-процессов «как есть» и «как надо»
Бизнес-модель
Бизнес-модель описывает процессы (существующие или будущие), которые должна поддерживать система. Бизнес-модель можно представить как подмножество модели предметной области. Кроме определения бизнес-объектов, вовлеченных в процесс, эта модель определяет работников, их обязанности, и действия, которые они должны выполнять.
Определение функциональных требований
Подход к выявлению системных требований основан на использования вариантов использования системы (Use Cases), которые охватывают как функциональные, так и нефункциональные требования, которые специфичны для конкретного варианта использования.
Для пользователя важно, чтобы система выполняла определенные действия для него, при этом пользователь определенным образом взаимодействует с системой, использует ее для своих целей. Таким образом, если определить все возможные варианты использования системы пользователями или другими внешними процессами, то мы получим функциональные требования к ней.
Однако каждый конкретный пользователь работает с системой по-своему, поэтому для определения действительных вариантов использования системы необходимо досконально знать потребности всех заинтересованных пользователей, провести анализ полученной информации и систематизировать ее в действительные варианты использования системы, т.е. абстрагироваться от конкретных пользователей и исходить от бизнес-задач.
В дополнение к вариантам использования необходимо определить, как должен выглядеть пользовательский интерфейс для реализации того или иного варианта использования. Набросать эскизы, обсудить их с пользователями, создать прототипы и отдать их на тестирование пользователям.
Определение нефункциональных требований
К нефункциональным требованиям относятся такие свойства система, как ограничения среды и реализации, производительность, зависимость от платформы, расширяемость, надежность и т.д. Под надежностью понимаются такие характеристики, как пригодность, точность, средняя наработка на отказ, число ошибок на тысячу строк программы, число ошибок на класс.
Требования по производительности – это скорость, пропускная способность, время отклика, используемая память. Многие требования, связанные с производительностью должны быть описаны в конкретных вариантах использования, а не в разделе относящейся ко всей системе.
Также можно отметить, что часто нефункциональные требования не могут быть привязаны к конкретному варианту использования и должны быть вынесены в отдельный список дополнительных требований к системе.
Характеристика моделей деятельности организации. Модель «как есть» (AS IS) и модель «как будет» (TO BE).
AS IS — модель «как есть», модель существующего состояния организации.
Данная модель позволяет систематизировать протекающие в данный момент процессы, а также используемые информационные объекты. На основе этого выявляются узкие места в организации и взаимодействии бизнес-процессов, определяется необходимость тех или иных изменения в существующей структуре.
Такую модель часто называют функциональной и выполняют с использованием различных графических нотаций и case-средств. На этапе построения модели AS-IS важным считается строить максимально приближенную к действительности модель, основанную на реальных потоках процессов, а не на их идеализированном представлении.
Проектирование информационных систем и управление процессами подразумевает построение модели AS IS и дальнейший переход к модели TO-BE, что является залогом автоматизации «правильных», усовершенствованных процессов.
TO BE (SHOULD-BE, AS-TO-BE) — модель «как должно быть».
Как правило, данная модель создается на основе AS IS, с устранением недостатков в существующей организации бизнес-процессов, а так же с их совершенствованием и оптимизацией. Это достигается за счет устранения выявленных на базе анализа AS IS узких мест.
В традиционном реинжиниринге именно на основе модели TO BE рекомендуется производить автоматизацию бизнес-процессов и проектировать КИС. Подразумевается, что это позволяет существенно снизить риск проявления автоматизации как исключительно источника затрат из-за автоматизации несовершенных процессов. Однако в настоящее время, в связи с возрастающей популярностью «эволюционного» реинжиниринга (см. CPI), снижается необходимость в долгой и трудоемкой подготовке модели TO BE.
Диаграммы стандарта IDEF0. Основные принципы построения.
Информационные технологии — Бизнес-процессы
Что такое IDEF0 диаграмма и как ее построить
Начнем с понятий.
Бизнес-процесс – это логичный, последовательный, взаимосвязанный набор мероприятий, который потребляет ресурсы, создаёт ценность и выдаёт результат.
Моделирование бизнес-процессов – это эффективное средство поиска путей оптимизации деятельности компании, позволяющее определить, как компания работает в целом и как организована деятельность на каждом рабочем месте.
Для чего это делается? Бизнес-процессы организации описывают для того, чтобы в последствии их проанализировать и понять, куда какая информация идет и откуда вытекает. Делается это в ряде случаев для оптимизации рабочего процесса на предприятии. К примеру, при внедрении новой информационной системы или создания должностных инструкций.
Бизнес-модель — это формализованное (графическое, табличное, текстовое, символьное) описание бизнес-процессов. Делается это для того, чтобы понять структуру организации и процессы происходящие в ней, создать базу данных к разрабатываемому программному обеспечению, автоматизирующему процессы на предприятии.
Существует несколько классических, строго оговоренных видов моделей.
Одна из самых распространенных — это IDEF0 модель, состоящая из диаграмм, текстов и глоссария, имеющих ссылки друг на друга.
Существует ряд правил составления IDEF0 диаграмм:
— все функции и интерфейсы представлены как блоки и дуги;
— место соединения дуги с блоком определяет тип интерфейса:
- управляющая информация входит в блок сверху,
- входная информация входит в блок слева,
- результаты выходят из блока справа,
- механизм (человек или автоматизированная система), который осуществляет операцию, входит в блок снизу .
Отдельные компоненты диаграммы могут быть более подробно расшифрованы на другой диаграмме. Общее число уровней детализации в модели не должно превышать 5-6.
Из недостатков можно отметить сложность восприятия данной диаграммы при большом количестве уровней.
Типы связей стандарта IDEF0.
Методология IDEF0 нашла широкое признание и применение, в первую очередь, благодаря простой графической нотации, используемой для построения модели. Главными компонентами модели являются диаграммы. На них отображаются функции системы в виде прямоугольников, а также связи между ними и внешней средой посредством стрелок. Использование всего лишь двух графических примитивов (прямоугольник и стрелка) позволяют быстро объяснить правила и принципы построения диаграмм IDEF0 людям, незнакомым с данной методологией. Это достоинство позволяет подключить и активизировать деятельность заказчика по описанию бизнес-процессов с использованием формального и наглядного графического языка.
Рассмотрим основные элементы графической нотации IDEF0 (рис. 6.1.).
Рис. 6.1. Элементы графической нотации IDEF0
Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу), которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).
Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок:
вход (англ. input) – материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;
управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т. е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);
выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;
механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;
вызов (англ. call) – стрелка указывает, что некоторая часть работы выполняется за пределами рассматриваемого блока. Стрелки выхода рисуются исходящими из нижней грани работы.
Диаграммы стандарта IDEF3. Основные принципы построения.
СТАНДАРТ IDEF3 — это методология сбора данных о процессе, рассматривающая взаимодействие информационных потоков как логическую последовательность выполнения на основе причинно-следственных связей между ситуациями и событиями, предназначенная для разработки структурного представления знаний о системе, и описания изменения состояний объектов, являющихся составной частью описываемых процессов.
При помощи графической нотации IDEF3 описывается логика выполнения работ, очередность их запуска и завершения. Т.о. IDEF3 предоставляет инструмент для моделирования сценариев действий сотрудников организации, отделов, цехов и т.п., например порядок обработки заказа или события, на которые необходимо реагировать за конечное время, выполнение действий по производству товара им т.д.
IDEF3 рассматривает поведенческие аспекты существующих или проектируемых систем. Знания о процессах структурированы в виде контекстных сценариев, что делает IDEF3 удобным инструментом сбора данных для описания системы. IDEF3 аккумулирует в себе временные зависимости и связи между процессами, происходящими на предприятии.
В результате создается структурированная база знаний для построения аналитических и проектировочных моделей. В отличие от других языков моделирования (таких, как SIMAN, SLAM, GPSS, WITNESS), которые строят прогностические математические модели, IDEF3 позволяет создавать структурные описания. Эти описания содержат информацию о том, что на самом деле происходит или будет происходить в системе, а также отражают точки зрения различных пользователей.
Описание процесса по нотации IDEF3 представляет собой структурированную базу знаний, которая состоит из набора диаграмм описания процесса, объектных диаграмм изменения состояний объектов и уточняющих форм. Цель такого описания может состоять как в документальном оформлении и распространении знаний о процессе, так и в идентификации противоречивости или несовместимости выполнения отдельных операций.
Для эффективного управления любым процессом, необходимо иметь детальное представление о его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:
- документировать имеющиеся данные о технологии выполнения процесса, выявленные, в процессе опроса специалистов предметной области, ответственных за организацию рас-сматриваемого процесса или участвующих в нем;
- анализировать существующие процессы и разрабатывать новые;
- определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов;
- определять ситуации, в которых требуется принятие решения, влияющего на ЖЦ процесса, например изменение конструктивных, технологических или эксплуатационных свойств ко—нечного продукта;
- содействовать принятию оптимальных решений при реорганизации процессов;
- разрабатывать имитационные модели технологических процессов, по принципу «как будет, если. «.
Моделирование в стандарте IDEF3 производится с использованием графического представления процесса, материальных и информационных потоков в этом процессе, взаимоотношений между операциями и объектами в процессе. Нотация визуального моделирования IDEF3 позволяет создать графическое описание логики взаимодействия информационных по-токов, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов, очередность их запуска и завершения. IDEF3 предоставляет инструмент моделирования сценариев действий сотрудников организации, отделов, и т.п. Например, на машиностроительном предприятии с помощью нотации IDEF3 можно описать порядок обработки заказа или события, на которые необходимо реагировать за конечное время, выполне-ние действий по производству товара и т.д.
Источник: studizba.com
Модели AS-IS и ТО-ВЕ
Модель AS-IS. В результате обследования предприятия в системе БПр выявляются «узкие» места — ненужные, неэффективные и дублирующие работы, а также работы, не обеспеченные ресурсами. Функциональная модель существующей организации работы — AS-IS («как есть») — строится с помощью CASE-средств, например программного продукта BPwin. При ее построении используются такие источники, как опросы экспертов (работников предприятия), документация (приказы, отчеты, должностные инструкции, положения о структурных подразделениях предприятия), анкетирование, фотография рабочего дня и др. Анализ функциональной модели позволяет:
- 1) специалистам, выполняющим работу по реинжинирингу, выявить недостатки существующего бизнеса и определить те области, в которых стоит производить изменения;
- 2) понять, как следует изменить бизнес-процессы (БПр), чтобы они удовлетворяли новым требованиям и целям;
- 3) оценить, насколько глубоким изменениям подвергнется существующая структура организации бизнеса;
- 4) объяснить сотрудникам, чем плохи прежние процедуры работы и почему они должны быть приспособлены к новым способам работы;
- 5) измерить характеристики тех БПр, которые следует изменить. Полученные измерения в дальнейшем могут быть использованы для оценки экономического эффекта проведенных изменений.
Структуризация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаком неэффективной деятельности могут быть бесполезные, неуправляемые и дублируемые работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат) и «входу» (объекты или информация используются нерационально) и т.д.
Одной из ошибок при создании модели AS-IS является создание идеализированной модели. Это происходит в том случае, когда модель создается на основе знаний руководителя, а не на основе опыта конкретного исполнителя работ. Руководитель в теоретическом аспекте осведомлен о том, как в соответствии с руководствами и должностными инструкциями предполагается выполнение работы, но часто не зна ет, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD BE («как должно бы быть»).
Модель ТО-BE. Обнаруженные в модели AS-IS недостатки можно исправить при создании модели ТО-BE («как будет») — модели новой организации бизнес-процессов. Модель ТО-BE нужна для оценки последствий внедрения информационной системы и анализа альтернативных, лучших путей выполнения работы и документирования того, как предприятие будет функционировать в будущем.
Как правило, строится несколько моделей ТО-BE (рис. 3.1), отображающих возможные траектории движения из существующего состояния системы БПр в будущие состояния. В соответствии с идеологией стрелы целеполагания возможны следующие траектории:
- • TO-BE 1 — оптимистический вариант структуризации БПр, связанный с реинжинирингом;
- • ТО-ВЕ 2 — наиболее вероятные варианты совершенствования БПр (в рамках инжиниринга);
- • ТО-ВЕ 3 — пессимистический вариант изменений БПр, связанный с учетом негативных SWOT-факторов.
Рис. 3.1. Построение моделей ТО-ВЕ как результат анализа модели AS-IS
Наибольший интерес представляет траектория 1, связанная с реинжинирингом БПр.
Реинжиниринг- фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность [92].
Имеется в виду не небольшое усовершенствование БПр компаний, например на 10—100%, а кардинальное повышение их эффективности, т.е. на порядок, что приводит к скачку результата.
Радикальное перепроектирование означает перепроектирование, затрагивающее суть (корень) явлений, а не поверхностные изменения, т.е. в ходе радикального перепроектирования отбрасываются все существующие структуры и процедуры и предлагается совершенно новый способ выполнения работы. Итак, реинжиниринг — это изобретение принципиально новых вариантов, а не улучшение, увеличение или модификация.
Проект по реинжинирингу бизнеса обычно включает следующие этапы [92]:
- 1) определение системы целей организации в соответствии с видением компании, учитывая ее стратегию и SWOT-факторы;
- 2) создание модели существующей организации (модель AS-IS («как есть»)). На этом этапе менеджеры с участием разработчиков информационной системы (ИС) должны разработать детальное описание существующей организации, идентифицировать и документировать ее основные БПр, оценить их эффективность;
- 3) разработка новой системы БПр (модель ТО-BE («как будет»)), которая предполагает:
- • перепроектирование БПр (создание более эффективных рабочих процедур, определение способов использования информационных технологий (ИТ), идентификация необходимых изменений в работе персонала),
- • разработку БПр с учетом параметров (количественный состав и квалификация персонала) трудового потенциала организации. На этом этапе организуются команды по выполнению работ во главе с лидером, подготавливается система мотивации и стимулирования, проектируются различные виды работ, создаются группы поддержки качества, составляются программы подготовки специалистов и т.д.,
- • разработку поддерживающих ИС. На этом этапе определяются имеющиеся ресурсы (оборудование, программное обеспечение) и реализуется специализированная ИС компании;
Реинжиниринг БПр необходимо проводить комплексно, в рамках стратегии, самоорганизующейся в соответствии с финишными целями предприятия. Радикальному перепроектированию должны быть подвергнуты:
- 1) система производства, включающая технологию производства продукции, номенклатуру и качество предлагаемых товаров, при этом требуется постоянная ориентация на потребителей;
- 2) система управления, включающая структуру организации, функции, нормативноорганизационные документы и т.д.
Подробно процессы самоорганизации рассмотрены в § 4.5.
Модели AS-IS и ТО-BE позволяют описать начальное и конечное состояния предприятия — до и после внедрения корпоративной информационной системы, оставляя без внимания сам процесс разработки (выбора) и внедрения. Но поскольку внедрение информационной системы — это тоже работа, то с помощью BPwin можно создать ее модель. Модель ТО-ВЕ — это не модель работы предприятия, а модель мероприятий по переводу его на новую технологию деятельности. Использование модели ТО-BE в совокупности со стоимостным анализом позволяет оценить объем средств, необходимых для приобретеиия/разработки и внедрения информационной системы. Можно построить несколько различных моделей ТО-BE с учетом внедрения различных информационных систем (как готовых, так и созданных на заказ) и выбрать оптимальный вариант.
Технология проектирования информационных систем также подразумевает создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т.е. создание модели ТО-BE. Только на основе модели ТО-BE строятся модель данных, прототип, а затем и окончательный вариант информационной системы. Результатом построения системы на основе модели AS-IS является автоматизация предприятия по принципу «все оставить как есть, только чтобы компьютеры стояли», т.е. информационная система автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. Внедрение и эксплуатация такой системы приводят лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого [70].
Источник: bstudy.net
Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть)
Обычно сначала строится модель существующей организации работы — AS-IS (как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, » кто что сделал» и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, » что мы делаем сегодня» перед тем, как перепрыгнуть на то, » что мы будем делать завтра».
Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем буду г состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.
Следует указать на распространенную ошибку при создании модели AS-IS — это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD-BE (как должно бы быть, хорошо бы так было).
Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу » все оставить как есть, только чтобы компьютеры стояли», т. е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.
Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состояния системы, поскольку такой переход — это тоже бизнес-процесс.
Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Report/Model Report. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рис. 5.13).
Model Name: Movie Rental
Definition: Учебная модель
Scope: Технологические, Финансовые и управленческие аспекты деятельности условного предприятия.
Viewpoint: Руководитель предприятия
Purpose: Описать функциональность предприятия с целью написания спецификаций информационной системы.
Рис. 5.13 — Отчет по модели
Источник: studopedia.info