Диаграмма последовательности

IBM Lotus Notes/Domino

• среда исполнения приложений автоматизации групповой деятельности

• криптозащита (шифрование и электронная подпись)

• клиент электронной почты

• почтовый сервер

• персональный и групповой календари, планировщик задач

• набор офисных приложений IBM Lotus Symphony (текстовый редактор, электронные таблицы, подготовка презентаций)

• клиент среды обмена мгновенными сообщениями (Instant messenger) Lotus Sametime (сервер Sametime является самостоятельным продуктом)

• репликация — синхронизация между дистанционно удалёнными экземплярами баз данных

• службы интеграции данных DECS (Domino Enterprise connection services)

• средство хранения вложенных файлов вне баз данных DAOS (Lotus Domino attachment and object services)

2. Технологии программирования, технологии проектирования баз данных.

Примеры технологий программирования

• Апплеты

• Клиент-сервер

• Servlets

• Remote method invocation

• Java server pages

Примеры технологий проектирования баз данных

- Язык SQL (обработка больших массивов данных)

• SELECT column1, column2 FROM table_name;

• SELECT * FROM table_name;INSERT INTO table_name (column1, column2, column3) VALUES (‘data1’, ‘data2’, ‘data3’);UPDATE table_name SET column1 = ‘data1’, column2 = ‘data2’ WHERE column3 = ‘data3’;DELETE FROM table_name WHERE column1 = ‘data1’;

- IDEF1x

3. Характерные черты компьютерных информационных технологий.

1. диалоговый режим решения задачи с широкими возможностями для пользователя;

2. сквозная информационная поддержка на всех этапах прохождения информации на основе интегрированной базы данных, предусматривающая единую унифицированную форму представления, хранения, поиска, отображения, восстановления и защиты данных;

3. безбумажный процесс обработки документа, при котором на бумаге фиксируется только окончательный вариант документа, а промежуточные версии и необходимые данные записаны на машинные носители;

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

5. возможность адаптивной перестройки формы и способа представления информации в процессе решения задачи.

4. Определение информационных систем. Классификация информационных систем. Их характеристика.

Классификация инф.систем

• 1. Ручные ИС характеризуются тем, что все операции по переработке информации выполняются человеком (Например: перо, чернильница, книга. Коммуникации осуществлялись ручным способом путем переправки через почту писем, пакетов, депеш. Основная цель технологии – представление информации в нужной форме).

• 2. Автоматизированные ИС - часть функций (подсистем) управления и обработки данных осуществляется автоматически, а часть - человеком. Автоматизированная система обработки экономической информации – комплексная человеко-машинная система, построенная на соответствующей информационной базе, позволяющая осуществлять все технологические операции над информацией и созданная для автоматизации человеческой деятельности в некоторой предметной области.

• 3. Автоматические ИС - все функции управления и обработки данных осуществляются техническими средствами без участия человека (например, автоматическое управление технологическими процессами) (Например: регулирование и защита паровых турбин; химическое производство; станции по перекачке нефти и газа. В них участие человека по тем или иным причинам невозможно, опасно или должно быть сведено к минимуму).

5. Однопользовательские и многопользовательские информационные системы.

Различают однопользовательские и многопользовательские ИС.

Однопользовательская ИС - локальный АРМ (автоматизированное рабочее место или рабочая станция) - совокупность информационно-программно-технических ресурсов, обеспечивающих конечному пользователю обработку данных и автоматизацию управленческих функций в конкретной предметной области.

Такой программно-технический комплекс, предназначен для реализации управленческих функций на отдельном рабочем месте, информационно и функционально не связан с другими ИС (АРМ).К таким ИС можно отнести АРМ бухгалтера малого предприятия, АРМ кассира, АРМ расчетчика заработной платы и т.п.

АРМ (автоматизированное рабочее место)- это совокупность аппаратных и программных средств и методов, позволяющих пользователю на современном уровне выполнять свои функциональные обязанности.

