Программные продукты и системы

Любой компании, занимающейся разработкой и верификацией программного обеспечения (ПО), необходимо хранить и обрабатывать большое количество информации в электронном виде. Чем сложнее проекты и чем выше их критичность, тем выше требования к процессу управления данными. Более того, для обеспечения гарантии качества выходного продукта необходимо установить, а затем поддерживать определенные процессы, регламентируемые как внутренними, так и отраслевыми стандартами. Это особенно важно для таких областей, как встроенное ПО, где цена ошибки может быть очень велика или даже сопряжена с угрозой жизни людей.

Для структурирования, управления и анализа электронной информации используют различные виды систем документооборота, которые оперируют термином «документ». (Под документом следует понимать некий набор структурированной информации, в общем случае – произвольный объект. Такой объект обладает набором свойств, набором ролей, которые могут работать с документом, и жизненным циклом, описывающим все стадии и процессы работы с этим объектом.) В компании, связанной с разработкой и тестированием ПО, рано или поздно возникает необходимость внедрения системы документооборота. Такую систему можно специально разработать для конкретной компании или использовать уже готовую, предварительно внеся в нее все необходимые настройки. В любом случае система поддержи документооборота – это система для предприятия, поэтому все требования к ее функционированию заложены в его бизнес-процессах. А значит, первичная задача – выявление и описание всех документов будущей системы в соответствии с основными процессами компании.

Наиболее частая проблема автоматизации – неверное понимание потребностей предприятия разработчиками и, следовательно, предоставление неадекватной системы. Поэтому очень важно точно определить первичные требования и поддерживать тесное взаимодействие разработчиков с заказчиками и специалистами в области бизнес-процессов компании на протяжении всего жизненного цикла (ЖЦ) системы.

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

Но начинать автоматизацию с документов и построения программной модели в качестве первичной непросто. Крупное предприятие с большим количеством разных бизнес-процессов и, возможно, с множеством филиалов, субподрядчиков и поставщиков удобно описывать, отталкиваясь от его бизнес-процессов, путем постепенной декомпозиции. Такой подход будет удобен и понятен для специалистов в области постановки и оптимизации бизнес-процессов, а именно, они должны определить первичные требования к системе документооборота. Наиболее простой и удобной методологией описания процессов являются SADT и языки IDEF0 и IDEF3 [2]. При помощи этой методологии можно описать функционирование больших организаций и декомпозировать все процессы до понятных и простых функций.

Предлагаемый авторами подход заключается в объединении двух методов проектирования: объектного UML и процессного IDEF. Описание структур документов и их динамического поведения строится на основе моделей бизнес-процессов предприятия. Каждый документ в данном случае представляет собой набор данных, задающих его структуру (атрибуты, заполняемые информацией) и модель ЖЦ, определяющего правила работы с документом, изменения его состояния и правила разграничения доступа. Каждый документ в системе представляет собой активный объект, отражающий бизнес-процессы предприятия в собственном ЖЦ. Система поддержки документооборота не содержит никаких схем процессов, она лишь интерпретирует описания документов, которые непосредственно функционируют в ее среде.

Сначала c использованием структурного подхода и нотации IDFE0 строится статическое функциональное описание процессов предприятия. Такое описание может уже существовать на момент проектирования системы документооборота, так как некоторые стандарты, например ISO 9001:2000 [3], прямо ориентированы на его наличие в том или ином виде. При его отсутствии можно базироваться на типовых схемах бизнес-процессов компаний-разработчиков ПО. Далее эта модель дополняется динамической частью с помощью языка IDEF3. Затем по этим описаниям строится объектная модель функционирования документов, базирующаяся на изменении их состояний. Рассматриваемый метод построения системы включает в себя следующие аспекты:

·     выделение основных типов документов (объектов);

·     определение ЖЦ для выделенных типов документов и упрощение этих ЖЦ;

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

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

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

Итак, любой процесс IDEF0 модели можно представить как преобразование входных данных в выходные при помощи механизмов и заданных правил. То есть процесс Р можно рассматривать как совокупность (обозначаемую как «|») четырех подпроцессов:  (или ), каждый из которых либо получает («»), либо передает («») данные (обобщенно обозначим входы и выходы процесса как «»).

Объединим предметы (обозначив их как var1, var2, …) по следующим правилам (процессы обозначим буквами P, Q, R, T).

Объединение по словарю (символ  обозначает тождественность предметов, позволяющую объединить их):

,

то есть следует объединять предметы, если они относятся к одной терминологической сущности (например: «отметка об утверждении теста после инспекции» и «код теста» относятся к одной сущности – «тесту»).

Синтаксическое объединение:

или

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

Объединение по операции: слияние дуг, которые участвуют в одинаковых операциях. Введем понятие главного предмета операции (Р!):

