Почему следует аккумулировать и систематизировать знания при реализации ИТ-проекта
Как минимум потому, что это служит необходимой информационно-методической поддержкой проектных работ и принятия решений и особенно актуально в ситуациях высокой неопределенности и в слабоструктурированных средах. База знаний, формируемая в результате аккумуляции и систематизации подобных ресурсов, должна быть не только источником полезного опыта, полученного проектной группой в ходе работ по созданию информационной системы, но и максимально простым средством моделирования нового видения, способов и алгоритмов реализации проектных задач. Иными словами, такая база знаний является хранилищем интеллектуального капитала и вместе с тем инструментом управления знаниями.
Эффективность, полезность, качество базы знаний как инструмента коррелируют с ресурсоемкостью ее ведения и результативностью извлечения знаний. Чем проще и быстрее сбор и фиксация знаний в базе и чем более пертинентны результаты запросов к ней, тем лучше и надежнее сам инструмент. Тем не менее дискретные методы и средства структуризации, которые применимы для систем управления базами данных, в том числе нормализация отношений реляционных баз данных, не позволяют описывать или моделировать смысловые компоненты, интерпретации, интервальные и непрерывные семантические множества. Для этого нужен методологический подход, обобщающий частные случаи конечных онтологий и приближающий модель знаний к непрерывности описания предметной области информационной системы.
Таким подходом может быть объединение положений теории нечеткой математики и понятия фрактальной размерности — предлагаю рассмотреть его в настоящей статье.
Оптимизируя описание знаний по критерию степени непрерывности (величине шага дискретизации описания) в условиях ограничения по принципу неполноты Геделя (в информационной системе — принципиальной неполноты рассуждений, знаний, выводимых из этой системы при условии ее непротиворечивости), выполняя последовательную фаззификацию (приведение к нечеткости), получаем формализованное описание, которое максимально полно и связно отображает некоторый массив знаний и с которым при этом можно выполнять любые операции информационных процессов — сбор, хранение, обработку и передачу.
Use-case и test-case
Сценарий использования (use-case) нужен для отображения множества бизнес-требований на множестве функциональных возможностей и, как правило, содержит описание последовательности действий пользовательской роли в формате «шаг оператора — реакция системы» с отсылкой к соответствующим функциональным требованиям, описанию элементов макета UI и параметрам объектов логической модели данных. Сценарий тестирования (test-case), в свою очередь, зеркалит юзкейс и содержит набор методов и действий для проверки реализованных функциональных требований на соответствие ожидаемым результатам — эталонным реакциям системы, описанным в юзкейсе.
Я предлагаю рассмотреть подход к унификации работы над обоими видами сценариев от модульного принципа построения системной архитектуры. Как известно, он позволяет максимально приблизить технологическую реализацию информационных процессов к их естественному воплощению в реальном мире, разрабатывать наиболее удобные для масштабирования и модернизации решения. Модуль можно представить как некую обособленную сущность, которая бывает обязательной или опциональной для целей существования системы, но в любом случае обеспечивает уникальный в ее границах набор функций. А всё многообразие функциональных возможностей любого модуля сводимо к трем типами операций: создание (запись новых данных), редактирование (изменение ранее записанных данных), удаление (стирание ранее записанных данных).
Представим, что такое множество нечеткое и включает в себя элементы, структура которых фрактальна. Тогда создание данных не самоподобно (реализовано без рекурсии — функция создания не повторяет саму себя), а редактирование и удаление в общем случае могут предусматривать как поэлементную реализацию (выполнение операции над избранными элементами множеств данных), так и сами включать в составе подобные себе операции. Таким образом, каждый юзкейс и, соответственно, тест-кейс будут связаны с описанием шагов с рекурсивными наборами операций над множествами данных — создание, редактирование или удаление. Теперь разберемся со всем по порядку.
Определение рекурсии нечеткого множества
Пусть X — множество значений некоторой характеристики моделируемой системы:
где n ∈ N ≥ 3 — количество значений такой характеристики (больше, чем элементарный набор (0; 1) — (ложь; истина)).
Пусть X = B, где B ={a, b, c, …, z} — множество эквивалентов, поэлементно соответствующее множеству значений характеристики X.
Тогда нечеткое множество 
, которое соответствует нечеткому (в общем случае) понятию, описывающему характеристику X, может быть представлено в виде:
где m — шаг дискретизации описания, i ∈ N — кратность шага.
Соответственно, чтобы оптимизировать модель знаний об информационной системе по критерию непрерывности (мягкости) описания, оставаясь в границах пространства неполноты рассуждений, введем степень рекурсии нечеткого множества и получим следующий вариант его представления:
где 
— множество, соответствующее нечеткому понятию, в общем случае более полно описывающему по критерию мягкости характеристику X, чем множество ; Re — степень рекурсии описания.
Следует учесть, что 
сводимо к четкому множеству в частном случае при необходимости.
Введение дробной размерности
При Re = 1 множество представляет собой обычное нечеткое множество 2-й степени, включающее в качестве элементов нечеткие множества (либо их четкие отображения), описывающие все значения характеристики X:
Однако это вырожденный случай, и в наиболее полном представлении часть элементов могут быть множествами, в то время как остальные — тривиальными (предельно простыми) объектами. Именно поэтому для определения такого множества необходимо ввести дробную рекурсию — аналог дробной размерности пространства (в данном контексте — пространства онтологии некоторой предметной области).
При Re дробной размерности получаем следующую запись :
где 
— нечеткое множество для значения X1, 
— нечеткое множество для значения X2 и так далее.
В таком случае рекурсия становится, по сути, фрактальной, а множества описаний — самоподобными.
Как определить множество функциональных возможностей модуля
Архитектура открытой информационной системы предполагает принцип модульности, который обеспечивает возможность масштабирования, репликации, адаптивность и эмерджентность системы. Модульное построение позволяет максимально приблизить технологическую реализацию информационных процессов к их естественному объективному воплощению в реальном мире, разрабатывать наиболее удобные по своим функциональным свойствам средства, призванные не заменять людей, а эффективно помогать им в управлении знаниями.
Модуль представляет собой некую обособленную сущность информационной системы, которая может быть обязательной или опциональной для целей существования системы, но в любом случае обеспечивает уникальный в границах системы набор функций.
Напомню, что всё многообразие функциональных возможностей модулей можно описать тремя типами операций: создание (запись новых данных), редактирование (изменение ранее записанных данных), удаление (стирание ранее записанных данных).
Пусть X — некая характеристика таких функциональных возможностей, тогда соответствующее множество X можно представить в виде:
где X1 — создание, X2 — редактирование, X3 — удаление,
Как я уже отмечал, функциональные возможности любого модуля таковы, что создание данных не самоподобно, а редактирование и удаление в общем случае могут как предусматривать поэлементную реализацию (выполнение операции над избранными элементами множеств данных), так и сами включать в составе подобные себе операции.
Следует отметить, что если операция для функциональной возможности X в данном модуле не выполняется (не реализована в системе), то соответствующее такой операции множество рассматривается как пустое.
Таким образом, для описания нечеткого понятия (высказывания) «модуль позволяет выполнить операцию с соответствующим набором данных в целях информационной системы» нечеткое множество в простейшем случае можно представить как:
Такое множество в общем случае имеет степень рекурсии, равную 1⅔, и является фрактальным и нечетким одновременно.
Подготовка сценариев использования и тестирования модуля
На этапах разработки и эксплуатации информационной системы необходимы специальные сценарии, описывающие порядок и содержание операций для использования модулей по их функциональному назначению (сценарии использования), а также для проверки соответствия ожидаемого и реального результатов работы модулей (сценарии тестирования).
С учетом представлений, изложенных выше, процесс работы над такими сценариями можно описать следующим образом.
Для модуля формируется нечеткое множество :
где:
— нечеткое множество для операции создания данных по функциональной возможности X;
— нечеткое множество для операции редактирования данных по функциональной возможности X, при этом степень рекурсии a (вложения функции) является натуральным числом и в тривиальном случае равна 1;
— нечеткое множество для операции удаления данных по функциональной возможности X, при этом степень рекурсии b (вложения функции) является натуральным числом и в тривиальном случае равна 1.
Такое множество описывает, что именно (какие объекты данных) создают, редактируют и (или) удаляют при любом варианте использования модуля.
Затем составляется набор сценариев использования 
по функциональной возможности X для рассматриваемого модуля, в каждом из которых описывается, для чего (для какой бизнес-задачи) создают, редактируют и (или) удаляют объекты данных, описанные множеством , и в каком порядке:
где n — количество сценариев использования для X.
Далее составляют набор сценариев тестирования 
по функциональной возможности X для каждого сценария использования рассматриваемого модуля. В сценарии тестирования описывается, какие значения данных и в каком порядке используются при выполнении сценария использования, а также какой результат должен быть получен:
где [D] — массив тестовых данных, n — количество сценариев тестирования для X.
В описанном подходе количество сценариев тестирования равно числу соответствующих сценариев использования, что позволяет упростить работу над их описанием и актуализацией по мере развития системы. Кроме того, такой алгоритм может быть использован для автоматизации тестирования программных модулей информационной системы.
Выводы
Представленный метод нечеткой индукции можно использовать на разных стадиях жизненного цикла любой модульной информационной системы как в целях накопления описательной части базы знаний, так и в работе над сценариями использования и тестирования модулей.
Более того, нечеткая индукция помогает синтезировать знания на основе полученных нечетких описаний подобно «когнитивному калейдоскопу», в котором часть элементов остаются четкими и однозначными, в то время как другие по правилу самоподобия применяются указанное в степени рекурсии количество раз для каждого множества известных данных. В совокупности полученные нечеткие множества формируют модель, которая может быть использована как для целей информационной системы, так в интересах поиска новых знаний вообще.
Подобного рода методология может быть отнесена к своеобразной форме «искусственного интеллекта» с учетом того, что синтезированные множества не должны противоречить принципу неполноты рассуждений и призваны помогать интеллекту человека, а не заменять его.
