Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Стек методов системной инженерии

Стек методов системной инженерии необъятен, и требуется разделение труда и сбор довольно разношерстной команды, чтобы получить в одном проекте необходимый набор компетенций. Если за исходную точку брать ISO 15288 "Системная и программная инженерия -- практики жизненного цикла системы", то сразу обнаруживается его абсолютная неконкретность и абстрактность, и в то же время редкое свойство масштабируемости в силу рекурсивного (к разным уровням подсистем) и итеративного (в разные моменты времени) применения. Абстрактность является и самым сильным местом этого стандарта, и самым слабым -- например, стандарт предписывает вам заниматься архитектурным проектированием (а не каким-то другим: от вас требуют использовать логическую и физическую архитектуру), но совершенно не объясняет, как именно вы должны эту архитектуру получить.

Можно использовать ISO 15288 непосредственно: любое дело делать "как придется", но сверяться с ISO 15288 -- чтобы чего-нибудь не забыть сверхважное. ISO 15288 в этом плане представляет собой метод (практику) системной инженерии, но очень нечетко определяет содержание входящих подметодов/практик/дисциплин -- не говоря уже о том, что крайне мало содержит указаний на то, как связаны эти составляющие его практики между собой и как они должны применяться в развертке во времени жизненного цикла. Это означает, что непосредственное использование ISO 15288 практически бесполезно -- у вас указано, что для борща обязательно использовать овощи и жидкость, но вот какие именно овощи, и вода эта жидкость или бульон -- это предполагается, что вы уже знаете. Пользуясь этим стандартом, вы не получите сухой борщ, или бульон с яйцом -- требование воды и овощей вас от этого избавит. Но вот упаренную гороховую кашу вы вполне получите, в полном соответствии со стандартом. Нужно конкретизировать.

Можно использовать двух, трех или даже трехуровнево (описано в приложении A из ISO 19760), причем варьируя набор уточняющих стандартов для каждой стадии жизненного цикла:
-- на первом уровне сам ISO 15288
-- на втором уровне детали уровня мероприятий ISO 15288 из какого-то другого, более подробного стандарта
-- на третьем уровне детали уровня дел из какого-то еще более подробного стандарта.

Я предлагаю использовать ISO 15288 в рамках ситуационной инженерии методов:

I. Общеметодический уровень: для всех систем и всех стадий жизненного цикла

1. ISO 15288, как набор практик (чтобы не забыть о том, каков более-менее полный набор практик системной инженерии, и чтобы получить основу для совмещения между собой всех остальных практик, а также задать общий язык).
2. общеметодические стандарты, раскрывающие выполнение отдельных практик. Например, MFESA для архитектурного проектирования. ICM для описания жизненного цикла. P2M для проектного управления. Моделеориентированная инженерия требований (model-driven requirements engineering), которая второго поколения, а не первого.

Основная мысль этих стандартов в том, что не бывает "универсального архитектурного метода", или "универсального жизненного цикла" -- в каждом конкретном случае нам нужно подгонять набор выполняемых инженерных деятельностей под условия конкретной ситуации: типа системы, жизненного цикла, инструментальной инфраструктуры. С другой стороны -- как именно подгонять под конкретные условия, и какой из многочисленных понятийных аппаратов конкретной предметной области задействовать, на этом уровне раскрывается в форме, специально подготовленной к уточнению по ситуации.

Тут еще вполне применим термин "практика", или "дисциплина" как тематический набор практик (дисциплина инженерии требований, практика архитектурного проектирования и т.д.). MFESA явно говорит о best practices в своем составе.

Это как раз уровень, на котором хотелось бы удержать PraxOS.

