Онтологический анализ дефектов при проектировании компонентов аппаратно-программных комплексов

В литературе, посвященной управлению сложными системами [1, 2] отмечается необходимость исследования не только «полезных» (useful), но и «вредных» (harmful) функций системы. В работе [3] подчёркивается необходимость смещения акцентов в проблематике создания аппаратно-программных комплексов (АПК) от вопросов штатной эксплуатации к вопросам их безопасного функционирования. Там же отмечается необходимость совершенствования технологий разработки, позволяющих обеспечивать защиту изделий как от злонамеренных действий, так и от непреднамеренных ошибок, допускаемых разработчиками на разных стадиях жизненного цикла АПК. В работах [3-5] отмечается, что одним из перспективных современных направлений исследований в области системной инженерии является создание методологических и теоретических основ дефектологии АПК. При этом следует выделять классы задач, связанные с обеспечением технологической и эксплуатационной безопасности АПК. Предлагаемая классификация является условной и основана на задачах, выделенных при анализе литературных источников [3, 5]:

• ■    задачи, решаемые в рамках комплексной проблемы защиты информации [3], в том числе задачи, связанные с обеспечением конфиденциальности, целостности и доступности информации для случая, когда в решении задач активное участие принимает пользователь [5];

• ■    задачи, связанные с построением АПК для управления и обработки информации в реальном времени при относительно малом участии пользователей (задачи функциональной безопасности) [5]. Под функциональной безопасностью АПК понимается свойство АПК сохранять работоспособность в соответствии со своим назначением при случайных дестабилизирующих воздействиях и отсутствии злоумышленного влияния на программную, аппаратную составляющую или базы данных).

В данной работе авторами под дефектом понимается предпосылка к ошибке, возникновение (реализация) которой влечет за собой значимые потери для пользователя АПК. Следует обратить внимание на то, что к настоящему времени не сформировано единой и устойчивой терминологии в области дефектологии; например, в работах [5-7] описана проблематика классификации дефектов и затрагиваются вопросы выработки понятий по данному разделу.

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

По нашему мнению, в литературе [8, 9], посвящённой проектированию, обеспечению эксплуатации и развитию систем обработки и обмена информацией, в основном, внимание акцентируется на полезных функциях. В то же время, понятие «дефект» необходимо увязывать с понятием «вредная функция». Изучению вредных функций не уделялось должного внимания в исследованиях, связанных с управлением качеством систем информационной поддержки управления. К настоящему времени получила развитие методологическая, модельная и инструментальная основа управления надёжностью изделий электронной техники, но аналогичное заключение нельзя сделать относительно надёжности программной составляющей АПК, хотя известны публикации [10] по тематике инженерии надёжности программных систем (Software Reliability Engineering).

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

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

Многомерность понятия «дефект» в проекте диктует его исследование, по крайней мере, в следующих проекциях.

• ■    Социальная. Необходимость исследования этой проекции обусловлена тем, что дефекты в АПК способствуют реализации вредных функций системой, в которую они встроены. Это, в свою очередь, может представлять угрозу для внешних и внутренних правообладателей системы [14]. Иными словами, понятие «дефект» напрямую связано с понятиями «угроза» и «риск» [5] (угроза обусловлена воздействием внешней среды на проект, риск ассоциирован с внутренней средой объекта управления).

• ■    Технологическая . Необходимость этой проекции обусловлена тем, что причинами дефектов являются:

• ■    ограниченные возможности изучения потребностей, ожиданий и желаний правообладателей [13] (внешних и внутренних [14]). Это обусловлено слабой формализацией известных технологий извлечения реальных потребностей пользователей;

• ■    ограниченность методов, моделей и инструментов планирования и управления проектами в условиях высокой изменчивости как внешней, так и внутренней сред проектов, связанных с созданием, модернизацией и развитием АПК [11, 15-17]. Центральной составляющей внешней среды являются потребности, желания, ожидания правообладателей, а также ограничения, накладываемые на способы реализации программных проектов в виде бюджета и сроков реализации проекта. Внутренняя среда представляет собой совокупность основных, вспомогательных и обеспечивающих процессов [18], результатом реализации которых является АПК;

• ■    отсутствие «бесшовных» технологий реализации как отдельного проекта [19], так и при построении интегрированных информационно-коммуникационных систем на базе локальных АПК [20].

• ■    индивидуальные пристрастия разработчиков в выборе инструментария реализации проектов (в литературе этому соответствует понятие «инструментальный ящик проектов» [19]). Интеграция компонентов, реализованных разным набором инструментов, также является причиной возникновения дефектов.

