Ершова Г.Н. Информационные технологии в книжном деле. Учебное пособие

Подождите немного. Документ загружается.

Пользователь − работник, который осуществляет взаимодействие с

информационной системой на своем рабочем месте в рамках своих

функциональных обязанностей.

Конечно, это далеко не полный перечень персонала, занятого на всех этапах

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

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

языках программирования; тестерах − специалистах, которые занимаются тестированием

готовой системы в реальных условиях с целью выявления всех ошибок

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

данных и занимаются ее оптимизацией в соответствии с требованиями, поставленными в

техническом задании. Необходимость привлечения этих специалистов зависит от

масштаба и способа создания информационных систем. В случае создания

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

небольшого и среднего предприятия можно обойтись только ролями заказчика, аналитика

и пользователя.

Этапы создания информационных систем

Наиболее важным этапом жизненного цикла информационной системы является

этап формирования и анализа требований к информационной системе, заканчивающийся

разработкой технического задания на создание системы.

Качество анализа и документов, подготовленных на данном этапе, закладывают

основу качества всей системы. Данный этап целесообразно проводить вне зависимости от

того программного обеспечения (готовая система или собственная разработка), которое

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

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

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

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

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

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

Если основная ответственность за качество выполнения последующих этапов

(проектирование, реализация, сопровождение) лежит на технических специалистах

(аналитик, программист), то качество этапов анализа и внедрения, в равной степени

зависит от аналитиков и заказчиков информационной системы. Лица, принимающие

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

этих этапов, состав работ, выполняемых на данном этапе, и документах получаемых по их

окончании.

Формирование и анализ требований — это наиболее трудоемкий и ответственный

этап создания информационной системы. Именно здесь формируется концепция будущей

информационной системы, закладываются основы технологии автоматизированной

деятельности.

Рассмотрим подробнее этап формирования анализа требований к информационной

системе. В его составе можно выделить следующие стадии:

Анализ первичных требований − это подготовительный этап работ. Его основной

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

информационной системе. Рассматриваются существующие механизмы управления,

схемы снабжения и реализации товаров, движение финансовых и товарных потоков,

анализируется существующий документопоток.

По окончании этой стадии заказчики в лице первых лиц предприятия должны

понимать, в чем будут состоять преимущества внедряемой системы, ее отличия от

существующей, основные функциональные возможности новой информационной

системы, а также объем необходимых финансовых и временных затрат для выполнения

последующих стадий. Следует подчеркнуть, что лица, принимающие решение о создании

информационной системы, должны понимать и оценивать ее функциональные

возможности не только на основании текущих потребностей в автоматизации, но и на

основании стратегии развития организации на ближайшие 5-7 лет. На этапе анализа

определяются границы создаваемой информационной системы, то есть те подразделения

или функции предприятия, которые нуждаются в автоматизации. По окончании анализа

первичных требований осуществляется планирование дальнейших работ, уточняются

сроки создания и внедрения информационной системы, определяется финансирование,

необходимое для выполнении каждого из этапов.

Детальное изучение предприятия. В рамках этой стадии проводится:

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

определение организационной структуры предприятия, его территориального

расположения;

определение перечня целевых задач (функций) предприятия;

распределение функций предприятия по его отдельным подразделениям

(сотрудникам);

исследование используемых на предприятии средств автоматизации.

Результатом указанной стадии должно быть формализованное описание функций

каждого подразделения предприятия, и их взаимодействия между собой и с внешней

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

выявлены внешние объекты.

Построение модели «как есть». Эта модель является описанием существующей

организационной, информационной, технологической структуры предприятия на момент

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

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

товарного, финансового потоков и документопотоков.

Построение модели «как должно быть». На основании анализа модели «как есть»

необходимо выявить «узкие места» и наиболее острые проблемы в технологической

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

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

выявленных проблем стоится модель «как должно быть», отражающая представление о

новых технологиях работы организации.

Заметим, что построенные модели могут иметь самостоятельное практическое

значение. Например, модель «как есть» позволяет выявить узкие места в существующих

технологиях предприятия и предложить рекомендации по их последующему решению.

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

диаграмм и целостного представления об организации.

По окончании этапа анализа целесообразно сформировать и согласовать документ,

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

назначение документа подобного рода:

Довести до сведения управленческого персонала и всех заинтересованных лиц

