Модели требований/целеполагания пока проигрывают в популярности архитектурным моделям
Вчера прошло совместное заседание методсовета ШСМ и русского отделения INCOSE, где обсуждали SysArсhi (https://ailev.livejournal.com/1444887.html). Большинство вопросов было к мета-модели SysArchi в части требований/целеполагания (в ней части хорошо видны -- сиреневенькая часть относится к модели требований/целеполагания, жёлтенькая к архитектуре предприятия, зелёненькая -- архитектуре целевой системы):
Видео всего заседания -- https://youtu.be/yTa9UrjQgd4. Утверждённое соглашение о моделировании SysArchi версии 1.0 -- https://yadi.sk/i/zhht0RshtJzyMQ
Мои выводы:
-- разговор про архитектуру и архитектурные описания (спасибо ISO 42010, IEC 81346 и т.д.) уже более-менее все поддерживают. И более-менее понимают про 4D экстенсионализм. И что целевая система и обеспечивающая система неразрывны и должны бы моделироваться вместе.
-- модели требований не понимает никто. В головах только понятия "требования" и где-то далеко от них понятие "стейкхолдер". Далее идёт неясная цепочка понятий, где выделяются "потребности". Что трассировка потребностей к требованиям впрямую не может быть осуществлена (там же граница системы по пути! Изменение стейкхолдеров и их viewpoints/языка, разные свойства разных систем) признаётся, но про механизмы моделирования этого никто не знает. Поэтому уйма вопросов,
Итого:
-- соглашение о моделировании утвердили в текущей версии (обозвали её версией 1.0 и призвали духов природы продолжать работать над следующими версиями -- вдруг откликнутся?), равно как и отметили, что SysArchi в его текущем виде мало поможет в больших проектах, и что мало кто может внести в эту метамодель что дельное (а что там лишее -- так запросто можно не использовать. Например, не использовать моделирование требований вообще). Дальше внимание нужно уделять SysMoLan (https://ailev.livejournal.com/1443879.html).
-- мне нужно что-то делать, чтобы в головах появилось не только представление об архитектуре и основных архитектурных решениях, но и представление о целеполагании.
GORE -- goal-oriented requirements engineering, это как раз то, что требует моделей требований. Я когда-то много об этом писал: https://ailev.livejournal.com/811715.html (2010 год), и это был фронтир (https://ailev.livejournal.com/900086.html), но за прошедшее время моделирование требований прошло по факту в мейнстрим, и даже в определении системной инженерии начали говорить не только о раннем по жизненному циклу определении/описании потребностей (stablishing stakeholders’ purpose and success criteria, and defining actual or anticipated customer needs and required functionality, early in the development cycle), но и документировании и моделировании требований: https://ailev.livejournal.com/1453390.html. Тем самым GORE и MBCD начинают смешиваться до неразличения -- и это поставлено как проблема в инженерии требований, см. соответствующий раздел в https://ailev.livejournal.com/1425741.html
Модели требований понимаются сейчас как модели, в которых отмоделированы взаимовлияния стейкхолдеров по поводу системы: что кто почему хочет. Эти модели нужны, чтобы снимать противоречия в требованиях, в том числе за счёт снятия стейкхолдерских конфликтов -- почему и нужно моделировать стейкхолдеров и их взаимоотношения.
Работа с целями обеспечивающих систем (в инженерии предприятий, по факту это практики стратегирования) -- это модели целеполагания, motivation models (например, стандарты OMG BMM, business motivation model, или OpenGroup ArchiMate 3.0 motivation extention).
Системность SysArсhi была в том, чтобы
-- моделировать целевую систему в её операционном окружении и обеспечивающие системы в рамках одной модели. И рамках одной же модели и с одинакомым подходом делать моделирование требований/целеполагания для целевой системы и для обеспечивающей (например, использовать эти модели для проведения business/mission analysis -- понимать, насколько участие в проекте какой-то целевой системы связано со стратегией предприятия обеспечивающей системы).
-- убрать дребезг, возникающий при моделировании сразу нескольких системных уровней (когда в зависимости от уровня кого-то называют то "член команды", то "(внешний) стейкхолдер" или одно и то же описание то "потребностью/требованием стейкхолдера", то "системным требованием". В Архимейте всё это одноуровнево, поэтому полно этих разделений на "внутренний-внешний". Поэтому значок используем один: "требование", а уж как его разные команды назовут (требование, потребность, ограничение/архитектурное решение) -- это уже зависит от того уровня, которым занимается команда, как целевой системой.
-- моделировать на одной диаграмме все важные описания: не только архитектурные описания, но и архитектурные потребносити/требования/стратегию (архитектурные, то есть ведущие к архитектурным решениям, потому как для детальной инженерии требований все эти визуальные языки -- слону дробина, см. подробней книжку "Визуальное мышление. Доклад о том, почему им нельзя обольщаться", там я об этом подробно написал: https://ailev.livejournal.com/1437344.html). Вот модель целеполагания и попала в мета-модель.
Архимейт этого всего не позволяет сделать как-то приемлемо, конечно, но цели были именно такими. Так что тамошний обрывок модели требований/целеполагания -- это как раз попытка отразить последний пункт, добавить язык моделирования требований в архитектурный язык. Конечно, возникает большое количество вопросов к самой модели целеполагания именно АрхиМейта (она не была существенно поправлена в SysArchi), но предназначена она именно для того, чтобы требования брались как-то обоснованно, с учётом какой-то цепочки моделирования ситуации в системном окружении, ведущей к системным требованиям.
Основные различения для этого моделирования заключаются в понятиях стейкхолдер, интерес, оценка интереса, цель, принцип/дисциплина, требования. Увы, большинство обсуждающих пытаются вообразить, что бы там могло скрываться за этими обыденными словами (их не волнует обычно, что в английском для "цели" могли бы быть target, goal, object, objective, aim и даже mark, purpose и end, и это ещё не конец списка -- да и по-русски тоже есть много чего, включая канцеляритную "целеустановку". Но очень редко "мишень", хотя в английском target тут вполне немилитаристски слышится). Со словом "интерес" (concern) вообще беда. Но в данном случае непонимания моделей требований упирается не в эту игру содержанием слов (см. "слова-термины важны, и слова-термины неважны" -- https://ailev.livejournal.com/1442764.html), а именно с непониманием самой идеи моделирования требований, обсуждаемых там сущностей-концептов.
Вот онтика системных описаний, где подробно прописаны понятия интереса и оценки интереса -- https://ailev.livejournal.com/1429330.html. В том числе там прописано отличие интереса (concern) и метода описания (viewpoint). Это самая частая ошибка моих студентов. Понятие дисциплины (из которой берутся принципы, как закономерности дисциплины, и для выражения понятий которой существует метод описаний) -- вот тут: https://ailev.livejournal.com/1427265.html. Дисциплина нам важна, как что-то, позволяющее адекватно моделировать интерес. Интерес -- это просто функциональное обозначение какой-то предметной области, необходимой стейкхолдеру для его деятельности. Он для удовлетворения своего интереса он выбирает (или ему предлагают!) какую-то дисциплину и связанный с ней метод описания объектов этой дисциплины. И далее уже описывается, что там с оценкой интереса в данном проекте. То есть "хотелка" это не интерес, а как раз оценка интереса! А цель -- это переход в действие, что нужно сделать (глагол), чтобы сдвинуть оценку интереса. Результирующие требования описываются в терминах выбранной дисциплины (и если вы не читали учебники по дисциплинам, отвечающим на те или иные интересы проекта, то вам этих требований обычно не понять. Ну, или вы просто не учтёте этих требований, потому как не знали о них! Помним, что требования открывают/discover или выявляют/elicit, а не "разрабатывают" -- сидя на диване, их не "сочинишь").
Современные методы разработки требований в этом месте не заморачиваются особо. Например, JTBD хорош для разработки приложений в телефоне (и все примеры оттуда: один человек, которого нужно обслужить по-королевски). А если вам нужно определиться с требованиями к авиадвигателю, то вечер сразу станет томным. С другой стороны, использовать для требований к авиадвигателю визуальный язык -- это неправильно вообще (правильно, если авиадвигатель из "образовательного авиастроения", по аналогии с "образовательной робототехникой". То есть самолёт и двигатель оба игрушечные, "из учебного проекта"). Так что языком моделирования требований должен быть текстовый язык.
В общем, с моделированием требований/целеполагания беда. Вывод: мне нужно об этом говорить более подробно. У меня сейчас в поддержку архитектурных описаний (кишок системы) самая толстая и сложная глава в учебнике -- пятая. А в поддержку внешних (чёрного ящика) описаний системы много меньше. А зря. Так что буду потихоньку вносить поправки в свои курсы и тексты, исправлять ситуацию.
UPDATE: Обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214214245764141
Видео всего заседания -- https://youtu.be/yTa9UrjQgd4. Утверждённое соглашение о моделировании SysArchi версии 1.0 -- https://yadi.sk/i/zhht0RshtJzyMQ
Мои выводы:
-- разговор про архитектуру и архитектурные описания (спасибо ISO 42010, IEC 81346 и т.д.) уже более-менее все поддерживают. И более-менее понимают про 4D экстенсионализм. И что целевая система и обеспечивающая система неразрывны и должны бы моделироваться вместе.
-- модели требований не понимает никто. В головах только понятия "требования" и где-то далеко от них понятие "стейкхолдер". Далее идёт неясная цепочка понятий, где выделяются "потребности". Что трассировка потребностей к требованиям впрямую не может быть осуществлена (там же граница системы по пути! Изменение стейкхолдеров и их viewpoints/языка, разные свойства разных систем) признаётся, но про механизмы моделирования этого никто не знает. Поэтому уйма вопросов,
Итого:
-- соглашение о моделировании утвердили в текущей версии (обозвали её версией 1.0 и призвали духов природы продолжать работать над следующими версиями -- вдруг откликнутся?), равно как и отметили, что SysArchi в его текущем виде мало поможет в больших проектах, и что мало кто может внести в эту метамодель что дельное (а что там лишее -- так запросто можно не использовать. Например, не использовать моделирование требований вообще). Дальше внимание нужно уделять SysMoLan (https://ailev.livejournal.com/1443879.html).
-- мне нужно что-то делать, чтобы в головах появилось не только представление об архитектуре и основных архитектурных решениях, но и представление о целеполагании.
GORE -- goal-oriented requirements engineering, это как раз то, что требует моделей требований. Я когда-то много об этом писал: https://ailev.livejournal.com/811715.html (2010 год), и это был фронтир (https://ailev.livejournal.com/900086.html), но за прошедшее время моделирование требований прошло по факту в мейнстрим, и даже в определении системной инженерии начали говорить не только о раннем по жизненному циклу определении/описании потребностей (stablishing stakeholders’ purpose and success criteria, and defining actual or anticipated customer needs and required functionality, early in the development cycle), но и документировании и моделировании требований: https://ailev.livejournal.com/1453390.html. Тем самым GORE и MBCD начинают смешиваться до неразличения -- и это поставлено как проблема в инженерии требований, см. соответствующий раздел в https://ailev.livejournal.com/1425741.html
Модели требований понимаются сейчас как модели, в которых отмоделированы взаимовлияния стейкхолдеров по поводу системы: что кто почему хочет. Эти модели нужны, чтобы снимать противоречия в требованиях, в том числе за счёт снятия стейкхолдерских конфликтов -- почему и нужно моделировать стейкхолдеров и их взаимоотношения.
Работа с целями обеспечивающих систем (в инженерии предприятий, по факту это практики стратегирования) -- это модели целеполагания, motivation models (например, стандарты OMG BMM, business motivation model, или OpenGroup ArchiMate 3.0 motivation extention).
Системность SysArсhi была в том, чтобы
-- моделировать целевую систему в её операционном окружении и обеспечивающие системы в рамках одной модели. И рамках одной же модели и с одинакомым подходом делать моделирование требований/целеполагания для целевой системы и для обеспечивающей (например, использовать эти модели для проведения business/mission analysis -- понимать, насколько участие в проекте какой-то целевой системы связано со стратегией предприятия обеспечивающей системы).
-- убрать дребезг, возникающий при моделировании сразу нескольких системных уровней (когда в зависимости от уровня кого-то называют то "член команды", то "(внешний) стейкхолдер" или одно и то же описание то "потребностью/требованием стейкхолдера", то "системным требованием". В Архимейте всё это одноуровнево, поэтому полно этих разделений на "внутренний-внешний". Поэтому значок используем один: "требование", а уж как его разные команды назовут (требование, потребность, ограничение/архитектурное решение) -- это уже зависит от того уровня, которым занимается команда, как целевой системой.
-- моделировать на одной диаграмме все важные описания: не только архитектурные описания, но и архитектурные потребносити/требования/стратегию (архитектурные, то есть ведущие к архитектурным решениям, потому как для детальной инженерии требований все эти визуальные языки -- слону дробина, см. подробней книжку "Визуальное мышление. Доклад о том, почему им нельзя обольщаться", там я об этом подробно написал: https://ailev.livejournal.com/1437344.html). Вот модель целеполагания и попала в мета-модель.
Архимейт этого всего не позволяет сделать как-то приемлемо, конечно, но цели были именно такими. Так что тамошний обрывок модели требований/целеполагания -- это как раз попытка отразить последний пункт, добавить язык моделирования требований в архитектурный язык. Конечно, возникает большое количество вопросов к самой модели целеполагания именно АрхиМейта (она не была существенно поправлена в SysArchi), но предназначена она именно для того, чтобы требования брались как-то обоснованно, с учётом какой-то цепочки моделирования ситуации в системном окружении, ведущей к системным требованиям.
Основные различения для этого моделирования заключаются в понятиях стейкхолдер, интерес, оценка интереса, цель, принцип/дисциплина, требования. Увы, большинство обсуждающих пытаются вообразить, что бы там могло скрываться за этими обыденными словами (их не волнует обычно, что в английском для "цели" могли бы быть target, goal, object, objective, aim и даже mark, purpose и end, и это ещё не конец списка -- да и по-русски тоже есть много чего, включая канцеляритную "целеустановку". Но очень редко "мишень", хотя в английском target тут вполне немилитаристски слышится). Со словом "интерес" (concern) вообще беда. Но в данном случае непонимания моделей требований упирается не в эту игру содержанием слов (см. "слова-термины важны, и слова-термины неважны" -- https://ailev.livejournal.com/1442764.html), а именно с непониманием самой идеи моделирования требований, обсуждаемых там сущностей-концептов.
Вот онтика системных описаний, где подробно прописаны понятия интереса и оценки интереса -- https://ailev.livejournal.com/1429330.html. В том числе там прописано отличие интереса (concern) и метода описания (viewpoint). Это самая частая ошибка моих студентов. Понятие дисциплины (из которой берутся принципы, как закономерности дисциплины, и для выражения понятий которой существует метод описаний) -- вот тут: https://ailev.livejournal.com/1427265.html. Дисциплина нам важна, как что-то, позволяющее адекватно моделировать интерес. Интерес -- это просто функциональное обозначение какой-то предметной области, необходимой стейкхолдеру для его деятельности. Он для удовлетворения своего интереса он выбирает (или ему предлагают!) какую-то дисциплину и связанный с ней метод описания объектов этой дисциплины. И далее уже описывается, что там с оценкой интереса в данном проекте. То есть "хотелка" это не интерес, а как раз оценка интереса! А цель -- это переход в действие, что нужно сделать (глагол), чтобы сдвинуть оценку интереса. Результирующие требования описываются в терминах выбранной дисциплины (и если вы не читали учебники по дисциплинам, отвечающим на те или иные интересы проекта, то вам этих требований обычно не понять. Ну, или вы просто не учтёте этих требований, потому как не знали о них! Помним, что требования открывают/discover или выявляют/elicit, а не "разрабатывают" -- сидя на диване, их не "сочинишь").
Современные методы разработки требований в этом месте не заморачиваются особо. Например, JTBD хорош для разработки приложений в телефоне (и все примеры оттуда: один человек, которого нужно обслужить по-королевски). А если вам нужно определиться с требованиями к авиадвигателю, то вечер сразу станет томным. С другой стороны, использовать для требований к авиадвигателю визуальный язык -- это неправильно вообще (правильно, если авиадвигатель из "образовательного авиастроения", по аналогии с "образовательной робототехникой". То есть самолёт и двигатель оба игрушечные, "из учебного проекта"). Так что языком моделирования требований должен быть текстовый язык.
В общем, с моделированием требований/целеполагания беда. Вывод: мне нужно об этом говорить более подробно. У меня сейчас в поддержку архитектурных описаний (кишок системы) самая толстая и сложная глава в учебнике -- пятая. А в поддержку внешних (чёрного ящика) описаний системы много меньше. А зря. Так что буду потихоньку вносить поправки в свои курсы и тексты, исправлять ситуацию.
UPDATE: Обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214214245764141