• ■    Управленческая . Организационная структура, методология, методическое и другие виды обеспечения зависят от масштаба и сложности проекта. Источниками возникновения дефектов могут служить, например, модель жизненного цикла (при реализации IT-проектов в условиях высокой изменчивости требований организационным дефектом будет выбор «водопадной» модели жизненного цикла; альтернативой широко применяемой «водопадной» модели в таких условиях являются подходы, соответствующие Agile process [15]), либо неадекватный набор нормативных документов, положенных в основу реализации проекта [8]. Следует особо подчеркнуть роль субъективной составляющей в реализации IT-проектов как источника дефектов. Многогранность субъективной составляющей подтверждается также статистическими данными, показывающими доминирующую роль субъективной составляющей IT-проектов на исход проекта [11, 15].

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

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

1    Классификация дефектов

Многомерность и динамическая природа объекта исследования « дефект программного компонента АПК » диктует множественность подходов к классификации дефектов.

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

В первую очередь следует разграничить дефекты в продуктах и дефекты в проектах. Дефекты продуктов являются производными дефектов проектов. Коренной причиной дефектов обоих классов является неопределённость как в требованиях к потребительским свойствам продукта, так и в способах обеспечения этих требований [21].

Заметим, что в [22] считается, что на вход программного проекта поступают требования пользователей (функциональные, иначе называемые «требования-возможности», описывающие, решение каких классов задач должен обеспечивать продукт; нефункциональные, иначе «требования-ограничения», определяющие такие характеристики, как надёжность, быстродействие и др.)1. Это подчёркивает сложность формирования спецификации требований пользователей, а также иллюстрирует стремление разработчиков методологий реализации IT-проектов дистанцироваться от возможной неудачной реализации проекта.

Если в основу классификации продуктов положить показатель сложности (для программного модуля и приложения, построенного по модульному принципу, определён формальный показатель в виде цикломатического показателя сложности [17]), то можно выделить следующие классы объектов:

• ■    программный   модуль/компонента   АПК,   предназначенный для реализации

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

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

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

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

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

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

Различное содержание понятия «дефект» в зависимости от уровня сложности объекта связано с использованием терминов: «bugs», «defect», «fault». Первый термин применим на уровне модуля (точка зрения разработчика); второй – на уровне локальной программной системы (точка зрения разработчика); третий – на уровне подсистемы /системы (точка зрения пользователя).

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

• ■    на уровне модуля - прогнозирование количества дефектов на основе показателя сложности [25];

• ■    на уровне локальной программной системы - модели надёжности [10, 26, 27];

• ■    модели для оценки надёжности функционально-сложных систем со сложными стратегиями ремонта и технического обслуживания – марковский анализ [28].

Следует подчеркнуть, что приведённая классификация, как и всякая классификация, является условной. Это обусловливает изменение содержания понятий «операция», «функция», «компонента», «система» по мере развития интеллектуальности средств сбора, обработки, хранения и представления информации, и, следовательно, изменяет содержание понятий «дефект», «ошибка», « отказ».

Классификация программных проектов по показателю сложности возможна по аналогии с СММI [29]:

• ■    проекты, реализация которых возможна без использования систематических процедур, по интуиции (ad hoc);

• ■    проекты, основанные на структуризации процессов;

• ■    проекты, основанные на использовании полезных практик, закреплённых в нормативных документах, руководствах и рекомендациях;

• ■    проекты, основанные на использовании взаимосвязанной совокупности нормативных документов, моделей и инструментов («инструментального ящика проекта» [19]);

• ■    проекты, основанные на комплексном формальном анализе альтернативных вариантов построения как структур взаимосвязанных процессов, так и способов реализации отдельных этапов этих процессов [19, 30].

Поэтапная реализация АПК позволяет рассматривать проекты и продукты как системы с конечным числом элементов или состояний системы [31].

Изложим содержание известной модели [31] системы Σ с конечным числом состояний:

• (1)                         Σ= ( U , Y , Q , λ , γ ) ,

в терминах программного проекта и продукта.

Для продукта составляющие модели получают следующее содержание:

U – множество требований пользователей (внешний облик АПК/ограничения АПК);

Y – множество потребительских свойств АПК;

Q – множество состояний продукта (модель жизненного цикла продукта);

λ – множество функций перехода между стадиями жизненного цикла:

• (2)                          λ i : Q i × U i → Q i+ 1 , i = 1, n - 1 ,

здесь i – номер стадии;

γ – множество функций выхода (результатов i –й стадии, поступающих на вход ( i +1)-й стадии):

• (3)                         γ i : Q i × U i → Y i .

Для проекта содержание модели получает следующее толкование:

U – множество требований к проекту (сроки; стоимость; ограничения на условия реализации);

Y – множество характеристик качества проекта (социальных; политических; финансовых; технологических; научных; образовательных);