организации последовательность реализации проекта, его цели и задачи.

Доказать необходимость и важность проекта. Четко сформулировать

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

Оценить границы проекта, перечислив участки и бизнес-процессы, которые будут

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

все условия проекта с его заказчиками и разработчиками.

Распределить ответственность, права и обязанности по реализации проекта среди

разработчиков и лиц, заинтересованных в информационной системе.

Регламентировать процедуры внесения изменений в проект и решения спорных

вопросов.

На этапе проектирования на основании данных этапа формирования и анализа

требований разрабатывается системный проект (модель требований), в котором должны

быть собраны и формализованы все требования заказчика. Системный проект отвечает на

вопрос «Что должна делать будущая система?».

После согласования системного проекта с заказчиком осуществляется разработка

предложений по автоматизации, включающая:

определение состава информационной системы, основных ее модулей, способов

взаимодействия между ними;

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

определение очередности проектирования и внедрения подсистем;

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

На основании принятых решений о стратегии автоматизации и согласованного

системного проекта осуществляется разработка технического проекта.

Технический проект отвечает на вопрос «Как построить систему, что бы она

удовлетворяла предъявленным к ней требованиям?». На данном этапе определяются:

общая информационная модель системы, функциональная модель системы в целом и

отдельных ее модулей, способы взаимодействия между отдельными модулями

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

системе.

На основании технического проекта осуществляется реализация информационной

системы − кодирование системы с использованием языков программирования.

Результатом этапа реализации является готовая система, удовлетворяющая всем

согласованным требованиям, описанным в системном проекте.

На этапе внедрения происходит установка системы, ее интеграция с другими

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

информационных систем в эксплуатацию требуется ввод начальных данных и перенос

данных, имеющихся в старой системы в новую. На этапе внедрения осуществляется

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

обычно фиксируется в виде акта о выполненных работах.

Заметим, что при внедрении готового программного обеспечения стадии

проектирования и внедрения обычно объединяются, а стадия реализация отсутствует. Это

связано с тем, что готовое программное обеспечение уже имеет определенную структуру,

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

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

отдельных групп пользователей.

Основными задачами этапа эксплуатации и сопровождения является:

• поддержка информационной системы в работоспособном состоянии в

соответствии с пользовательской документацией;

• сопровождение − внесение изменений в программное обеспечение в целях

исправления ошибок, повышения производительности или адаптации к

изменившимся требованиям. При этом вносимые изменения не должны

нарушать концепцию информационной системы, ее структуры.

Современные методы построения моделей бизнес-процессов

Бизнес-процесс – целенаправленная последовательность процедур,

предназначенная для получения заданного конечного результата. При этом он

состоит из связанного набора повторяемых операций, которые преобразуют

исходную информацию (материал) в конечный продукт (услугу) в соответствии с

предварительно установленными правилами.

Функция (или процедура) – упорядоченная последовательность операций,

предназначенная для получения промежуточного результата бизнес-процесса.

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

рамках создаваемой модели нецелесообразно.

Одним из основных этапов, как было показано выше, создания информационной

системы предприятия является этап «формирование и анализ требований». В рамках этого

этапа осуществляется моделирование бизнес-процессов организации − процесс отражения

существующего в организации потока работ в виде модели процессов. Основой

моделирования любого процесса является детальное описание его содержания.

Среди современных методов построения моделей бизнес-процессов ключевое

место занимают структурное и объектно-ориентированное моделирование.

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

представлении бизнес-процессов в виде последовательности функций с декомпозицией до

неделимых операций.

Достоинством структурного подхода является графическая простота и наглядность

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

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

трудоемкость в построении моделей.

Объектно-ориентированный подход основан на представлении предметной

области в виде объектов, взаимодействующих между собой посредством передачи

сообщений. Основным понятием объектно-ориентированного подхода является объект.

Каждый объект характеризуется некоторым набором присущих ему состояний и

операций, выполняемых для проверки и изменения этих состояний. Объекты

объединяются в классы. Все представители одного и того же класса имеют один и тот же

набор операций и могут реагировать на одни и те же сообщения.

Для описания бизнес-процессов с использованием объектно-ориентированной

методологии в настоящее время широко применяется унифицированный язык

моделирования UML (Unified Modeling Language).