.

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

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

Пусть Pj! = var1, j=1..n, тогда

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

Теперь необходимо построить ЖЦ для всех типов документов по IDEF0 диаграммам. Динамические условия и описание того, как функционируют процессы, выполняется в виде IDFE3 моделей.

Применяя аналогичные методы и объединяя механизмы IDEF0 модели, упрощенной путем замены предметов на объекты, в которые они уже объединены, можно получить предварительный набор ролей по отношению к документам [4]. Для любой роли по отношению к документу определяется ее действие, которое влияет на рассматриваемый документ. Авторами предлагается следующая классификация этих действий:

(А) – выполнение некоего этапа работы;

(Б) – принятие принципиально важного решения с фиксацией этого факта;

(В) – внесение информации (в суть или свойства документа).

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

·     (А) и (Б) не могут начинаться из начального состояния (сначала надо внести какую-либо информацию);

·     (А) не может приводить к конечному состоянию (любая работа должна быть проверена, и этот важный факт должен быть отмечен);

·     более строго: после (А) обязательно должно следовать действие (Б); возможно, через дейст- вие (В);

·     обратной связью в ЖЦ может служить лишь действие (Б).

Следующий шаг – упрощение ЖЦ, основанное на объединении состояний или разделении документа на два или более. Для решения вопроса о том, каким из этих методов целесообразно производить упрощение ЖЦ, авторами предлагается два критерия.

Критерий линейности этапов ЖЦ оценивает вероятность перехода из некоторого состояния Sj в новые (рис. 1). Если переход в некоторое новое состояние Sk существенно более вероятен, чем в другие состояния (Sk+1), этот участок является линейным и на нем рекомендуется разделить документ на два отдельных.

Критерий числа изменений при возврате (рис. 2) заключается в рассмотрении обратных связей между состояниями, и если их количество велико, следует попробовать объединить состояния, в которые происходят возвраты, в одно.

Критерий связанности этапов ЖЦ рассматривает возможность разделения орграфа состояний и переходов на подграфы с минимальным количеством связей между ними. Если количество связей между двумя подграфами мало по сравнению со средней степенью вершин подгафов, эти подграфы можно выделить в разные ЖЦ (то есть разделить документ на несколько).

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

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

Более того, люди, занимающиеся автоматизацией, могут делиться на несколько независимых групп, имеющих разные знания и навыки. Одна группа решает, что должно делать предприятие, и им совсем необязательно быть специалистами в области разработки систем документооборота. Языки IDEF достаточно просты и одновременно выразительны для описания процессов предприятия. Вторая группа – это специалисты, понимающие, как наилучшим образом сделать то, что решила первая группа. Они уже в большей степени являются специалистами по проектированию и оптимизации документооборота и работают с объектной моделью. С другой стороны, им не надо быть специалистами по бизнес-процессам. На последнем этапе подключаются к работе люди из группы реализации. На этом этапе можно не только реализовать систему документооборота с нуля, но и настроить какую-либо существующую, так как все настройки и документы уже известны и описаны. В третьей группе могут быть просто специалисты по внедрению какой-то готовой (но гибко настраиваемой) системы. Благодаря предлагаемому методу постепенного перехода от процессов к документам и их схемам работы, концепция «что должно делать предприятие» в итоге перейдет в конкретные настройки, а на каж- дом этапе будут работать специалисты в своей области.

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

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

Авторами было разработано и реализовано программное средство, упрощающее применение описанных методов и позволяющее частично их автоматизировать. Сами методы были успешно применены при проектировании системы документооборота для одной из компаний, специализирующихся на разработке и верификации встроенного ПО. На основе примерно 40 процессов и порядка тысячи предметов были выделены основные типы документов и построены их ЖЦ. Эксплуатация электронной системы документооборота, в основу которой были положены выделенные типы документов, показала применимость описываемых методов и алгоритмов. Кроме того, внедрение системы документооборота позволило успешно пройти сертификацию по стандартам ISO 9001:2000 и AS 9100A.

Список литературы

1.   Фаулер М., Скотт К. UML основы. Краткое руководство по унифицированному языку моделирования. – М.: Символ-Плюс, 2002. – 192 с.

2.   Марка Д.А., МакГоуэн К. Методология структурного системного анализа и проектирования SADT. – М.: Метатехнология, 1993. – 240 с.

3.   ISO 9001:2000 Quality Management System – Requirements, ISO, 2000. – 33 p.

4.   Синицын С.В., Хлытчиев О.И. Переход от процессного к объектному описанию системы документооборота предприятия. / В сб.: Современные технологии в задачах управления автоматики и обработки информации: Тр. XVI Междунар. науч.-технич. сем. – Тула.: Изд-во ТулГУ. – 2007. – С. 80–81.