Кибернетика и программирование
Правильная ссылка на статью:
Соснин П.И., Куликова А.А., Наместников А.М. — Контролируемое формирование понятий с нечётким значением в архитектурном моделировании систем с программным обеспечением // Кибернетика и программирование. - 2019. - № 3. Ш1: 10.25136/2644-5522.2019.3.28245 URL: htфs://nbpublishxomlbrary_read_artide.php?id=28245
Контролируемое формирование понятий с нечётким значением в архитектурном моделировании систем с программным обеспечением
Соснин Пётр 1/Ъанович
доктор технических наук
профессор, кафедра «Вычислительная техника», Ульяновский государственный технический
университет
И sosnin@ulstu.ru
Куликова Анна Александровна
аспирант, кафедра «Вычислительная техника», Ульяновский государственный технический университет 432027, Россия, Ульяновская область, г. Ульяновск, уп. Северный Венец, 32
И a.push1206@gmail.com
Наместников Алексей Михайлович
доктор технических наук
доцент, кафедра «Информационные системы», Ульяновский государственный технический университет 432027, Россия, Ульяновская область, г. Ульяновск, уп. Северный Венец, 32
El nam@ulstu.ru
Статья из рубрики "Автоматизация проектирования и технологической подготовки производства" Аннотация.
Предметом исследования является онтологическое моделирования концептов (понятий), имеющих нечёткое значение, неконтролируемое использование которых обычно приводит к проблемам с успешностью разработок систем, интенсивно использующих программное обеспечение (Software Intensive Systems, SIS). Объектом исследования является овеществление характеристик качества SIS, которые относятся к типичным концептам такого типа. Особое внимание уделяется требованиям тех лиц проектного окружения (стейкхолдеров), разнородные интересы которых обычно вносят неопределённость в требования к разрабатываемой SIS, но должны быть учтены в проекте в обязательном порядке. В работе предлагается согласованное применение методов архитектурного моделирования и нечёткой логики для оценок характеристик качества, которые должны быть вычислимы и контролироваться по ходу проектирования. Новизну исследования определяет включение в структуру и содержание концептов с нечётким значением новых составляющих, регистрирующих динамику их становления по
ходу проектирования определённой SIS так, что для каждого из таких концептов текущее значение его содержания позволяет контролировать достигнутое значение степени (уровня) профессиональной зрелости овеществления концепта. Новыми составляющими являются расширение атрибутики концепта и оперативная вычислительная связь атрибутики с нормативными потоками работ, группы которых согласованы с уровнями профессиональной зрелости овеществления концептов в про е кте .
Дата направления в редакцию:
Дата рецензирования:
Исследование выполнено в рамках грантов Российского фонда фундаментальных исследований (РФФИ) №18-07-00989а, №18-47-730016 р_а, №18-47-732012 р_мк, а также государственного задания №2.1534.2017/4.6.
Введение
В последние годы были предпринят ряд попыток переосмыслить базовые концепции программной инженерии, включая вопросы разработки систем, интенсивно использующих программное обеспечение (SIS), важнейшим подклассом которых являются автоматизированные системы (АС). Основной причиной инновационного переосмысления была и является проблема чрезвычайно низкой степени успешности -Ш-в создании современных SIS, в решении которой конструктивный учёт человеческого фактора занимает принципиальное место. Среди перспективных попыток переосмысливания концепций следует особо отметить инициативу SEMAT (Software Methods and Theory) ^ и внедрение в практику проектирования SIS методологии
проектного мышления (Design Thinking, DT)-3^. Обе эти попытки затрагивают особенности концептуальной активности проектировщиков в реальном процессе проектирования. Для подхода SEMAT это активное использование гибкого мышления, в то время как DT-подход фокусирует внимание проектировщиков на осознании задачных ситуаций, формулировке постановок задач, идей их решения и концептуальном прототипировании. Но практически все попытки исходят из того, что негативные проявления человеческого фактора обусловлены проблемами с пониманием задач, ситуаций и событий в процессах индивидуальной или совместной работы над проектом в
условиях непривычной и высокой сложности взаимодействия разработчиков SIS с их проектами.
Одним из принципиальных направлений овладения сложностью и снижения негативных проявлений человеческого фактора, обусловленных проблемами с пониманием,
считается архитектурное моделирование SIS^4!, в осуществлении которого центральное место занимает снижение сложности взаимодействия с SIS в точках её жизненного цикла за счёт использования совокупности согласованных «точек зрения» (viewpoints) на проект и соответствующих им видов (views), в каждом их которых конструктивно регистрируется необходимое понимание.
Отметим, что вложение конструктивного понимания в архитектурные модели следует овеществлять так, чтобы оно соответствовало его природе. Понимание - это естественно-искусственный феномен, который, в первую очередь, отвечает за правильное использование языковых средств в деятельности человека. В случаях, когда это необходимо, естественная сторона понимания проявляется через управляемую координацию результатов восприятия (или воображения) и построения соответствующих им описаний. Искусственная сторона проявляется в использовании средств, которые помогают моделировать внутренние процессы и результаты понимания за пределами мозга для объединения моделируемого понимания с внутренними процессами с целью повышения их эффективности. Процесс понимания и его результат зависят от человека, который взаимодействует с некоторыми ситуациями, применяет средства моделирования и подходящий способ комбинирования внутренних и внешних процессов, направленных на достижение необходимого (и достаточного) понимания.
Проектирование любой SIS является источником разнообразных ситуаций, в каждой из которых необходимо конструктивно обеспечить достижение достаточного понимания. Понимание должно быть реализовано в рамках языка проекта LP(t), создаваемого в процессе проектирования. Более того, акты понимания осуществляются проектировщиками в текущем состоянии LP(t), тем самым подтверждая, что это состояние является адекватным для разрабатываемого проекта. Результаты понимания лучше регистрировать в формах, которые могут быть использованы повторно, поскольку они позволяют согласовать понимание всех заинтересованных сторон, участвующих в прое кте .
Среди важнейших форм регистрации согласованного понимания необходимо отметить архитектурное описание проектируемой системы. Такое описание состоит из комплекса архитектурных видов, каждый из которых связывает определенную блок-схему с ее описанием на языке проекта LP(t). Качество интегрированных архитектурных решений существенным образом зависит от ядра LP(t), которое целесообразно строить в форме онтологии проекта OP(t), включающей в себя понятия (концепты), без которых обеспечение понимания и повторное использование его зарегистрированных следов невозможно.
Принципиальной особенностью любой онтологии OP(t) является то, что её компоненты должны найти свою объективацию в соответствующем проекте. Это требование распространяется на концепты (понятия), прямо или косвенно связанные с оценкой «успешности» проекта. Среди подобных концептов важное место занимают те из них, которые применяется в описании архитектурных видов, - прежде всего, подмножество концептов, выражающих интересы (concerns), вовлеченных в проект стейкхолдеров. Зачастую нарушения требований, выражающих интересы стейкхолдеров, приводят к неудачам проектирования. С этой точки зрения, часть требований, учитываемых в
архитектурных моделях имеет как семантическое выражение, так и оценочное значение: например, требования, предъявляемые к характеристикам качества, - «расширяемость», «масштабируемость», «понятность» и т.д.
В рамках данного исследования рассматриваются онтологические спецификации нечетких концептов, включая их оценочное значение. Предлагаемые решения ориентированы на их материализацию в инструментальной среде моделирования
OwnWIQA-^. Этот инструментарий поддерживает деятельность проектировщика на концептуальном этапе и включает в себя средства онтологического сопровождения разработки архитектурных решений.
Как было отмечено выше, по ходу разработки определенной SIS проектировщики формируют язык проекта, ядро которого содержит значимые концепты - некоторые из них относятся к требованиям (характеристикам), которые должны найти свои спецификации в процессе архитектурного моделирования разрабатываемой SIS. Согласно стандарту ISO/IEC/IEEE 42010:2011, такие характеристики имеют следующее определение: «интересы к разрабатываемой системе, проявляемые одной или рядом заинтересованных сторон».
Интерес как характеристика (разрабатываемой или завершённой) системы может иметь отношение к любому аспекту, оказывающему влияние (воздействие) на систему и овеществлённому в ней в форме, доступной для восприятия и оценки в среде существования системы, включая эволюционное, технологическое, оперативное, организационное, политическое, нормативное, социальное проявление в бизнес-процессах. В наиболее общем виде типичные виды таких характеристик представлены на рис. 1.
Харлктериегаки
Ф YH KILilUlIII, IЫ1Ы Г
фсбоваини Требовании к качеству
lli jcoKiiyiwm [еиые Необпвгеяыгая
описаннн того, фунпm платность
должна долггъ Характеристики качества система.
Рис.1. Виды характеристик, выражающих интересы
Понимание заинтересованных сторон и их интересов является основой для создания успешной архитектуры, поскольку разнообразие заинтересованных сторон и их интересов создают плодотворную среду и, соответственно, приводят к сложностям, с которыми сталкиваются архитекторы, а они, в свою очередь, должны учитывать эти сложности при разработке архитектурных решений. Чтобы подчеркнуть значимость данных условий, представим ряд интересов из их списка, приведённого в публикации приемлемость, доступность, точность, адаптивность, управляемость, ценовая доступность, гибкость, гарантированность, проверяемость, автономность, возможность
Т]кбомняя К
;|(ШТ1¥КП|Н&
Мотивы Цып Ныврсиия Ошиш1ш
резервного копирования, соответствие бизнес-целям, сертифицированность, совместимость с другими подсистемами, полнота, сложность, соответствие нормативным требованиям, концептуальная целостность, согласованность, конфиденциальность, конфигурируемость, правильность, настраиваемость, доступность данных, конфиденциальность данных, надежность, удобство развертывания, возможность аварийного восстановления, документируемость, долговечность, легкость обучения, простота использования, экономичность, эффективность, производительность, расширяемость, отказоустойчивость, гибкость, внедряемость, взаимозаменяемость, интуитивность, правомерность, локализуемость, ремонтопригодность, управляемость, мобильность, изменяемость, модульность, открытость, оперативность, переносимость, качество обслуживания, возможность восстановления, соответствие нормативным требованиям, воспроизводимость, время отклика, возможность повторного использования, безопасность, масштабируемость, удобство обслуживания, простота, стабильность, тестируемость, своевременность, отслеживаемость, понятность, удобство использования, универсальность и др. Этот список открыт для включения в него других характеристик, но его можно взять за основу для заимствований в любом проекте (это основная причина включения данного списка в нашу статью).
Как было сказано выше, любая характеристика из приведённого списка имеет определенную экспликацию, которая позволяет применить её для конкретного проекта и помогает проектировщику построить соответствующую им архитектуру или набор архитектурных видов в графической форме. Вся необходимая для этого информация должна найти свое выражение в соответствующей статье онтологии проекта.
В связи с этим, авторы предлагают дополнить структуру статьи традиционной онтологии такой спецификацией характеристики, которая отражала бы её оценочное значение. В свою очередь, это решение предполагает существование механизма присваивания оценочного значения для характеристики, в том числе, когда её значение является нечётким. Если такой механизм отсутствует, его следует изобрести.
Существуют следующие подходы к нечеткой спецификации характеристик, которые имеют оценочное значение:
■ Большая часть характеристик, соответствующих требованиям качества, содержит формулы для вычисления их метрик в стандарте ISO/IEC/IEEE 52010:2011 (бывший стандарт ISO 9126), и эти метрики могут использоваться для определения характеристик качества как соответствующих нечетких переменных.
■ Для оценок некоторых характеристик можно использовать стандарты, которые предписывают им нормативы профессиональной зрелости - например, CMMI-1.3 Development, PMBOK 5 или P1M3.
■ Существуют нечеткие характеристики, которые уже имеют нормативные шкалы для выражения их оценочного значения - например, «информационная безопасность» имеет шкалу с семью уровнями оценки (по стандарту ISO/IEC 15408).
■ Необходимо проанализировать текстовое описание выбранной характеристики и придумать ее спецификацию в форме соответствующей нечеткой переменной.
Выбор любого из возможных способов спецификации характеристик выведет на необходимость построения подходящей функции принадлежности для соответствующей нечеткой переменной. Если для какой-либо характеристики эта функция будет известна, ее можно использовать для оперативного мониторинга текущего значения
характеристики по ходу проектирования. Таким образом, на конечном этапе проектирования будет известно, какие из выбранных характеристик достигли своего запланированного значения.
В предметной области архитектурного моделирования сложился богатейший опыт, практики которого принято квалифицировать и оценивать с позиций профессиональной
зрелости, ориентируясь на модели профессиональной зрелости (Maturity Models) --71.
С позиций профессионально зрелого архитектурного моделирования и оценок его реализации следует различать:
Именно по этой причине архитектурное описание (Architeture Description, AD) в его текущем состоянии (изменяясь при необходимости) востребовано на всех этапах жизненного цикла разработки и эксплуатации соответствующей SIS.
Представим детальнее вопросы профессиональной зрелости в построении AD. В наиболее общем плане артефакт такого типа создают для полезного сопровождения (maintenance) практически всех активностей, осуществляемых в жизненном цикле АС (если учесть возвраты назад, обусловленные управлением изменениями).
Если интерпретировать создание AD в разработке определённой АС как проект по созданию системы (подсистемы AD), то, в связи с вышесказанным, для неё особо значимым атрибутом качества является «сопровождаемость» (maintainability). Учитывая, что подавляющее число атрибутов качества являются нечёткими понятиями, в первом приближении к «архитектурной сопровождаемости» с этим понятием целесообразно связать значение «сопровождаемости» в его понимании, представленном в стандарте ISO/IEC 9126.
Согласно данному стандарту, «сопровождаемость» интегрирует проявления свойств, описанных чуть ниже, за каждым их которых также стоит интеграция совокупности родственных качественных разновидностей, причем также нечётких по своей природе. На первом уровне детализации сопровождаемость включает в себя:
Учитывая специфику конструкта AD, интерпретируемого как подсистема, применяемая в проектировании АС, используемую в стандарте 9126 спецификацию «сопровождаемости» целесообразно расширить, включив в него характеристику «понятность» (Understandability).
Такой приём осуществлён в где авторы этой публикации приводит версию модели зрелости для разработки AD, представляя «сопровождаемость» композицией следующих атрибутов (и их составляющих): Stability (структурируемость, секционность, сложность), Analyza bility (понятность, трассируемость), Changeability (модифицируемость, расширяемость), Testability (в смысле предсказуемость). Для выбранных атрибутов в ^ предложена модель зрелости, в которой специфика уровней зрелости отражена в их названиях:
Таким образом, включение в процессы архитектурного моделирования интерпретации его процессов и результата с позиций профессиональной зрелости приводит, во-первых, к конструктивному представлению (на каждом уровне) «точек зрения» заинтересованных сторон, а во-вторых, к возможности оценивания каждого требования, учитываемого в AD, как лингвистической переменной с нечёткими значениями, привязанными к шкале уровней зрелости.
Как было отмечено выше, для работы с нечеткими характеристиками авторами принято решение использовать инструментарий OwnWIQA, который включает подсистему для создания проектных онтологий и их объединения в комплексы - например, для семейства связанных проектов (для семейства SIS). Концептуальная модель таких онтологических структур представлена на рис. 2.
Онтология проекта создается в форме рабочего словаря (соответствующего определенному проекту), который делится на группы и подгруппы. Концепт онтологии (понятие) - это элемент словаря, который может быть представлен его спецификацией, загруженной в соответствующую ячейку семантической памяти вопросно-ответного типа [81
Рис. 2. Структура создаваемой онтологии проекта
Ячейки такой памяти могут изменяться с сохранением концепта в форме, типичная структура которой представлена на рис. 3, где видно, что семантическое значение любого компонента обычно выражается его именем.
Рис. 3. Типичная структура концепта
На рисунке показано, что предусмотрена возможность прикрепления к концепту набора изображений (графических единиц), которые выражают необходимую или полезную информацию. Некоторые из этих изображений могут соответствовать функциям принадлежности, если ячейка содержит нечеткие понятия (например, нечеткие характеристики) в графической форме. В инструментальной среде OwnWIQA предусмотрен графический редактор, который можно использовать для создания и изменения подобных форм.
Первая группа родственных работ содержит публикации, посвященные месту и роли характеристик, выражающих интересы различных стейкхолдеров, в архитектурном описании систем с программным обеспечением. Глубокий анализ разнообразных характеристик, а также характеристики из стандарта ISO/IEC/IEEE 42010:2011 приводится в публикации Ряд представлений среды архитектурного моделирования приведён в статье -t^, где описываются точки зрения, которые определяют главные
принципы для создания и построения архитектурных представлений. В исследовании t10-рассматриваются особенности таких характеристик и точек зрения в сервис-ориентированных приложениях. Реальная практика архитектурных решений обсуждается в публикации учитывающей промышленную разработку SIS. Ретроспективный обзор теории и практики построения архитектурных описаний представлен в работе U^i.
Среди работ, посвященных использованию онтологий в проектировании SIS, начнём с
публикации -Ш1, в которой отмечено, что в теории и практики применения онтологий в проектировании ещё не накоплено достаточно опыта. Специфика проектных онтологий
раскрыта в отчёте -U41, в котором основное внимание уделяется «людям, процессу и продукту» и совместному пониманию взаимодействий. Проблемы онтологического сопровождения процессов разработки программных систем раскрыты в работе 1A5I.
Особо отметим публикацию i161, в которой онтология проекта применяется для анализа и формулировки архитектурных требований.
Еще одна группа родственных работ посвящена использованию онтологий и нечетких концептов в практике архитектурного моделирования. В этой группе, прежде всего,
необходимо отметить публикацию в которой приведена конструктивная версия
онтологического сопровождения процесса формирования требований к разрабатываемой
SIS, и статью t181, в которой представлен нечеткий подход к количественной оценке характеристик AD, основанный на архитектурных знаниях. Оригинальная версия онтологического подхода к принятию решений, учитывающая нечёткость используемых понятий, представлена в публикации li^I.
При создании архитектуры определенной системы у любой задачи, связанной с этим процессом, должна появиться своя адекватная спецификация и запланированная материализация. Поэтому подсистемой AD целесообразно связать её жизненный цикл. В ходе жизненного цикла важны следующие стадии материализации характеристик AD:
Указанные состояния являются контролируемыми результатами процесса, направленного на достижение запланированного оценочного значения характеристики, интерпретируемой как соответствующее требование. Более того, это достижение подтверждается материализацией данного требования. Что подсказывает решение связать с характеристикой нечеткий атрибут «достигнутое состояние планируемого значения характеристики», который позволил бы в режиме реального времени отслеживать состояния материализации характеристики в ходе проектирования.
Такая интерпретация оценки объективации рассматриваемой характеристики коррелируется с возможностями применения моделей зрелости процессов в разработке программного обеспечения. Как правило, подобные модели ориентированы на шкалу с
пятью уровнями зрелости. В специализированных прикладных моделях эти уровни имеют различные интерпретации. Среди специализированных моделей, ориентированных на
архитектурное описание, следует отметить модель, описанную в Эта модель имеет пять уровней оценки зрелости. Принимая во внимание данный способ оценки зрелости, а также с целью повышения качества, мы также предлагаем использование пяти уровней оценки, но с интерпретацией, описанной выше в этом подразделе. Способ оценки, основанный на уровнях, позволяет упростить определение функций принадлежности для характеристик качества. Он также может применяться для характеристик других видов, но с соответствующим количеством уровней. Некоторые виды шаблонов для характеристик (не только качественного вида) представлены на рисунке 4.
Рис. 4. Шаблоны функции принадлежности
Шаблоны «а)» и «Ь)» типичны для архитектурных требований. Они построены и скорректированы для шкалы с пятью уровнями для того, чтобы они соответствовали требованиям качества (шаблон «с)»). Четвертый шаблон <^)» перекликается с семью уровнями оценки по стандарту ^0/1ЕС 15408.
Чтобы использовать и оценивать характеристики, упомянутые в предыдущем разделе, при разработке определенного проекта, мы создали в онтологии специальный подраздел «Характеристики», который может использоваться в качестве основы для различных проектов. Каждый элемент этого подраздела имеет имя, текстовое определение и несколько атрибутов, таких как:
■ исполнитель (проектировщик);
■ дата;
■ пре дс та в ле ние ;
■ ссылки на точку зрения стейкхолдеров;
■ оценочное значение и т. д.
На рис. 5 показано, как раздел «Характеристики» представлен в инструментальной среде OwnWIQA на примере концепта «удобство использования».
Ргдлктор словарей
удобство 1Н««И**Я H3-VCH4 ст^^льиоств
мищеазяня
«и гдотмт«я»не стаз^ртач} Л" оэнятпкть
erpyirypup^tuocTii "" ио^пфиц^^тсиост* npiiiibUy™«!»
Определения
Псиизлтсср. рбрзтмцЯ TJ>_ JJJIJ-&JJ&J мл
и Других ВиДйЕ IX&С- <ЛО ВНК«нН|й4 ГфиМЛп
t нуКныМ риуЛъТ4Т4М.
УЛ^ЛлТЬ
Атрибуты
Исполнитель
Дагз
Ссылка на Оценочное
точку зрения значение
Рис. 5. Секция «Характеристики» в онтологии проекта
Как было отмечено выше, помимо определения концепта, его содержимое расширяется с помощью базовых и дополнительных атрибутов, которые соответствуют семантическому потенциалу ячейки памяти, представленной на рисунке 3. Поясним некоторые из этих атрибутов:
Следует отметить, что в онтологии проекта есть раздел для размещения аксиом онтологии, набор которых включает в себя правила согласованности характеристик. Обеспечение согласованности используется с помощью вычисления оценочных значений характеристик, названных в правилах архитектурного описания
Ниже представлен алгоритм инструментария по поиску концептов онтологии в проектных документах и получения потенциальных значений концептов из этих текстов:
Атрибуты, добавленные инструментом к концептам онтологии проекта, могут рассматриваться как первоначальный вариант значения нечетких переменных. Это означает, что разработчик должен проанализировать эти атрибуты и оценить характеристики. Это следует повторять на каждой стадии проектирования.
Рассмотрим в качестве примера характеристики «понятность» и «удобство использования» пользовательского интерфейса. Эти две характеристики тесно связаны друг с другом, потому что, когда мы говорим о высоком уровне удобства использования, мы имеем в виду, что пользователь может легко понять, как пользоваться системой в момент, когда он видит перед собой интерфейс. В случае если что-то осталось неясным, пользователь может воспользоваться онтологией проекта, чтобы получить больше информации о системе.
Следовательно, понятность может зависеть от того, достаточно ли информации об пользовательском интерфейсе содержится в онтологии проекта. Это означает, что при создании прототипов пользовательского интерфейса разработчик должен проверить, представлены ли все его элементы в онтологии проекта и при необходимости добавить новые концепты. Требуемое значение понятности считается достигнутым, когда все элементы пользовательского интерфейса могут быть найдены в онтологии проекта.
Процедура, которая проверяет наличие определенного термина в онтологии проекта и добавляет понятие, если оно отсутствует, может быть запрограммирована на языке псевдокода непосредственно инструментальной среде OwnWIQA (как показано ниже). Для удобства мы создали текстовый файл: «interface_elements.txt», который хранит всю текстовую информацию из прототипа пользовательского интерфейса.
LABEL LCycle // индекс начала цикла
conceptsNumber := CountStringsInFile("C:W IQAinterface_elements.txt")
IF i >= conceptsNumber THEN goto LOut
word := ReadFromFile(i, "C:WIQAinterface_elements.txt")
//чтение строки с индексом i из файла с нормализованными словоформами
wordID := Onto_GetWordId(dictID, groupID, word)
IF wordID ! = 0 THEN BEGIN
//если ID слова не равен нулю, то это означает, что данное слово содержится в онтологии
newWordID := Onto_CreateWord (groupID, word) END i := i +1 GOTO LCycle LABEL LOut Заключение
При разработке SIS целесообразно использовать нечеткие переменные, спецификации которых формируются и координируются в ходе процесса проектирования. В данной статье основное внимание уделяется такому типу архитектурных требований (характеристик), которые выражают интересы активных и потенциальных заинтересованных сторон. Выбор был вызван существенным влиянием материализации интересов, связанных с качеством, на успешность проектов.
Предлагаемый способ конструктивной работы с характеристиками скорректирован для его реализации в инструментальной среде OwnWIQA, которая имеет подсистему для создания и использования прикладных онтологий. Основной особенностью таких онтологий является хранение любых понятий в семантической памяти вопросно-ответного типа. Ячейки такой памяти позволяют не только регистрировать символьные описания характеристик, но и присоединять к ним другую полезную информацию, в том числе текстовую, графическую и алгоритмическую. Другими словами, ячейки памяти открыты для загрузки спецификаций таких сложных конструкций, как характеристики.
Сложность работы с характеристиками вызвана необходимостью объявить их так, чтобы они объективировались в обоснованных формах, которые позволяли бы использовать их повторно с различными целями. Главной из этих целей является подтверждение того, что характеристики нашли свои материализации. В рамках предлагаемого метода онтологические спецификации каждой обработанной характеристики помогают организовать мониторинг процесса достижения запланированного значения. Для вычисления текущего значения мы предлагаем использовать функции принадлежности, градуировка которых соответствует уровням зрелости процессов в разработке SIS. Такой выбор основан на практике (методике), которая позволяет достичь запланированной версии объективизации характеристик. Кроме того, он помогает регистрировать историю изменения состояний соответствующих требований.
Библиография