Q – множество компонентов основного (реализации проекта), вспомогательного (инструменты), обеспечивающего (управление) процессов;

λ – множество работ, реализуемых на j -й стадии проекта:

^i ^: Q j ^x U j ^ Q j+ 1 , ^j - 1, n ^- 1 ,

Y - множество промежуточных продуктов, получаемых на стадиях проекта (критериев перехода от j -й стадии к (j' +1)-й стадии):

• ( 5) Y J : Q j * U j ^Y j+ 1 .

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

Основу классификации мест возникновения дефектов в продукте может составить структура типового процесса разработки и использования АПК (рисунок 1). Предлагаемая модель построена по аналогии с известной V-моделью жизненного цикла программного продукта [32].

Рисунок 1 - Места возникновения дефектов при создании и использовании АПК

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

Основу классификации мест возникновения дефектов в программном проекте также могут составить ключевые направления совершенствования IT-проектов, определённые в работах [15, 16].

Предлагаемые подходы к классификации дефектов в компонентах АПК и проектах реализации их компонент не могут считаться исчерпывающими. Приведённые примеры лишь иллюстрируют множественность подходов к изучению дефектов.

Классификацию моделей дефектов можно увязать с классификацией их типов, например: ■ конструктивные;

• ■    технологические;

• ■    временные.

Примером математической модели дефектов в классе моделей конструктивных дефектов является установление формальных соотношений между показателем сложности продукта и ожидаемым числом дефектов [25].

Примером структурной модели, отражающей технологические аспекты предупреждения и ранней идентификации дефектов, является V-модель жизненного цикла программного продукта [32].

Примером модели, ориентированной на сокращении времени разработки программной компоненты АПК с требуемыми потребительскими свойствами в условиях высокой изменчивости требований пользователей, является Agile Process [15].

В качестве примера классификации моделей дефектов в проектах можно привести следующее:

• ■    моделирование последствий дефектов во внешней и внутренней средах проекта;

• ■    моделирование дефектов в организации проектов;

• ■    моделирование последствий дефектов в планах проектов.

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

2 Холистический подход к анализу дефектов

Одним из фундаментальных подходов к исследованию сложных систем является рассмотрение её как взаимодействующей совокупности целостностей [31, 33]. Анализ критических факторов успеха и неудач, связанных с реализацией IT-проектов [15, 16], позволяет сделать однозначный вывод о решающей роли субъективной составляющей на результаты проекта. Рассуждая о дефектах, следует подчеркнуть, что различные правообладатели по-разному относятся к одним и тем же свойствам АПК, входящим в состав сложных систем, в том числе к наличию и проявлению разных дефектов. Это обусловлено различием точек зрения, в рамках которых каждый правообладатель относится к ценностям, создаваемым АПК [9, 24].

Известно, что каждую систему следует рассматривать с позиции внешнего поведения и внутреннего устройства. Внешнее поведение – это основа оценивания системы потребителем. Внутреннее устройство – это основа оценивания системы и её компонентов разработчиками. Различие точек зрения на систему приводит к заключению о различном отношении к одним и тем же дефектам разных правообладателей. Рассмотрение дефекта как неотъемлемого свойства сложных систем, с одной стороны, различное видение разными правообладателями одной и той же системы, с другой стороны, определяющая роль субъекта в разработке компонентов системы и оценивании их потребительских свойств, с третьей, позволяют сделать заключение о множественности холонических моделей дефектов. На рисунках 2-4 в качестве примера приведены холонические модели дефектов, соответствующие рассмотрению компонентов АПК внешними и внутренними правообладателями.

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

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

Рисунок 2 – Холоническая модель дефекта с точки зрения создания и обеспечения функционирования и развития АПК

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

Рисунок 3 – Холоническая модель дефекта с точки зрения пользователя АПК

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

Несоответствие потребительских свойств информационных продуктов, сервисов АПК и средств доступа к ним реальным потребностям

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

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

Рисунок 4 – Холоническая модель дефекта с точки зрения руководителя проекта

Дефекты в извлечении функциональных и нефункциональных требований к АПК

Следует отметить, что содержание компонентов представленных холонов (и, следовательно, содержание ассоциированных с ними дефектов) зависит от уровня рассмотрения АПК: программного модуля/технического устройства, локальной автоматизированной системы; компоненты функциональной подсистемы корпоративной информационной системы; функциональной подсистемы корпоративной информационной системы; корпоративной информационной    системы;    территориально распределённой информационно коммуникационной системы.

Заключение

Рассмотрены подходы к классификации дефектов в компонентах АПК и проектах реализации их компонент. Изложено описание общей модели сложных систем в терминах продуктов (компонентах АПК) и проектах их реализации.

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

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