Сфера применения АРМ необычайно широка. Они используются при автоматизации управления на промышленных предприятиях, в научных организациях, в организациях любого профиля. Например, это:

• АРМ экономиста (это автоматизация задач планово-финансового управления).

• АРМ бухгалтера (это автоматизация задач учета материальных ценностей, труда и заработной платы, составление отчетности и т.д.).

• АРМ руководителя (это автоматизация задач руководителя любого уровня по сбору, обработке больших объемов информации, по ее анализу в различных разрезах, по моделированию процессов и ситуаций, по структурированию данных для принятия управленческих решений).

Многопользовательские ИС в зависимости от масштаба и интеграции компонентов ИС могут быть следующих видов:

1. комплекс информационно и функционально связанных АРМ, реализующих в полном объеме функции управления (рабочая группа);

2. компьютерная сеть АРМ на единой информационной базе, обеспечивающая интеграцию функций в масштабе предприятия или группы бизнес-единиц;

корпоративная ИС (КИС), обеспечивающая полнофункциональное распределенное управление крупномасштабным предприятием.

6. Понятие корпоративной информационной системы. Структура корпоративной информационной системы. Примеры корпоративных информационных систем.

Под корпоративной информационной системой (КИС) будем понимать информационную систему масштаба предприятия.

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

Основное назначение КИС – оперативное предоставление непротиворечивой, достоверной и структурированной информации для принятия управленческих решений.

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

Основой для построения таких систем служат локальные вычислительные сети.

КИС имеют следующие характерные черты:

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

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

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

• развитая технология объединения и консолидация данных удаленных подразделений.

• наличие корпоративной БД.

ü Под корпоративной БД понимают БД, объединяющую в том или ином виде все необходимые данные и знания об автоматизируемой организации. Создавая КИС, разработчики пришли к понятию интегрированных БД, в которых реализация принципов однократного ввода и многократного использования информации нашла наиболее концентрированное выражение.

В настоящее время наряду с названием КИС употребляются, например, следующие названия:

• Автоматизированные системы управления (АСУ);

• Интегрированные системы управления (ИСУ);

• Интегрированные информационные системы (ИИС);

• Информационные системы управления предприятием (ИСУП).

7. Характерные черты MRP, ERP, CRM.

• MRP- англ. Material Requirement Planning — планирование потребности в материалах) — система планирования потребностей в материалах.

Характеристика:

ü удовлетворение потребности в материалах, компонентах и продукции для планирования производства и доставки потребителям;

ü поддержка низких уровней запасов;

ü планирование производственных операций, расписаний доставки, закупочных операций.

ü ERP- ERP (англ. Enterprise Resource Planning, планирование ресурсов предприятия) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения, обеспечивающего общую модель данных и процессов для всех сфер деятельности.

ü ERP-система — конкретный программный пакет, реализующий стратегию ERP.

Модули ERP

• Модульный принцип организации позволяет внедрять ERP-системы поэтапно, переводя в эксплуатацию один или несколько функциональных модулей на каждом этапе, а также выбирать организации только те из них, которые актуальны для организации.

• Разбивка по модулям и их группировка различная, но у большинства основных поставщиков выделяются группы модулей: финансы, персонал, операции.

Пример ERP - система «КОМПАС».

• CRM - Система управления взаимоотношениями с клиентами (англ. Customer Relationship Management) — прикладное программное обеспечение для организаций, предназначенное для автоматизации стратегий взаимодействия с заказчиками, в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процедур и последующего анализа результатов.

• Функциональные возможности CRM

• Управление продажами (SFA — англ. Sales Force Automation)

• Управление маркетингом

• Управление клиентским обслуживанием и колл-центрами (системы по обработке обращений абонентов, фиксация и дальнейшая работа с обращениями клиентов)

Примеры CRM систем:

• BS CRM

• Microsoft Dynamics CRM

• NetSuite CRM

