Средства коммуникации в вопросно-ответной среде автоматизированного проектирования Текст научной статьи по специальности «Компьютерные и информационные науки»

КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ

СИСТЕМЫ

УДК 621. 372

СРЕДСТВА КОММУНИКАЦИИ В ВОПРОСНО-ОТВЕТНОЙ СРЕДЕ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ

© 2007 г.

Исходные предпосылки

Около 10 лет назад в знаменитом отчёте корпорации Standish Group [1] была опубликована неутешительная статистика, характеризующая проблемы разработок автоматизированных систем (АС), интенсивно использующих программное обеспечение. Сложившаяся ситуация квалифицировалась как «хаос». Среди основных причин неудач были названы «недостаточное взаимодействие разработчиков с другими заинтересованными лицами, в первую очередь с пользователями» и «проблемы с полнотой и адекватностью требований к разрабатываемой системе, обычно изменяющихся по ходу разработки».

За последнее время положение в программной инженерии изменилось, но незначительно. Так, например, в оценках 2005 г., приведённых в [2], список причин неудач практически совпадает со списком причин, указанных в отчете Standish Group. Дополнительно отметим, что к числу причин неудач часто относят «недостаточную степень понимания и взаимопонимания» и «плохое коммуникативное взаимодействие» в круге лиц, вовлечённых в разработку АС.

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

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

В.А. Маклаев

потока работ «Взаимодействие с опытом», согласованного с потоками работ технологии Rational Unified Process [4].

Поток работ «Взаимодействие с опытом» реализуется как приложение, разработанное в корпоративной среде вопросно-ответного процессора NetWIQA [5]. Предлагается развить это приложение, включив в него средства вопросно-ответной коммуникации.

Вопросно-ответное моделирование

В основу потока работ «Взаимодействие с опытом» положено вопросно-ответное моделирование (QA-моделирование) рассуждений лиц, вовлечённых в процессы решения проектных задач.

В ходе QA-моделирования с позиций рассуждений R(Z), используемых в решении каждой задачи Z, создаётся и исследуется её вопросно-ответная модель (QA-модель), в рамках которой выделяются, представляются и связываются вопросные {Qi} и ответные {Ai} составляющие R(Z). Задача понимается и представляется как тип вопроса, что позволяет в рамках Z выделять подзадачи Zk и их QA-модели QA(Zk).

Каждая конкретная QA-модель представляет собой систему

QA(Z(t)) = S({XI(Ti, Sblj, Sb2k, t, Gn)}), интерактивных динамических объектов XI(Ti, Sblj, Sb2k, t, Gn), каждый из которых материализует в базе проекта либо вопрос (X = Q), либо ответ (X = A), либо задачу (X = Z). Каждый такой объект определён с использованием следующей атрибутики: уникальное индексное имя XI, приписываемое автоматически; Tj— описание «объекта»; Sblj— идентификатор субъекта, ответственного за «объект»; Sb2k— указатель на субъекта (в общем случае составного субъекта), заинтересованного в «объекте»; t— момент времени, в который зафиксировано текущее состояние «объекта»; Gln— другие атрибуты «объекта» XI, представляющие его в базе проекта.

Сущность бА-моделирования определяется интерактивным взаимодействием лиц, которым разрешён доступ к модели

