Проект стандарта управления требованиями ISO 29148. Заметки с обсуждения.
На четырнадцатом заседании Русского отделения INCOSE (слайды и видео первого часа: http://community.livejournal.com/incose_ru/7754.html) главным образом обсуждался проект стандарта ISO/IEC 29148 "Software and systems engineering - Life cycle processes - Requirements engineering" (докладчиком был puln, это стандарт, уточняющий требования ISO 15288 и 15289. Члены Русского отделения INCOSE получили проект этого стандарта почтой перед заседанием).
Вот мои заметки с заседания:
1. Люди, незнакомые с онтологической спецификой современных САПР, выпадают из обсуждения -- ибо люди, знакомые с такой спецификой, немедленно начинают обсуждать особенности формальной онтологии в попытках связать разные группы описаний (views) с той группой описаний, которая является целевой на данный момент (требования). У нас в Русском отделении INCOSE чуть ли не половина участников обсуждения знакома с архитектурой интеграции данных по ISO 15926, а половина -- незнакома. Нужно что-то с этим делать, иначе мы не сможем плодотворно обсуждать огромное количество тем. Так, слайд про Requirements Breakdown structure половина участников просто не поняла (особенно тот момент, что над ним изображены структуры данных из ISO 15926-4).
2. Мысль о том, что требования бывают самые разные по их роли в ходе жизненного цикла, и выражаются разными типами спецификаций, неожиданно оказалась трудной для обсуждения и понимания. А ведь ISO 15288 вводит много разных видов требований (см. http://ailev.livejournal.com/706776.html), и значительная часть работы системного инженера связана с переходом от одних видов требований к другим. Оказывается, эта идея дается не так легко (впрочем, это относится к почти любым типам различений). Тут, конечно, существенно влияет понимание вопроса о соотнесении всех этих требований: неявно предполагается, что такое соотнесение возможно -- но это явно отход от системного подхода (так, свойства системы эмерджентны, и никаким образом не выводятся из свойств элементов. Поэтому никакого разнесения-allocation и соотнесения-tracing быть в этом месте не может, хотя и требуется стандартом. Это нужно, наверное, отдельно и специально обсуждать).
3. Софтверный шовинизм -- забавное явление. У софтверщиков границы обсуждаемой системы -- софт, а все остальное -- морок и "внешние системы", с которыми они работают безо всяких принципов системной или программной инженерии. Представить, что "пользователь" тоже проходит свой жизненный цикл (и что в этот жизненный цикл не нужно включать "рождение и болезни"), для софтверщиков довольно сложно. А идея обсуждать этот цикл в том же системном подходе и его терминологии, что софтовые и железные системы, вообще представляется странной. Поэтому софтверщики не так готовы включать людей в описываемую часть системы, и люди для них остаются чудесным и загадочным явлением, работа с людьми минимально технологизируется. Системные инженеры, которые работают с оборудованием (в том числе с входящим в состав оборудования софтом) много больше склонны включать людей в состав системы. И все-таки системные инженеры-железячники с огромным лагом заимствуют практики у софтверщиков -- так что в чем-то этот софтверный шовинизм оправдан.
4. Системные инженеры, работающие с людскими системами, отстают в огромной степени: с одной стороны, они понимают, что никакой бихевиоризм и "проектный подход" с людьми не прокатит (ибо люди весьма рефлексивны и могут как способствовать прохождению ими жизненного цикла на пути реализации новых умений и знаний, а затем интеграции себя в целевую киберфизическую систему, так и весьма изобретательно препятствовать этому). С другой стороны, им приходится как-то участвовать в обсуждениях договорившихся об общей терминологии в рамках системного подхода железячников и софтверщиков. И чтобы не представать эдакими шаманами, "ловцами душ", им приходится как-то подстраиваться. Если железячники заимствуют идеи у софтверщиков с десятилетним лагом, то человечники (формальное имя этого -- human-system integration, HSI, http://ailev.livejournal.com/671112.html) отстают от тех же железячников еще на десяток лет.
Стандарт ISO 29748 хорошо это иллюстрирует: он различает по типу "спецификацию системы" и "спецификацию софта", а "спецификацию людей/организации" не различает (нужно понимать так, что она прячется где-то внутри спецификации системы). А ведь в общем случае уже общепринято, что системы состоят из тупого железа, всякого софта (включая документы и "все, что легко копировать") и людей. Три совершенно разных жизненных цикла, которые очень трудно интегрировать в одной системе.
5. Очень сложно дается понимание "вложенности" окружений:
-- внешний мир (и соглашения с ним + регулирование)
-- бизнес/менеджмент
-- проекты/"операции" (project management, который вовсе не "менеджмент" в смысле "управления", а из той же серии, что configuration management или risk management. Знаю, знаю, что эти "проектные управленцы", а не "управляющие проектами" о себе думают -- это я называю "проектный шовинизм", того же сорта явление, что и "процессный шовинизм" управленцев качеством с их quality management как "качественным управлением" вместо "управления качеством")
-- техническая суть дела, собственно выполнение преобразований мира для получения целевой системы или услуги.
Эта схема базовая для ISO 15288, но уже не воспринимается как "та же самая" в чуть-чуть измененом изложении ISO 29148. И вообще не воспринимается как базовая, основная, главная. А ведь это как раз описание связи менеджеров и инженеров, мира бизнеса и технического мира.
Вот мои заметки с заседания:
1. Люди, незнакомые с онтологической спецификой современных САПР, выпадают из обсуждения -- ибо люди, знакомые с такой спецификой, немедленно начинают обсуждать особенности формальной онтологии в попытках связать разные группы описаний (views) с той группой описаний, которая является целевой на данный момент (требования). У нас в Русском отделении INCOSE чуть ли не половина участников обсуждения знакома с архитектурой интеграции данных по ISO 15926, а половина -- незнакома. Нужно что-то с этим делать, иначе мы не сможем плодотворно обсуждать огромное количество тем. Так, слайд про Requirements Breakdown structure половина участников просто не поняла (особенно тот момент, что над ним изображены структуры данных из ISO 15926-4).
2. Мысль о том, что требования бывают самые разные по их роли в ходе жизненного цикла, и выражаются разными типами спецификаций, неожиданно оказалась трудной для обсуждения и понимания. А ведь ISO 15288 вводит много разных видов требований (см. http://ailev.livejournal.com/706776.html), и значительная часть работы системного инженера связана с переходом от одних видов требований к другим. Оказывается, эта идея дается не так легко (впрочем, это относится к почти любым типам различений). Тут, конечно, существенно влияет понимание вопроса о соотнесении всех этих требований: неявно предполагается, что такое соотнесение возможно -- но это явно отход от системного подхода (так, свойства системы эмерджентны, и никаким образом не выводятся из свойств элементов. Поэтому никакого разнесения-allocation и соотнесения-tracing быть в этом месте не может, хотя и требуется стандартом. Это нужно, наверное, отдельно и специально обсуждать).
3. Софтверный шовинизм -- забавное явление. У софтверщиков границы обсуждаемой системы -- софт, а все остальное -- морок и "внешние системы", с которыми они работают безо всяких принципов системной или программной инженерии. Представить, что "пользователь" тоже проходит свой жизненный цикл (и что в этот жизненный цикл не нужно включать "рождение и болезни"), для софтверщиков довольно сложно. А идея обсуждать этот цикл в том же системном подходе и его терминологии, что софтовые и железные системы, вообще представляется странной. Поэтому софтверщики не так готовы включать людей в описываемую часть системы, и люди для них остаются чудесным и загадочным явлением, работа с людьми минимально технологизируется. Системные инженеры, которые работают с оборудованием (в том числе с входящим в состав оборудования софтом) много больше склонны включать людей в состав системы. И все-таки системные инженеры-железячники с огромным лагом заимствуют практики у софтверщиков -- так что в чем-то этот софтверный шовинизм оправдан.
4. Системные инженеры, работающие с людскими системами, отстают в огромной степени: с одной стороны, они понимают, что никакой бихевиоризм и "проектный подход" с людьми не прокатит (ибо люди весьма рефлексивны и могут как способствовать прохождению ими жизненного цикла на пути реализации новых умений и знаний, а затем интеграции себя в целевую киберфизическую систему, так и весьма изобретательно препятствовать этому). С другой стороны, им приходится как-то участвовать в обсуждениях договорившихся об общей терминологии в рамках системного подхода железячников и софтверщиков. И чтобы не представать эдакими шаманами, "ловцами душ", им приходится как-то подстраиваться. Если железячники заимствуют идеи у софтверщиков с десятилетним лагом, то человечники (формальное имя этого -- human-system integration, HSI, http://ailev.livejournal.com/671112.html) отстают от тех же железячников еще на десяток лет.
Стандарт ISO 29748 хорошо это иллюстрирует: он различает по типу "спецификацию системы" и "спецификацию софта", а "спецификацию людей/организации" не различает (нужно понимать так, что она прячется где-то внутри спецификации системы). А ведь в общем случае уже общепринято, что системы состоят из тупого железа, всякого софта (включая документы и "все, что легко копировать") и людей. Три совершенно разных жизненных цикла, которые очень трудно интегрировать в одной системе.
5. Очень сложно дается понимание "вложенности" окружений:
-- внешний мир (и соглашения с ним + регулирование)
-- бизнес/менеджмент
-- проекты/"операции" (project management, который вовсе не "менеджмент" в смысле "управления", а из той же серии, что configuration management или risk management. Знаю, знаю, что эти "проектные управленцы", а не "управляющие проектами" о себе думают -- это я называю "проектный шовинизм", того же сорта явление, что и "процессный шовинизм" управленцев качеством с их quality management как "качественным управлением" вместо "управления качеством")
-- техническая суть дела, собственно выполнение преобразований мира для получения целевой системы или услуги.
Эта схема базовая для ISO 15288, но уже не воспринимается как "та же самая" в чуть-чуть измененом изложении ISO 29148. И вообще не воспринимается как базовая, основная, главная. А ведь это как раз описание связи менеджеров и инженеров, мира бизнеса и технического мира.