• Oracle CRM On Demand

• SAP Business One

• Социальный CRM

• SCM - Supply Chain Management — системы управления цепочками поставок

• SRM - Supplier Relationship Management (Управление взаимоотношениями с поставщиками)

• и пр.

8. Стандартизация и сертификация в информационных технологиях. Международные стандарты ISO/OSI 12207.

Рынок ИТ имеет следующие особенности:

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

• не существует банков данных продукции, ограничено создание рекламных бюллетеней;

• не проводятся маркетинговые исследования цепочки "пользователь–производитель" на основе зависимости "цена—конкурентоспособность".

В Беларуси совершенствуется информационный бизнес и ведутся работы в следующих аспектах:

• правовой аспект— совершенствуются законодательные нормы, правовой статус методов и форм защиты информации;

• технический — разрабатывается и совершенствуется система стандартизации, оценки качества и унификации ИС, ТО и ПО;

• организационный — формируется информационная инфраструктура и организация технологических процессов обработки информации;

• экономический — исследуются закономерности формирования рынка ИТ, оценки конкурентоспособности, формирования системы маркетинга.

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

• Важную роль при создании корпоративных информационных систем играют стандарты ISO/OSI (International Organization/Open System Interconnect), то есть стандарты открытых вычислительных систем (модульность, открытость и т.д.).

• ISO/OSI 12207 - определяет структуру жизненного цикла программного обеспечения.

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

• Разработан в 1995 г. объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения». Включает описание основных, вспомогательных и организационных процессов.

9. Основные процессы разработки ПО (ISO 12207).

ISO/OSI 12207 определяет следующую структуру жизненного цикла ПО, основанную на трех группах процессов:

• основные процессы жизненного цикла ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

• организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла ПО, обучение).

• • процесс приобретения, определяющий действия покупателя, приобретающего информационную систему, программный продукт или его сервис;

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

• • процесс разработки, определяющий действия разработчика принципов построения программного изделия;

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

• процесс сопровождения, регламентирующий действия персонала по модификации программного продукта, поддержке его текущего состояния и функциональной работоспособности.

Вспомогательные процессы регламентируют документирование, управление конфигурацией, обеспечение качества, верификацию, аттестацию, совместную оценку, аудит.

Стандарт предполагает базовый набор взаимосвязей между процессами с различных точек зрения, т.е. в различных аспектах

•
Степень обязательности для организации, принявшей решение о применении ISO/IEC 12207, обусловливает ответственность в условиях торговых отношений за указание минимального набора процессов и задач, требующих согласования с данным стандартом.

• Стандарт содержит мало описаний, направленных на проектирование баз данных, что объясняется наличием отдельных стандартов по данной тематике.

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

• Модель жизненного цикла ПО зависит от специфики ИВС и специфики условий, в которых последняя создается и функционирует.

• Регламенты жизненного цикла ПО являются общими для любых моделей жизненного цикла, методологий и технологий разработки.

• Стандарт ISO/IEC 12207 описывает структуру процессов жизненного цикла ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

10. Модели жизненного цикла программного обеспечения (ПО). Каскадная модель.

Каскадная модель (70-85 г.г.)- ее основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

• Основным недостатком каскадного подхода является существенное запаздывание с получением результатов.

• Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания.

• Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена.

• В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям.

• Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.

11. Модели жизненного цикла программного обеспечения (ПО). Спиральная модель.

Спиральная модель (86-90 г.г.) – это модель с упором на начальные этапы жизненного цикла - анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

• Основная проблема спирального цикла - определение момента перехода на следующий этап.

• Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла.

• Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена.

• План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

12. Методология RAD.

Методология быстрой разработки приложений RAD (Rapid Application Development).

Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

• небольшую команду программистов (2-10 человек);

• короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

Основные принципы методологии RAD:

• разработка приложений итерациями;

• необязательность полного завершения работ на каждом из этапов жизненного цикла ПО;