(0А(ЖО) = S({XI(Obi, SЫj, Sb2k, г, вп)}), позволяющим:

1. Обогащать модель бА(2(г)) дополнительным содержанием благодаря включению в её состав очередных единиц типа XI(Obi, Sb1j, Sb2к, г, в1 п), а также путем формирования с её помощью (в том числе используя возможности атрибутики вп) ряда концептуальных моделей задачи 2(г), включая модели на базе языка иМЬ; ряда визуально-интерактивных представлений модели 6А(2(?)); ряда преобразований модели бА(2($).

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

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

Вопросно-ответное моделирование коммуникативных задач

Предлагается включить в состав модели бА( 2(г)) дополнительный «коммуникативный вид», раскрывающий вопросно-ответные процессы как коммуникативное взаимодействие лиц, вовлечённых в работу над задачей 2(г).

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

2*. Для формирования, обоснования, ревизии, оценивания и освоения проектных решений, в том числе для обеспечения достаточных оснований и дос-

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

Задача 2* решена с учётом того, что функции коммуникативного объекта (в общем случае) выполняет проектное решение декларативного или процедурного типа или его часть.

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

В процессе решения задачи 2* разработан комплекс средств, позволяющий обслужить коммуникативное взаимодействие в рамках задач бА-коммуникации: «Почтовая связь в корпоративной среде разработки АС», «Упреждающие решения и обратные действия», «Взаимодействие с личным опытом», персональное и коллективное «Оценивание», «Обоснование» в формах аргументации, «Ревизия», «Мозговой штурм» и обсуждение в формах «Совещание», «Дискуссия» и «Полемика».

Механизмы бА-моделирования задач коммуникации представим на примере задач «Совещание», «Оценивание» и «Ревизия». Задачу «Совещание» ограничим обсуждением одного вопроса.

На обобщённой схеме коммуникации для «Совещания», представленной на рис. 1, показано, что взаимодействие коммуникантов (председателя совещания Sb1 и его участников Sb2) осуществляется в рамках специальной задачи 21 и её модели 6А(2Т), которые материализованы в вопросно-ответной базе проекта. По ходу совещания необходимо обрабатывать совокупность мнений участников совещания так, чтобы они отложились в решении совещания в соответствии с договоренностями и/или голосованием.

Председатель (Sbl) *

Участники (^2)

Рис. 1. Организационно-техническая схема «совещания»

На информационной схеме «совещания» (рис. 2) отражены отношения между «решением» и «мнениями», причём предполагается, что участник совещания может высказать не только одно «мнение» или же не высказать ни одного «мнения».

*

Решение

Мнение Оценки

хОО*

I П-с^—о-

Рис. 2. Информационная схема «совещания»

На информационной схеме совещания результаты голосования представлены в форме оценок, функции которых выполняют относительное число голосов типа «За» за каждое мнение (предложение). При заданной норме оценки на учёт мнения (например, не мене 0,5) мнение включается в решение совещания. Само решение также оценивается на его приемлемость исходя из определённой нормы голосования.

Голосования являются важнейшей коммуникативной процедурой совещания, которая встраивается при каждом употреблении как коммуникативная задача оценивания Z^.1, подчинённая коммуникативной задаче совещания Z^.

Вопросно-ответная схема для бА-модели задачи голосования в контексте бА-модели «Задачи совещания» имеет вид, представленный на рис. 3.

QAI-. <

ZI(Ob, Sbl, Sb2, t, QAI.l ZI.l(Obl,...) QAI.2 ZI.2(Ob2,...)

..... ^ Вклад конкретн ого

QAI.p *

QA(ZI.l): QA.l QA.2

QA.p

Рис. 3. Вопросно-ответные структуры задач

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

«Ревизия» в выбранных формах её использования «инспекции» и «экспертизы» является необходимым и принципиальным действием, в котором есть место вопросно-ответной коммуникации (бА-коммуникации).

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

Задача бА-инспекции включает:

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

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

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

Задача «экспертизы» используется для оценки соответствия решения:

— требованиям к АС или требованиям ближнего контекста;

— ограничениям, которые накладываются на АС или накладываются на проектное решение его контекстом;

— нормам, соблюдаемым в разработке АС, в том числе стандартам различного типа;

— требуемой степени адекватности.

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

Вывод

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

Литература

1. The Standish group, Charting the Seas of Information Technology-Chaos. The Standish Group International, 1994.

2. Charette R. «Why Software Falls» //IEEE Spectrum. 2005. Vol. 42, № 9. P. 36-43.

3. Sosnin P. , Sosnina E. Question-answer system for object-oriented analysis and design// Proceeding of 22nd

International conference Information Technology and Construction. Dresden. 2005. P. 199-204.

4. Kroll P., Kruchten Ph. The Rational Unified Process Made Easy: A Practitioners Guide to the RUP. Addison-Wesley, 2003.

5. Sosnin P. Question-Answer Processor for Cooperative Work in Human-Computer Environment //Proceeding of the 2d International IEEE conference Intelligent System. 2004. P. 452-456.

Таганрогский радиотехнический университет

9 октября 2006 г.

УДК 004.4

НЕЧЕТКИЕ МОДЕЛИ ПРИНЯТИЯ РЕШЕНИИ В ПРОЕКТАХ СОЗДАНИЯ

ИНФОРМАЦИОННЫХ СИСТЕМ

© 2007 г. А.И. Долженко

Проекты внедрения и совершенствования информационных систем (ИС) имеют цель — создание информационных сервисов. При этом под информационным сервисом (сервис ИТ) понимается информационный процесс, который реализуется средствами информационных технологий и параметры которого значимы для протекания бизнес-процесссов в организации [1]. Жизненный цикл проекта внедрения и совершенствования (в дальнейшем изложении — проекта) информационной системы включает следующие стадии: начальная, уточнения, конструирования, развертывания и эксплуатации. Следует отметить, что на начальной стадии и стадии уточнения проекта, с одной стороны, имеется большая неопределенность при принятии решений о будущих сервисах и их реализации, с другой — важность принятия эффективного решения крайне высока, так как ценность проекта для бизнеса закладывается именно на этих стадиях и это во многом определяет возможность достижения цели проекта в целом. Последующие стадии жизненного цикла проекта (конструирование, развертывание и эксплуатация) являются достаточно сложными, но их влияние на ценность проекта гораздо ниже.

Неопределенность порождает риски управления проектом. В проектах ИС риски отражают возможные существенные потери, которые проявляются в ухудшении потребительского качества создаваемой ИС, увеличению затрат времени на проект или в полном срыве проекта [2]. Риски максимальны на начальной стадии проекта и должны снижаться до минимального уровня на фазе эксплуатации.

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

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

В проектах ИС обслуживание бизнес-процессов предметной области реализуется сервисами ИТ, которые представляют собой различные модули промышленно поставляемых ИС. Это характерно для проектов внедрения ИС на базе таких ERP-систем как SAP/R3, Oracle Aplication, Baan, MS Axapta, MS Navision, БОСС-Корпорация, Галактика, Парус, БЭСТ-ПРО, 1С «Предприятие 8.0» и др. Процесс выбора сервисов ИТ на основе существующих приложений ERP-систем для бизнес-процессов предприятия характеризуется значительной неопределенностью. Приложения могут быть недостаточно подробно документированы, что затрудняет их выбор; могут иметь избыточную функциональность для реализации конкретного сервиса ИТ, а это предполагает повышение объема инвестиций в проект; могут иметь недостаточную функциональность для сервиса ИТ, в связи с чем необходимы дополнительные затраты на доработку; могут иметь сложную процедуру конфигурирования и настройки приложений, что требует значительных финансовых затрат на консалтинг и обучение как конечных пользователей, так и обслуживающего ИС персонала.

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