Зачем нам нужна модель знаний? За последние несколько десятилетий существования отрасли информационных технологий была создана значительная теоретическая база.
Многочисленные ассоциации и организации разработали массивы знаний и методологий в различных областях.
Вот некоторые из них:
- БАБОК (A Guide to the Business Analysis Body of Knowledge) — путеводитель по совокупности знаний по бизнес-анализу от Международного института бизнес-анализа (IIBA).
- СВЕБОК (Software Engineering Body of Knowledge) — международный стандарт ISO/IEC TR 19759 от 2015 года, описывающий общепринятый свод знаний о программной инженерии.
- СЕБОК (Свод знаний системной инженерии) - совокупность знаний в области системной инженерии, разработанная организацией BKCASE, которая контролируется Управляющим советом, состоящим из трех ассоциаций (т.е.
Международного совета по системной инженерии, Исследовательского центра системной инженерии и IEEE Computer).
Общество)
- БПМ CBOK (Руководство к Своду знаний по управлению бизнес-процессами) - свод знаний по управлению бизнес-процессами Ассоциации специалистов по управлению бизнес-процессами (ABPMP).
- ПМБОК (Project Management Body Of Knowledge) — совокупность профессиональных знаний по управлению проектами Института управления проектами PMI.
- Сертификация IREB CPRE (сертификация по инженерии требований) Foundation Level — методология разработки требований сообщества IREB.
Сотни страниц сухого текста: определений, классификаций, зачастую нет русского перевода – все это мешает усвоению ценного материала, представленного в источниках.
Чтобы систематизировать и использовать такой объем информации в работе, необходимо представить знания в более удобной и сжатой форме.
В настоящее время существует множество способов представления знаний: семантические сети, фреймы, языки и нотации и т. д. ( Википедия ).
Один из этих методов можно использовать для ведения конспектов изучаемого материала в виде модели знаний, чтобы:
- извлекать существенные понятия о понятиях, описанных в совокупности знаний
- получить структурированное, систематическое представление о связях между понятиями
- обеспечить быстрый доступ к изучаемой информации, чтобы в дальнейшем быстро и удобно использовать ее в своей работе.
Что должна включать в себя модель знаний?
Совокупность знаний и методологий проектирования требований и системного анализа описывают процессы, методы и подходы, используемые при проектировании и создании информационных систем.А поскольку это процессы, то классический подход к такой модели заключается в том, чтобы ответить на основные вопросы:
- ВОЗ? - какие субъекты с каким набором компетенций осуществляют деятельность в процессах
- Как? - какие действия, приемы и события включают в себя процессы, в какой последовательности они выполняются; Помимо описания самой деятельности, важно отразить:
- ключевые принципы, на которых строится деятельность
- ключевые свойства и аспекты деятельности
- основные ограничения
- определения и факты, связанные с процессами
- Что? - какие достигнутые результаты и другие объекты являются результатом деятельности или являются входными данными для деятельности?
- За что? - какие ценные действия и процессы вносят вклад в общий процесс разработки требований и системного анализа.
- структурный - отношение к группе, связь части и общего
- зависимости - влияние понятий друг на друга или операции, связывающие понятия друг с другом.
- динамичный - указать последовательность выполнения, направление потока информации
- генерализация и специализация - связь абстрактного и конкретного представления одного понятия, отражающая наследственность.
Архимат для представления знаний
Для реализации модели на практике понадобится простой и удобный в использовании инструмент, способный наглядно (в графической форме) представить выявленные понятия, определения и связи.Ниже представлена попытка представить методологию разработки требований сообщества IREB как модель знаний в Обозначения ArchiMate .
Нотация ArchiMate предназначена для описания архитектуры информационных систем, имеет собственное бесплатное кроссплатформенное программное обеспечение и описывает широкий спектр аспектов информационных систем на различных уровнях (уровнях абстракции) системы: стратегия, бизнес, приложения, технологии.
, производство, внедрение и переходы, мотивация.
Позволяет описать пассивную и активную структуру системы, ее поведение и различные виды связей между элементами.
Некоторые примеры описания модели знаний с использованием элементов нотации Archimate: 1. Виды деятельности, группы видов деятельности и связи между ними.
Цель описания: ответить на вопрос «КакЭ» - описать последовательность и структуру выполняемых в процессе действий, а также используемые приемы.
Используя элемент слоя реализации «Пакет работ», вы можете отразить действия и методы, используемые в процессах.
Отношения «Композиция» отражают, что одно действие является частью более крупной группы действий.
Соединение «Триггер» позволяет отображать последовательность действий.
Например, процесс организации работы с требованиями включает в себя деятельность по управлению жизненным циклом, которая состоит из последовательности этапов: Определение моделей жизненного цикла → Контроль переходов и т. д. 
Элемент «Ценность» позволяет указать ценность или преимущества использования действия в общем процессе и ответить на вопрос модели «ПочемуЭ» вопрос.
2. Результаты деятельности Цель описания: ответить на вопрос «ЧтоЭ» - описывать основные ключевые результаты деятельности и процессов, информационных потоков.
Результаты деятельности описываются элементом «Результат».
Отношения «Реализация» отражают, какая деятельность создает результаты.
Отношение «Доступ» позволяет вам показать чтение или запись информации из/в доставленные результаты.
Связь «Поток» отражает факт передачи информации (без указания сущностей) между действиями или событиями.
Например, результатом деятельности по выявлению заинтересованных сторон являются списки заинтересованных сторон, которые вводятся в деятельность по выявлению требований.
Кроме того, при выявлении требований используется информация о необходимости изменений.
3. Свойства деятельности Цель описания: отразить основные принципы, свойства, ограничения и аспекты деятельности, а также связанные с ними определения.
Используя элементы слоя мотивации ArchiMate, вы можете описать ключевые свойства, аспекты, определения и ограничения, связанные с действиями и доставляемыми результатами системы.
Элемент «Требование» описывает свойства или аспекты, связанные с деятельностью или результатами процесса.
Элемент «Принцип» позволяет описать ключевые принципы, связанные с деятельностью.
Элемент «Значение» можно использовать для описания ключевых понятий и определений.
Используя отношение «Ассоциация», описанные артефакты связываются с действиями и полученными результатами.
Например, процесс разработки требований имеет «Ключевые аспекты процесса RE» (разложенные в отдельном представлении) и основан на девяти ключевых принципах.
«Принцип 4. Контекст» связан с понятием «Контекст» (само определение дано в описании элемента).
Факторы, которые каким-либо образом ограничивают пространство свойств или влияют на свойство, отражаются элементом «Ограничение», а само влияние отражается связью «Влияние».
4. Отношения между действиями и субъектами, их выполняющими: роль или действующее лицо несет ответственность или выполняет некоторые действия.
Цель описания: ответить на вопрос «КтоЭ» - описать наборы компетенций и основных участников процессов.
Элемент «Роль» (Business Role) позволяет отразить набор компетенций или область ответственности, связанную с деятельностью.
Элемент Business Actor представляет бизнес-субъект, выполняющий данную деятельность.
Это может быть как конкретный человек, так и структурные подразделения, например, подразделения.
Отношение присвоения устанавливает связь между соответствующим активным элементом и выполняемой им деятельностью.
Например, «Заинтересованные стороны» формируют «Спрос на изменения», который запускает процесс инжиниринга требований, который выполняет роль «Инженера по требованиям», обладающего определенным набором компетенций (указан в описании).
5. Структурные связи между субъектами.
Обобщение и специализация Используя отношение Агрегация, элементы одного типа можно объединять в группы, организованные в сложные иерархии.
На схеме элементы могут быть отражены как отдельные элементы, соединенные между собой или расположенные в границах родительского элемента.
Например, ключевые аспекты процесса разработки требований включают аспект требований и времени, который, в свою очередь, включает аспект спецификации, основанной на рисках.
С помощью отношения Состав отображаются случаи, когда один элемент является неотъемлемой частью другого (не может существовать без него).
Например, обучение пользователей является частью процесса выбора инструмента CASE. Связь «Специализация» позволяет отразить связь между абстрактным понятием и его конкретными реализациями.
Например, концепция модели включает модели системного контекста, которые, в свою очередь, могут быть реализованы в виде диаграмм DFD или вариантов использования UML. 
6. Что еще может сделать Арчи? Каждому элементу можно дать описание или текстовое пояснение.
ArchiMate включает в себя инструмент для просмотра всех связей выбранного элемента.
Глубину соединений можно регулировать.
В состав Archi входит плагин, позволяющий загрузить модель в формат html для размещения на сайте с минимальными изменениями.
В формате реализована навигация по модели: переходы от вида к виду по клику на ссылку вида, отображение описаний выбранных элементов.
Заключение
Методология разработки требований сообщества IREB описывается моделью представления знаний ArchiMate. Результат здесь: Что было достигнуто:- представить знания о разработке требований в графической форме
- выделить основные понятия, связи между ними и записать описание ключевых определений
- реализовать простой и удобный доступ к модели в сети Интернет.
- элементы реализации используются для описания деятельности и доставляемых результатов, что ограничивает использование типов связей между элементами схемы; возможно, лучше было бы использовать элементы для описания бизнес-процессов
- сфера применения модели – достаточность для описания других областей знаний системного анализа
- возможность описания нескольких кодов и методологий в одной модели; например, описанная методология не выделяет отдельно процесс анализа требований, что ограничивает возможность совмещения этой модели с областью знаний о системном анализе в целом.
-
8 Важных Факторов Для Изучающих Vista
19 Oct, 24 -
Обзор Блога №26
19 Oct, 24 -
Мониторинг S.m.a.r.t. В Заббиксе
19 Oct, 24 -
Лагерная Игра «Торренты»
19 Oct, 24