• обязательное вовлечение пользователей в процесс разработки ИС;

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

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

• тестирование и развитие проекта, осуществляемые одновременно с разработкой;

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

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

В методологии RAD:

• работающее ПО ценится выше всеобъемлющей документации;

• сотрудничество с заказчиками ценится выше формальных договоров;

• реагирование на изменения ценится выше строгого следования плану.

• При этом следует понимать - при всех достоинствах быстрой разработки ПО этот подход применим только в проектах малого и среднего масштаба (1-6-20 разработчиков) и с низкой критичностью (дефект - это потеря удобства, но не опасность для жизни).

13. Технологии нисходящего и восходящего проектирования.

Технология нисходящего проектирования Базируется на методе "сверху-вниз" или "пошаговой детализации". В основе идея постепенной декомпозиции задачи на подзадачи. Сначала - грубая модель, потом детализация алгоритмов. Потом разработка отдельных блоков, называемых часто подпрограммами.

• Нисходящее проектирование – пошаговый процесс, который начинается с наиболее общей функции, разбивает ее на подфункции, а затем процесс повторяется для каждой подфункции до тех пор, пока все подфункции не станут настолько малыми и простыми, чтобы их можно было закодировать программными инструкциями.

• На первом этапе разработка кодируется, тестируется и отлаживается головной модуль, который отвечает за логику работы всего программного комплекса.

• Остальные модули заменяются заглушками, имитирующими работу этих модулей.

• Применение заглушек необходимо для того, чтобы на самом раннем этапе проектирования можно было проверить работоспособность головного модуля.

• На последних этапах проектирования все заглушки постепенно заменяются рабочими модулями.

Недостатки:

Ø Необходимость заглушек.

Ø До самого последнего этапа проектирования неясен размер программного комплекса и его эксплуатационные характеристики, за которые, как правило, отвечают модули самого низкого уровня.

Преимущества:

Ø На самом начальном этапе проектирования отлаживается головной модуль (логика программы).

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

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

Недостатки:

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

Преимущества:

Ø не нужно писать заглушки.

На практике применяются оба метода. Метод нисходящего проектирования чаще всего применяется при разработке нового программного комплекса, а метод восходящего проектирования – при модификации уже существующего комплекса.

14. Основные принципы проектирования, их характеристика.

Проектирование сложных объектов базируется на следующих основных принципах:

• декомпозиция и иерархичность описания объектов;

• многоэтапность и итерационность проектирования;

• типизация и унификация проектных решений и средств проектирования.

• Принцип иерархичности означает структурирование представлений об объектах проектирования по степени детальности описаний,

• принцип декомпозиции – разбиение представлений каждого уровня на ряд составных частей с возможностями раздельного проектирования.

• Проектирование сложного объекта (как системы взаимосвязанных и взаимодействующих элементов) включает ряд последовательных этапов: предпроектные исследования, разработка технического задания, эскизного, технического, рабочего проектов, испытаний и внедрения. Система может разрабатываться в условиях, когда ее элементы не определены (нисходящее проектирование), и элементы могут проектироваться раньше системы (восходящее проектирование).

• Проектирование представляет собой итерационный процесс, в котором попеременно выполняются процедуры внешнего и внутреннего проектирования. Внешнее – разработка технического задания на систему, а внутреннее – проектирование по сформулированному техническому заданию.

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

• Унификация целесообразна в таких классах объектов, в которых на основе спроектированного небольшого числа разновидностей элементов предстоит проектирование большого числа разнообразных систем.

15. Структурный подход к проектированию информационных систем (особенности, принципы).

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

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

При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.

• Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:

Ø принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

Ø принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

Другие не менее важные принципы:

• принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;

• принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

• принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

16. Методология SADT.

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

Ø SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

Ø DFD (Data Flow Diagrams) диаграммы потоков данных;

Ø ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