II. Ситуационный уровень: для отдельных типов систем и отдельных стадий жизненного цикла
-- учет природы целевой системы (так, для разработки архитектуры организации, железки и софта нужны разные архитектурные методы, хотя в любом случае это архитектурные методы, а не методы инженерии требований или методы проектной работы -- предметная специфичность удерживается)
-- учет стадии жизненного цикла (так, архитектурная работа на стадии разработки и архитектурная работа на стадии техобслуживания и ремонтов требует использования разных методов, постановки совершенно разных целей)
-- привязка к конкретным приемам работы и связанной с ними инструментальной инфраструктуре (методы и инструменты неразделимы). Например, уточнить требования MFESA для DSM -- design structure matrix, чтобы поднять модульность. И обязательно привязаться к инструменту (как выполнять DSM с использованием имеющегося софта).

Тут уже более приложимо слово "метод", чем практика. Хотя это все игра словами: текущее словоупотребление еще совершенно не устоялось в ситуативной (или ситуационной? LingvoScience выдает оба слова через запятую как переводы situational) инженерии методов.

Общеметодическая часть -- это требование быть хоть как-то образованным системным инженером/менеджером (например, отличать архитектурную деятельность и деятельность по инженерии требований, а также владеть специфической терминологией и понимать место этих деятельностей в общем контексте всех необходимых работ. Или понимать основные принципы управления информацией. И все это в объеме, достаточном для поддержания профессионального разговора со специалистами в этих узких областях).

Это огромная учебная проблема: минимальные прикидки показывают, что по каждой из 25 основных практик человек должен освоить (то есть хотя бы поддержать разговор) сто страниц плотно набитого идеями текста -- итого 2500 страниц.

Я делю сейчас людей на три категории:
-- не в состоянии поддержать разговор о методе (постоянно переспрашивает термины, не понимает смысла сказанного)
-- поддерживает разговор о методе ("читал" -- т.е. понимает смысл сказанного и знает слова, но путается в предмете при разборе конкретных ситуаций)
-- разбирается в методе (в достаточной мере, чтобы использовать метод в текущей работе)

Я считаю, что уровень "поддержки разговора" -- это как раз и есть общеметодическая часть. 2500 страниц вдумчивого чтения хорошо структурированной литературы (учебников, стандартов, "наборов методов"), и вы будете поддерживать разговор о системной инженерии.

А потом заранее неизвестное число страниц заранее непонятной литературы, участия в непонятном числе проектов и неструктурированного общения, чтобы перейти на уровень "разбирается". Как я понимаю, ситуативная инженерия методов пытается отвечать как раз на этот вопрос: как минимизировать затраты ума, нервов и денег на перетаскивание структурированного знанияе общеметодического уровня на более низкий ситуационный уровень, не потеряв его полноты и структуры. Другими словами, как из "поддерживающих разговор о методе" сделать "разбирающихся в методе".

Про всего два уровня абстракции я, конечно, сверхобобщил. Все много, много хуже.

Пока же ситуация такова, что даже при двухуровневой структуре я забежал далеко-далеко вперед: если вокруг только те, кто не в состоянии поддержать разговор о методе, то ситуативную инженерию методов применять еще слишком рано: "Какое такое архитектурное проектирование, которое мы тут должны адаптировать к ситуации нашей целевой системы, этапа жизненного цикла проекта и наличествующих инструментов?! Вы о чем? Садитесь, и проектируйте -- если не понимаете, как, поглядите в ГОСТЫ 1953 года издания, или посмотрите, как работают наши пенсионеры"...

Как это все отмоделировать хотя бы в том же EPF Composer, это отдельная задача: для ситуативного моделирования методов это хороший инструмент, но для общеметодической работы не слишком. Впрочем, тут и специальные LMS тоже могут оказаться бесполезными -- но мне они с инструментарием ситуативной инженерии методов представляются родственниками. В частности, в LMS популярна метафора музыкального сервиса -- альбомы, жанры, треки, плей-листы. Это очень напоминает то, что делает EPF Composer: у вас есть 1100 исходных треков (это не с потолка, это число фрагментов методов в репозитории методов http://ofpro.org), вам нужно сделать плейлист этих методов для вашего проекта, причем как диджею (синхронизируя треки друг с другом, сочиняя и тут же записывая собственные треки прямо в плейлист, подпевая солистам и непрерывно меняя плейлист для учета настроения тех, кто потом будет его играть-слушать).
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 1 comment