Краткая характеристика сферы внедрения информационной системы

Основные понятия процессного подхода

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

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

Сегодня исследование процессов организации невозможно представить себе без технологической поддержки, оказываемой CASE-средствами (Computer Aided System Engineering), реализующими различные методологии анализа и описания сложных систем.

Одной из наиболее широко распространенных методологий (и одновременно нотаций) является ARIS (ARchitecture of Integrated Information Systems).

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

Наиболее часто используемые типы моделей описаны ниже.

Диаграмма цепочки добавленного качества

Диаграммы цепочки добавленного качества (Value-Added Chain Diagram, VAD-диаграмма ) используются для верхнеуровневого описания групп бизнес-процессов компании, непосредственно влияющих на выход готовой продукции.

Перечень основных объектов модели представлен в таблице 1.2.

Таблица 1.2. Объекты диаграммы цепочки добавленного качества

№ п/п	Тип объекта	Символ объекта	Описание
1.	Звено цепочки добавленного качества (функция)		Объект соответствует группе бизнес-процессов, создающих добавленную стоимость

Событийная цепочка процесса

Событийные цепочки процессов (Extended Event driven Process Chain Diagram, диаграмма eEPC) применяются для детального описания бизнес-процессов компании, упомянутых на VAD-диаграммах. Диаграммы содержат последовательность шагов и результатов их выполнения. Как правило, для каждого шага указываются исполнитель, входящие и исходящие документы (носители информации) и используемые информационные системы.

Перечень основных объектов модели представлен в таблице 1.3.

Таблица 1.3. Объекты событийной цепочки процесса

№ п/п	Тип объекта	Символ объекта	Описание
1.	Интерфейс процесса		Событие, инициирующее выполнение бизнес-процесса
2.	Событие		События являются результатом выполнения функций, а также инициируют передачу выполнения процесса от одной функции к другой. Отличительная черта события - его мгновенность, событие не имеет продолжительности. Для каждой функции должны быть определены входящее и исходящее события
3.	Функция		Действие в рамках одного бизнес-процесса компании

Организационная схема

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

Перечень основных объектов модели представлен в таблице 1.4.

Таблица 1.4. Объекты организационной схемы

№ п/п	Тип объекта	Символ объекта	Описание
1.	Организационная единица		Департамент, управление, отдел и т. д.
2.	Должность		Штатная должность
3.	Штатный сотрудник		Человек, занимающий должность

Диаграмма носителей информации

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

Перечень основных объектов модели представлен в таблице 1.5.

Таблица 1.5. Объекты диаграммы носителей информации

№ п/п	Тип объекта	Символ объекта	Описание
1.	Картотека		Объект соответствует группе документов
2.	Документ		Объект соответствует любому документу на произвольном носителе

Диаграмма типа информационной системы

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

Перечень основных объектов модели представлен в таблице 1.6.

Таблица 1.6. Объекты диаграммы типа информационной системы

№ п/п	Тип объекта	Символ объекта	Описание
1.	Тип прикладной системы		Совокупность систем, имеющих общее назначение и похожие технические характеристики
3.	Тип модуля		Совокупность модулей системы, объединенных общим назначением
4.	Экран		Окно программы

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

Основные понятия управления требованиями

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

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

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

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

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

К сожалению, не существует и единого определения требований. Так, например, согласно стандарту IEEE Standard Glossary of Software Engineering Terminology под требованиями понимаются:

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

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

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

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

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

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

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

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

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

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

Номер требования будет формироваться по следующим правилам:

RXXYY, где:

• R - текстовая константа, обозначающая требование к системе;
• XX - группа бизнес-процессов ( PU - закупки, SA - сбыт, LO - склад);
• YY - уникальный номер требования в группе.