Методология SADT (Structured Analisys and Design Technique - технология структурного анализа и проектирования) разработана Дугласом Т. Россом в 1969-1973 годах. SADT успешно использовалась в военных, промышленных и коммерческих организациях для решения широкого спектра задач, таких как программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, встроенное ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. данная методология широко поддерживается Министерством обороны США, которое было инициатором разработки стандарта IDEF0 как подмножества SADT. Наряду с растущей автоматизированной поддержкой, сделало ее более доступной и простой в употреблении.

Процесс моделирования в SADT включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели и уточнение модели.

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

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

17. Характеристика нотации IDEF0. Правила построения моделей и использования блоков.

Новое название методологии SADT, принятое в качестве стандарта - IDEF0 (Icam DEFinition) - часть программы ICAM (Integrated Computer-Aided Manufacturing - интегрированная компьютеризация производства), проводимой по инициативе ВВС США.

Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующего уровня.

Эти блоки представляют подфункции (подмодули) исходной функции.

Каждый из подмодулей может быть декомпозирован аналогичным образом.

Число уровней не ограничивается, зато рекомендуется на одной диаграмме использовать не менее 3 и не более 6 блоков.

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

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

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

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

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

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

• Связь по входу (input-output), когда выход вышестоящей работы направляется на вход следующей работы.

• Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление следующей работы. Связь показывает доминирование вышестоящей работы.

• Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Используется для описания циклов.

• Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей. Является показателем эффективности бизнес-процесса.

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

18. Общая характеристика и особенности разработки диаграмм потоков данных DFD. Основные элементы диаграммы.

DFD (Data Flow Diagrams)- используются для описания движения документов и обработки информации как дополнение к IDEF0.

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы и стрелки представляют собой жесткие взаимосвязи, стрелки в DFD показывают лишь то, как объекты (включая данные) движутся от одной работы к другой.

DFD отражает функциональные зависимости значений, вычисляемых в системе, включая входные значения, выходные значения и внутренние хранилища данных.

DFD - это граф, на котором показано движение значений данных от их источников через преобразующие их процессы к их потребителям в других объектах.

DFD содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.

• Процессы. Процесс преобразует значения данных. Процессы самого нижнего уровня представляют собой функции без побочных эффектов (примерами таких функций являются вычисление суммы двух чисел, вычисление комиссионного сбора за выполнение проводки с помощью банковской карточки и т.п.). Весь граф потока данных тоже представляет собой процесс (высокого уровня). На DFD процесс изображается в виде эллипса, внутри которого помещается имя процесса; каждый процесс имеет фиксированное число входных и выходных данных, изображаемых стрелками.

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

• Активные объекты. Активным называется объект, который обеспечивает движение данных, поставляя или потребляя их. Активные объекты обычно бывают присоединены к входам и выходам DFD.

• Хранилища данных. Хранилище данных - это пассивный объект в составе DFD, в котором данные сохраняются для последующего доступа. Хранилище данных допускает доступ к хранимым в нем данным в порядке, отличном от того, в котором они были туда помещены. Агрегатные хранилища данных, как, например, списки и таблицы, обеспечивают доступ к данным в порядке их поступления, либо по ключам.

• Потоки управления. DFD показывает все пути вычисления значений, но не показывает в каком порядке значения вычисляются. Решения о порядке вычислений связаны с управлением программой, которое отражается в динамической модели. Эти решения, вырабатываемые специальными функциями, или предикатами, определяют, будет ли выполнен тот или иной процесс, но при этом не передают процессу никаких данных, так что их включение в функциональную модель необязательно.

19. Диаграммы ERD. Основные особенности.

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) — модель данных, позволяющая описывать концептуальные схемы. Представляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных.

ER-модель удобна при прототипировании (проектировании) информационных систем, баз данных, архитектур компьютерных приложений, и других систем (далее, моделей). С её помощью можно выделить ключевые сущности, присутствующие в модели, и обозначить отношения, которые могут устанавливаться между этими сущностями.

