Системная инженерия: как скрестить ISO 15288 и system family engineering
Ежели поглядеть на ISO 15288, то сразу видно, что он описывает жизненный цикл одной системы. В жизни же обычно встречается плавный переход от работы над одной системой к работе над другой системой, и полномасштабное использование опыта, знаний, кусков проекта предыдущей системы для работы над системой новой. В итоге "жизненный цикл системы" в реальности существеннейшим образом отличается от нарисованного воображением "жизненного цикла одинокой сферической системы в вакууме", когда мы сначала ищем стейкхолдеров, затем отбираем у них требования, затем их анализируем, затем соображаем, какая будет архитектура системы -- все так, но к началу работы над конкретной системы часто и стейкхолдеры известны много лет, и требования были тщательно проанализированы давным-давно, и архитектура уже не меняется, а все сводится к добавлению пары-тройки требований к их огромному массиву и внесению не слишком значительных (по сравнению с начальным проектированием) изменений в проект. В жизни происходит system family engineering (product family engineering, domain engineering, software product line, variability modeling, variant management etc., http://ailev.livejournal.com/616338.html). И возникает потребность говорить на эти темы по-русски (http://ailev.livejournal.com/617255.html), а также привязки ISO 15288 к реалиям такой жизни, когда "от понятия "ТЗ" [те же требования в совокупе] в связи с "выращиваемыми" или "наращиваемыми" системами придется отказаться. Давно уже только bug reports и feature requests остались" (http://ailev.livejournal.com/625474.html).
Фиксируем решение:
1. Переводить system family engineering и т.д. не будем. Термин остается тот же -- "системная инженерия" (просто считаем, что другой системной инженерии, кроме как для варианта семейств систем, не бывает). Целевая система так и остается просто "системой", только понимается теперь либо как класс, либо как конкретная система (при этом мы опираемся на онтологию, подход и терминологию в http://ailev.livejournal.com/611354.html, где мы пытались переводить куски онтологии Gellish).
2. Называем три минимально необходимых для обсуждения проблем system family engineering класса систем:
-- конкретная система (основная "целевая система", например Электростанция на даче X, Буксир "Отважный Y", Процессы проектного управления предприятия Z).
-- технологическая платформа -- общее знание о серии конкретных систем (то есть технологическая платформа это класс систем -- Трехлопастные ветроэлектростанции 1КВт, Буксиры-кантовщики проекта 1234, Процессы PMBoK. Поелику класс, то для названия технологической платформы используем множественное число).
-- отрасль/предметная область (domain) -- знание об общем в серии технологических платформ (то есть отрасль.предметная область это класс технологических платформ -- ветряки, буксиры, процессы проектного управления).
3. Эти три (находящихся друг с другом в отношениях конкретизации в одну сторону и классификации в другую сторону) системы проходят каждая свой класс жизненного цикла:
-- реализация конкретной системы
-- эволюция технической платформы (внесение изменений в технологическую платформу по мере прохождения реализаций конкретных систем)
-- развитие отрасли/предметной области (смена технологических платформ по мере исчерпания их эволюционного потенциала).
4. ISO 15288 используется для всех трех пар систем/ЖЦ, но стадии разных ЖЦ разных систем нельзя перемешивать, каждый раз нужно явно указывать о какой именно системе (и ее ЖЦ) идет речь. Именно поэтому все системы и ЖЦ поименованы по-разному (собственно, такой подход вполне в традиции ISO 15288, который различает также целевую, обеспечивающие системы, и системы в операционном окружении). Итак: нет просто "ЖЦ" и просто "системы", кроме как в тексте самого стандарта ISO 15288! В жизни всегда есть только "такой-то ЖЦ" и "такая-то система" (например, реализация Электростанции на даче X, эволюция трехлопастных ветроэлектростанций 1КВт, развитие ветряков).
5. Обязательные 25 процессов системной инженерии модифицируются для каждого из трех типов систем (более того -- еще и для каждой стадии жизненного их цикла!). Так, процесс "управление конфигурацией" в случае реализации конкретной системы работает как "управление версиями" (отслеживание изменений в проекте конкретной системы), в случае эволюции -- как "управление вариантами" (отслеживание изменений в технологической платформе -- общих для всей серии конкретных систем требованиях, архитектуре, дизайне, технологических инструкциях и т.д.). От этого "управление конфигурацией" не перестает быть одним из обязательных 25 процессов системной инженерии, меняется только целевая система, для которой работает этот процесс, а также технологии и обосновывающие их теории, используемые для выполнения требований процесса "управление конфигурацией" ISO 15288.
Фиксируем решение:
1. Переводить system family engineering и т.д. не будем. Термин остается тот же -- "системная инженерия" (просто считаем, что другой системной инженерии, кроме как для варианта семейств систем, не бывает). Целевая система так и остается просто "системой", только понимается теперь либо как класс, либо как конкретная система (при этом мы опираемся на онтологию, подход и терминологию в http://ailev.livejournal.com/611354.html, где мы пытались переводить куски онтологии Gellish).
2. Называем три минимально необходимых для обсуждения проблем system family engineering класса систем:
-- конкретная система (основная "целевая система", например Электростанция на даче X, Буксир "Отважный Y", Процессы проектного управления предприятия Z).
-- технологическая платформа -- общее знание о серии конкретных систем (то есть технологическая платформа это класс систем -- Трехлопастные ветроэлектростанции 1КВт, Буксиры-кантовщики проекта 1234, Процессы PMBoK. Поелику класс, то для названия технологической платформы используем множественное число).
-- отрасль/предметная область (domain) -- знание об общем в серии технологических платформ (то есть отрасль.предметная область это класс технологических платформ -- ветряки, буксиры, процессы проектного управления).
3. Эти три (находящихся друг с другом в отношениях конкретизации в одну сторону и классификации в другую сторону) системы проходят каждая свой класс жизненного цикла:
-- реализация конкретной системы
-- эволюция технической платформы (внесение изменений в технологическую платформу по мере прохождения реализаций конкретных систем)
-- развитие отрасли/предметной области (смена технологических платформ по мере исчерпания их эволюционного потенциала).
4. ISO 15288 используется для всех трех пар систем/ЖЦ, но стадии разных ЖЦ разных систем нельзя перемешивать, каждый раз нужно явно указывать о какой именно системе (и ее ЖЦ) идет речь. Именно поэтому все системы и ЖЦ поименованы по-разному (собственно, такой подход вполне в традиции ISO 15288, который различает также целевую, обеспечивающие системы, и системы в операционном окружении). Итак: нет просто "ЖЦ" и просто "системы", кроме как в тексте самого стандарта ISO 15288! В жизни всегда есть только "такой-то ЖЦ" и "такая-то система" (например, реализация Электростанции на даче X, эволюция трехлопастных ветроэлектростанций 1КВт, развитие ветряков).
5. Обязательные 25 процессов системной инженерии модифицируются для каждого из трех типов систем (более того -- еще и для каждой стадии жизненного их цикла!). Так, процесс "управление конфигурацией" в случае реализации конкретной системы работает как "управление версиями" (отслеживание изменений в проекте конкретной системы), в случае эволюции -- как "управление вариантами" (отслеживание изменений в технологической платформе -- общих для всей серии конкретных систем требованиях, архитектуре, дизайне, технологических инструкциях и т.д.). От этого "управление конфигурацией" не перестает быть одним из обязательных 25 процессов системной инженерии, меняется только целевая система, для которой работает этот процесс, а также технологии и обосновывающие их теории, используемые для выполнения требований процесса "управление конфигурацией" ISO 15288.