Объектно-ориентированный подход проектирования и разработки программного

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

также позволяет более качественно выделить операции, осуществляемые над объектами и

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

заключается в меньшей наглядности конкретных процессов.

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

Выбор того или иного похода определяется конечными целями и задачами

моделирования.

Остановимся более подробно на структурном подходе к моделированию бизнес-

процессов в основе которого лежит метод структурного анализа или SADT-методология

(Structured Analysis and Design Technique – Технология структурного анализа и

проектирования). Первоначально метод SADT применялся для моделирования

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

силами США, после чего в 1993 году был принят в качестве федерального стандарта США

под наименованием IDEF0 (Integration computer aided manufacturing Definition).

Метод SADT представляет собой совокупность правил и процедур,

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

Функциональная модель SADT представляется в виде последовательности

взаимосвязанных бизнес-процессов.

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

фрагментов текста и глоссария. Диаграммы − главные компоненты модели. Достоинством

SADT диаграммы является ее достаточно простое графическое представление,

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

В SADT диаграммах используется всего два графических элемента:

функциональный блок − описание функций, операций, действий, и интерфейсная дуга,

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

Элементарный графический блок представлен на рисунке 5.

На рисунке 5 показано, что каждый блок имеет входы четырех типов:

вход (входная информация),

выход (выходная информация),

управление (управляющая информация),

механизм (исполнитель, который осуществляет операцию, человек,

информационная система и пр.).

ФУНКЦИЯ

(процесс)

УПРАВЛЕНИЕ

(инструкция, норматив,

план, ограничение)

ВХОД

(материальный объект,

документ)

ВЫХОД

(материальный объект,

документ)

МЕХАНИЗМ

(исполнитель)

рис. 5 Элементарный графический блок представления процесса в IDEF0

Входы одного блока могут быть выходами или управлением для других.

Рассмотрим в качестве примера построение функциональной модели процесса

закупки книжным магазином книжных товаров для формирования розничного

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

разделе 2. Здесь мы рассмотрим основные функции, которые составляют бизнес-процесс

закупки.

Функциональная модель начинается с построения общего описания процесса −

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

рассматривается как один функциональный блок со всеми связанными обрабатываемыми

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

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

Цель моделирования определим как описание процесса управления закупками,

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

систему управления организации. В качестве «точки зрения» выберем позицию

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

физических взаимосвязей процесса управления закупками и основных бизнес-процессов.

Контекстная диаграмма процесса закупки приведена на рисунке 6.

тематический план

прайс-лист

информация о поставщике

УПРАВЛЕНИЕ

ЗАКУПКАМИ

информация о состоянии

заказа

информация о ходе

исполнения договора

нормативные

документы

внутрений регламент

работы

отдел закупки

Договор поставки

Заказ товара пост авщику

заявки подразделений

План закупок

Рисунок 6. Контекстная диаграмма бизнес-процесса закупки товара.

Затем контекстная диаграмма детализируется на другой диаграмме с помощью

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

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

набор подфункций, каждая из которых показана как блок.

Декомпозиция процесса «Управление закупками» может быть представлена

следующими задачами:

планирование закупки −оценка потребностей покупателей, работа с планами

выпуска издательств, формирование предварительных заказов на новые печатные

издания;

работа с поставщиком − сбор информации о потенциальных поставщиках

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

договоров на поставку товара, отслеживание баланса закупка – оплата поставщика

и т.д.;

формирование заказа −формирование заказа на поставку товара на склад

книготоргового предприятия;

Для построения и анализа моделей деятельности организации (предметной

области), используются специальные программные средства − CASE-средства. Они

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

документации необходимого качества.

На рисунке 7 изображена декомпозиция бизнес-процесса «Управление закупками»,

построенная с использованием одного из таких CASE – средств − BPwin (разработчик

PLATINUM technology).

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

«Планирование закупки» изображена на рисунке 8.

Декомпозиция каждой функции может осуществляться до тех пор, пока на

диаграмме не будут отображены элементарные операции. Число уровней декомпозиции

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

бизнес-процессов используется 2-3 уровня декомпозиции. Последующие уровни

декомпозиции требуются для построения алгоритмов обработки информационных

потоков при проектировании и разработке информационных систем, а также для

разработки инструкций для исполнителей бизнес-процессов.