Используемые нотации для ERD диаграмм:

• Нотация Питера Чена

• Нотация IDEF1x

• Нотация Мартина

• Нотация Баркера.

20. Нотация Питера Чена. Нотация IDEF1x.

Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (Peter Pin-Shen Chen) – американским профессором компьютерных наук в университете штата Луизиана.

Множества сущностей по Чену изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов. Если сущность участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная. Атрибуты изображаются в виде овалов и связываются линией с одним отношением или с одной сущностью.

Базовые понятия ERD:

• Сущность (Entity) — это множество реальных или абстрактных объектов (людей, мест, событий), обладающих общими атрибутами или характеристиками.

• Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована.

• Пример. Сущность – Студент. Экземпляр сущности – студент Иванов И.И.

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

• Атрибут (Attribute) — характеристика сущности.

• Пример. Сущность «Студент» имеет атрибут «ФИО».

• Экземпляр сущности «студент» (конкретный человек) будет иметь экземпляр атрибута «ФИО» (например, Иванов И.И.)

• Каждая сущность может обладать любым количеством связей с другими сущностями модели.

• Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.

21. Характеристика и особенности применения стандарта IDEF3. Особенности построения диаграмм PFDD.

IDEF3 -стандарт документирования информац-х, технологич. и иных процессов, происх-х на предприятии, и предоставляет инструментарий для моделирования сценариев. Сценарием (Scenario) мы называем описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса.

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах:

o Диаграммы относящиеся к первому типу называются диаграммами описания последовательности этапов процесса (PFDD),

o а ко второму - диаграммами состояния объекта в и его Трансформаций Процессе. (Object State Transition Network, OSTN). Иное встречающееся название для PFDD - диаграмма работ WFD (Work Flow Diagram).

С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса.

Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса.

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация типов перекрестков

Синхронное(||&||) асинхронное(||&|) «И», синхронное(||O||) асинхронное (||O|)«ИЛИ»,эксклюзивное «ИЛИ»(||X|).

Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 1, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер "1", то блоки UOB на его декомпозиции будут соответственно иметь номера "1.1", "1.2" и т.д.

22. Характеристика и особенности применения стандарта IDEF3. Особенности построения диаграмм OSTN.

IDEF3 является стандартом документирования информационных, технологических и иных процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарием (Scenario) мы называем описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса.

На промышленном предприятии документооборот производственных процессов состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление об его сценарии и структуре сопутствующего документооборота.

o Диаграммы относящиеся к первому типу называются диаграммами

Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD),

o а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе. (Object State Transition Network, OSTN). Иное встречающееся название для PFDD - диаграмма работ WFD (Work Flow Diagram).

· Если диаграммы PFDD технологический процесс "С точки зрения наблюдателя", то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс "С точки зрения объекта". На рис. представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

· Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB "Окрасить Деталь", представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 1, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер "1", то блоки UOB на его декомпозиции будут соответственно иметь номера "1.1", "1.2" и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.

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

UML (Unified Modeling Language — унифицир-й язык моделирования) — язык графич описания для объектного моделирования в области разраб. ПО. UML - открытый стандарт, использующий графич обозначения для создания абстрактной моделисистемы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

Диагр прецентов (диагр. вар-в использования) описывает функц-е назначение системы, т.е. то, что система будет делать в процессе своего функционирования; явл. исх. концептуальной моделью системы в процессе ее проектир-ния и разработки. Суть диагр: проектируемая система представляется в виде мн-ва сущностей или актеров (действующих лиц), взаим-щих с системой с пом. так называемых вар-в использования (прецедентов). Основными компонентами ДВИ являются: актеры, прецеденты, отношения. Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.

Диагр. взаимодействий явл моделями, опис-щими поведение взаимод-щих групп объектов. Суще-ют 2 вида диагр взаимодействий:

§ диаграммы последовательности действий – sequence diagram;

§ диагр.кооперации (кооперативные диаграммы) – collaboration diagram

Диаграммы последовательности действий отображают взаимодействие объектов, упорядоченное по времени.

Основными компонентами диаграмм последовательности действий являются:- Объекты;- Линия жизни; - Сообщения.

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

Кооперация. (collaboration) - служит для обозначения множества взаимодействующих с определенной целью объектов в общем контексте моделируемой системы. Основные компоненты диаграммы кооперации:

- объекты(активный, паасивный, мультиобъект,составной); связи; сообщения.

На диагр кооперации изобр-ся только такие отношения м/у объектами, кот играют роль информац-х каналов при взаимодействии.

На диагр. кооперации не указывается время в виде дополнит. измерения.

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

Унифицированный язык моделирования (Unified Modeling Language - UML) - это язык для специфицирования, визуализации, конструирования и документирования на основе объектно-ориентированный подхода разные виды систем: программных, аппаратных, программно-аппаратных, смешанных, явно включающие деятельность людей и т. д.

UML предназначен для:

1)Визуализации 2)Специфицирования 3)Конструирования

4) Документирования артефактов преимущественно программных систем.

Применение UML позволяет использовать стандартные способы для демонстрации проекта всем заинтересованным сторонам

UML – это открытый стандарт

Диаграмма состояний

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

Диаграмма последовательности

Позволяет отразить последовательность передачи сообщений между объектами. Обычно используются для моделирования потоков управления путем упорядочения по времени.

Диаграммы последовательности это диаграммы взаимодействия, которые подчеркивают упорядоченность сообщений по времени. Диаграммы последовательности показывают множество объектов и сообщений, посылаемых и получаемых этими объектами.

Объекты – это обычно именованные или анонимные экземпляры (instances) классов, однако они могут также представлять экземпляры других элементов (things), таких как кооперации, компоненты и узлы. Диаграммы последовательности используются для иллюстрации динамического представления (view) системы.

25. Унифицированный язык моделирования UML. Диаграммы классов. Диаграммы развертывания.

Унифицированный язык моделирования - это язык для специфицирования, визуализации, конструирования и документирования на основе объектно-ориентированный подхода разные виды систем: программных, аппаратных, программно-аппаратных, смешанных, явно включающие деятельность людей и т. д.

Диаграммой классов называется диаграмма, на которой показан набор классов, интерфейсы, объекты, кооперации и их отношения. При моделировании объектно-ориентированных систем этот вид диаграмм используется наиболее часто. На данной диаграмме не указывается информация о временных аспектах функционирования системы.

Класс в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции (рис. 5.1).

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

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

Унифицированный язык моделирования (UML) - это язык для специфицирования, визуализации, конструирования и документирования на основе объектно-ориентированный подхода разных видов систем: программных, аппаратных, программно-аппаратных, смешанных, явно включающие деятельность людей и т. д.

На диаграммах классов обычно показывают классы, интерфейсы, объекты, кооперации и их отношения. Они соответствуют статическому виду системы с точки зрения процессов.

Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который может быть разделен горизонтальными линиями на разделы. В этих разделах могут указываться имя класса (обязат. элемент), атрибуты и операции.

Атрибут = свойство, которое является общим для всех объектов данного класса.

Операция (operation) представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию.

Базовыми отношениями на диаграмме классов являются:

· отношения ассоциации (association);

· отношения обобщения (generalization);

· отношения агрегации (aggregation);

· отношения композиции (composition);

· отношения зависимости (dependency

Диаграммы компонентов

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

1.компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций;

2.компоненты-рабочие продукты (файлы с исходными текстами программ);

3.компоненты исполнения, представляющие исполнимые модули - файлы с расширением ехе.

27. Сущность и принципы реинжиниринга бизнес-процессов (РБП). Этапы проекта РБП.

Реинжиниринг бизнес-процессов – это в фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность (М. Хаммер и Дж. Чампи)

Можно выделить три типа компаний, для которых реинжиниринг необходим и целесообразен:

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

• Компании, не имеющие в текущий момент затруднений, но предвидящие неизбежность возникновения трудноразрешимых проблем.

• Компании, не имеющие проблем сейчас, но прогнозирующие их в обозримом будущем. Это компании-лидеры, проводящие агрессивную маркетинговую политику желающие с помощью реинжиниринга добиться лучшего.

Принципы реинжиниринга:

¨ Горизонтальное сжатие процесса

¨ Вертикальное сжатие процесса

¨ Распараллеливание шагов процесса

¨ Многовариантность исполнения процессов

¨ Единая точка контакта с клиентом

¨ Делегирование полномочий по принципу «сверху вниз»

¨ Децентрализация бизнеса и централизация информации

Этапы проекта РБК:

1)разработка образа будущей компании

2)создание модели существующей компании(обратный инжиниринг)

3)разработка нового бизнеса(прямой инжиниринг)

-перепроектирование бизнес-процессов

-разработка бизнес-процессов компании на уровне трудовых ресурсов

-разработка поддерживающих информационных систем

4)внедрение перепроетированных процессов.

28. Сущность и принципы реинжиниринга бизнес-процессов (РБП). Альтернативные подходы к совершенствованию деятельности и их отличие от РБП.

Альтернативные подходы к совершенствованию деятельности:

• автоматизация бизнес-процессов – применение машин, машинной техники и технологии с целью облегчения человеческого труда, вытеснения его ручных форм, повышения его производительности

Как правило, приводит к ускорению бизнес-процесса, автоматизируя его со всеми недостатками. Не ставит перед собой основную задачу реинжиниринга – проектирование нового процесса, благодаря чему достигаются основные результаты.

• программный реинжиниринг (software reengineering)- реинжиниринг, который перестраивает существующие информационные системы, переводя их на более современные технологии

С позиции структуры бизнес-процессов (их оптимизации) программный реинжиниринг часто не обеспечивает ничего, кроме создания информационных систем более высокого уровня, автоматизируя при этом старые процессы. Суть автоматизируемых процессов не меняется.

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

Например, на рынке падает спрос на автомобили компании GM, и эта компания должна быть способна перестроить производство (с минимальными затратами) на уменьшение количества выпускаемых автомобилей.

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

• реструктуризация предприятий – комплекс мероприятий по организационной, управленческой, имущественной, финансовой и технической адаптации предприятия к условиям экономики, а также по изменению номенклатуры выпускаемой продукции в целях повышения эффективности производства. При реструктуризации новая модель бизнеса может одновременно отвечать признакам функциональной и командно-процессной ориентации. При реинжиниринге только процессной ориентации

• улучшение качества (quality improvement) и всеобщее управление качеством (total quality management). Управление качеством за основу принимает существующие процессы, которые требуется улучшить (делать то, что делали, но только лучше)

Для справки

Total Quality Management — философия всеобщего управления качеством, успешно стартовавшая много лет назад в Японии и США с практики присуждения наград компаниям, достигшим высшего качества производимой продукции.

Главная идея TQM состоит в том, что компания должна работать не только над качеством продукции, но и над качеством организации работы в компании, включая работу персонала. Постоянное параллельное усовершенствование 3-х составляющих:

q качества продукции;

q качества организации процессов;

q уровня квалификации персонала;

— позволяет достичь более быстрого и эффективного развития бизнеса.

Качество определяется следующими категориями:

Ø степень реализации требований клиентов;

Ø рост финансовых показателей компании;

повышение удовлетворенности служащих компании своей работой.

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

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

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

• инжиниринг бизнеса – набор приемов и методов, которые компания использует для проектирования бизнеса в соответствии со своими целями

(Реинжиниринг бизнес-процессов – это в фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность (М. Хаммер и Дж. Чампи)