Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

В глоссарий системной инженерии

Все эти термины я когда-то уже описывал, но по заявкам трудящихся я сделаю еще несколько гнезд глоссария "с нуля".

Артефакт (artifact) -- что-то (оборудование, знаковые системы, сервисы или обрабатываемые материалы), что сделано в ходе выполнения проекта или процесса. Из артефактов особо выделяют продукты (продукт -- артефакт, который произведен, измерим, и может быть либо конечным объектом сам по себе, либо объектом-компонентом. Product -- an artifact that is produced, is quantifiable, and can be either an end item in itself or a component item. PMBOK® Guide, v.4. Есть множество аналогичных определений и для процессного управления: продукт работы -- артефакт, ассоциирующийся с выполнением процесса, ISO/IEC 15504-1:2004 Информационные технологии -- Оценка процессов -- Часть 1: Концепции и словарь, 3.55. work product. -- an artifact associated with the execution of a process (ISO/IEC 15504-1:2004 Information technology -- Process assessment -- Part 1: Concepts and vocabulary, 3.55). Очень важно отметить, что есть артефакты, продуктами не являющиеся: они производятся для того, чтобы смочь произвести продукты, но никак не входят в состав комплекта поставки. Это руководства, планы, протоколы испытаний, модели и т.д. Иногда никакого различия между продуктами и прочими артефактами не делают, и в тексте тогда не остается слова артефакт вообще: продуктами называется все то, что сделано, независимо от конечного назначения.

Впрочем, так подробно с иностранными цитированиями для сверки, наверное, не нужно. Поэтому дальше буду писать по-русски. С цитированиями, наверное, это будет в следующем году, ежели начнем переводить стандарт Глоссария системной инженерии (а пока прошу всех сюда: http://pascal.computer.org/sev_display/index.action).

Валидация -- это определение того, насколько система соответствует требованиям заинтересованных сторон. В ISO 15288:2008 различают требования заинтересованных сторон (что хотят заинтересованные стороны от системы, в этот момент еще не определена, какова же будет система. Например, "хотим быстро перемещаться между точками А и Б") и требования к системе (иногда также называемые "определение системы", systems definition -- определение границ системы, еще без того, чтобы определить логическую архитектуру системы. Например, "система будет -- самолет с вертикальным взлетом"). Эти разные виды требований нельзя путать:
-- требования заинтересованных сторон порождаются в результате выполнения практики выявления требований заинтересованных сторон и их выполнение проверяется в ходе применения практики валидации.
-- требования к системе порождаются в результате выполнения практики анализа требований и их выполнение проверяется в ходе применения практики верификации.
Верификацию и валидацию вместе (напомним, тематическое объединение практик называют "дисциплиной") иногда называют квалификацией Практики определения требований заинтересованных сторон и анализ требований вместе называют дисциплиной инженерии требований.
Описанные соответствия практик иллюстрируют V-диаграммой (от названия буквы V, на левой дисциплину инженерии требований, а на правой практики квалификации. В V-диаграмму иногда включают еще и такое рассмотрение: соответствие архитектурному описанию проверяется в ходе применения практики интеграции. Поэтому иногда архитектурное описание тоже относят к виду требований ("требования архитектуры").

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

Верификация -- проверка системы на соответствие требованиям к системе. Подробности см. в "валидация".

Мета-модель -- набор понятий и связей между ними, в терминах которых строится модель системы, другими словами "модель модели". Мета-модели стали популярны в системной инженерии. Например, есть ряд стандартов, определяющих метамодели для моделей, строящихся в ходе инженерии жизненного цикла проекта:
-- метамодель инженерии программного и системного процесса OMG SPEM 2.0 -- Software and Systems Process Engineering Metamodel. Нужно учесть, что "программный процесс" и "системный процесс" являются синонимами процессов жизненного цикла проекта),
-- программная инженерия -- метамодель для разработки методологий ISO/IEC 24744:2007 Software Engineering -- Metamodel for Development Methodologies. Опять же, методология в этом стандарте определяется как набор методов, а из применения методов создается процесс (развертка применений методов во времени), который воплощается в жизнь в ходе жизненного цикла проекта.

Жизненный цикл проекта -- тот отрезок полного жизненного цикла системы (от замысла до исчезновения системы), который попадает во временнЫе рамки проекта.

Описатель -- по словарю синонимов: атрибут, свойство, характеристика, спецификатор, классификатор. Русско-английский словарь дает переводы: attribute, declarative, descriptor, handle, qualifier, specificator. Например, описатели (attributes) практики согласно ISO/IEC TR 24774 -- это название, назначение, результаты и состав (мероприятия и дела).

Проект -- планируемые и выполняемые согласно планам и контролируемые работы, проходящие на каком-то участке жизненного цикла конкретной системы. Проекту соответствует особая группа описаний, хорошо приспособленная для планирования ресурсов (логистики, определения потоков материалов, работ, финансов) и управленческого контроля. Другая группа описаний, которая меньше приспособлена для планирования ресурсов и потоков материалов и финансов -- это процессная (с другой стороны, в процессной группе описаний хорошо описывается типовая часть множества однотипных проектов, а также сам процесс преобразования материалов путем выполнения над ними отдельных операций). Проектные и процессные описания объединяются в рамках описаний жизненного цикла, в которых признается важность и тех и других. Тем не менее, чтобы подчеркнуть внимание системной инженерии не только к технологической (правильная последовательность операций, каждая из которых заключается из применения метода в правильный момент жизненного цикла системы) группе описаний, но и к управленческой (вопросы планирования ресурсов, контроль хода работ и т.д.) группе описаний, в ISO 15288:2008 говорится: "в настоящем Стандарте в качестве контекста для описания практик, связанных с планированием, исполнением, оценкой и контролем, выбран проект". А вот управленцы качества для всего того же выбирают "процесс": их много меньше волнует "уложиться в график и в бюджет", и много больше волнует "все сделать по правильным технологиям в правильной последовательности, чтобы получить правильный результат". Классическое определение проекта из американского PMI PMBoK вряд ли интересно в силу уже полной замыленности. Приведем для разнообразия не менее важное и распространенное, но в силу языковых и страновых особенностей чуть менее известное определение проекта из японского стандарта управления проектами P2M (обязательного, например, для всех финансируемых японским правительством инженерных проектов --http://www.pmprofy.ru/files/756/p2m.pdf): Понятие "Проект" означает работу по созданию ценности, базирующуюся на отдельной миссии, которая выполняется в определенное или согласованное время и с ограничениями, включающими ресурсы и внешние обстоятельства (A project refers to a value creation undertaking based on a specific mission, which is completed in a given or agreed time frame and under constraints, including resources and external circumstances).

Типовой -- ср. "дома типового проекта", "типовой договор", "типовой устав", "типовые правила" и прочие специфические русскоязычные сочетания. В английском языке тут используется reference -- reference design будет "типовой проект", reference process framework -- типовой набор практик. Обычно слово "типовой" означает, что будет проводиться какая-то адаптация по месту, так что не рекомендуем переводить reference как "эталонный", что также означает общий образец, но не указывает на возможность этот образец менять в соответствии с требованиями момента.

Требование -- очень многозначное понятие, омоним.
1. какая-то возможность или условие, которое необходимо пользователю для решения своей задачи;
2. какая-то возможность, которую необходимо иметь системе, или условие, которому она должна удовлетворить для того, чтобы соответствовать соглашению, стандарту, спецификации или другой формально приложимой документированной норме, идущей от какого-то заинтересованного лица;
3. описание, соответствующее 1. или 2.
Определение из проекта стандарта инженерии требований ISO 29148 повторяет определение из IEEE 12200-2005 (перештампованному затем как ISO 26702:2007): требование -- это утверждение, которое указывает на эксплуатационные, функциональные или проектные характеристики или ограничения, каковые однозначны, проверяемы или измеряемы, и необходимы для приемки (потребителями или согласно наставлениям службы обеспечения качества) продукта или процесса (requirement: A statement that identifies a product or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance guidelines).
Требований огромное число видов: требования заинтересованных сторон, требования к системе, требования проекта, функциональные и нефункциональные требования, интерфейсные требования, нетехнические требования и т.д. Требования бывают одиночными, а также собираются в совокупности -- спецификации. Есть многочисленные требования к тому, каковы должны быть требования, и что с ними нужно делать. Получением требований занимается дисциплина инженерии требований, а проверкой выполнения требований -- дисциплина квалификации.

Форма жизненного цикла -- определяемый по согласованию инженеров и менеджеров способ получения необходимых функций системы (ISO 15288 относит определение формы жизненного цикла к менеджерской группе описаний ЖЦ):
-- последовательная, когда сразу все функции системы получаются после выполнения всей последовательности стадий замысла, разработки и изготовления системы.
-- инкрементальная, когда функции системы постепенно порциями (инкрементами) добавляются с каждой новой версией системы, пока система не выйдет на заранее оговоренный полный набор функций. Это означает, что стадия ввода в эксплуатацию повторяется для каждой версии системы.
-- эволюционная, это аналогично инкрементальной форме жизненного цикла, только при выпуске первых версий нет понимания, какой будет окончательный набор функций системы.
Форма жизненного цикла как термин вводится в проекте ISO 24748-1: "Организации по-разному применяют стадии для реализации различных деловых стратегий и стратегий снижения рисков. Одновременное или, в редких случаях, даже в другом порядке применение стадий приводит к формам жизненного цикла с ясно различающимися характеристиками. Часто применяются последовательная, инкрементальная и эволюционная формы жизненного цикла. Кроме того, может быть выработано подходящее сочетание данных форм". Смысл сказанного раскрывается подробнее в ISO 19760, но про то же самое говорится "подходы (approaches) к жизненному циклу": Организационная группа описаний иллюстрирует последовательный, инкрементальный и эволюционный подходы. ... Как альтернатива, может быть выработан подходящий смешанный подход, включающий элементы данных подходов". Далее в разделе 7.2 приводятся более-менее подробные описания того, как проходит жизненный цикл при последовательной, инкрементальной и эволюционной его форме (в терминологии "подход к жизненному циклу").
* * *
Тут я бы написал, что мне самому очень хотелось бы считать, что термин "форма жизненного цикла" не занят (и раскопки в интернете, скорее это подтверждают, чем опровергают), и я бы с удовольствием вернулся от определения этой формы "по стандартам" (особенно с учетом того, что в ISO 15288 этот термин вообще не встречается) к данному мной еще в мае 2009г. определению: http://ailev.livejournal.com/688971.html. Возможно, я бы дал сейчас и такое определение: "форма жизненного цикла -- это то, что отображается на горбатой диаграмме как разметка на оси времени". То есть "форма жизненного цикла -- это разметка стадий и контрольных точек/пересмотров выделения ресурсов жизненного цикла во времени".

Но тут я бы наступил пока на горло собственной песне и подумал еще (в том числе и потому, что есть и такая традиция понимания самого термина "жизненный цикл", в котором он всегда не конкретный, а типовой, а конкретны лишь соответствующие его каким-то периодам проекты. И с этим нужно еще разобраться: там "жизненным циклом" или "описанием/моделью жизненного цикла" называется как раз то, что я хотел бы назвать "формой" (стадии, контрольные точки, пересмотры выделения ресурсов, состояние системы к концу стадии, отстраиваясь от технической группы описаний -- мероприятий по применению главным образом технических практик в те или иные моменты времени. Я хочу одномерную горбатую диаграмму, в которой нет измерения дисциплин, а указана только стадийность -- и такая диаграмма как раз и характеризовала бы "форму". Но ISO 15288 норовит именно это назвать описанием (model) жизненного цикла, игнорируя тот факт, что в практике описывания жизненного цикла требуется описывать и дисциплины, и их применения в нужные моменты времени, и описывать (вернее, выбирать) форму жизненного цикла. Можно было бы отказаться от термина "форма ЖЦ" вообще и говорить о типах/видах (или даже моделях, отчаянно вляпываясь в омонимию типа "модель автомобиля масштаба 1:9" и "автомобиль ВАЗ модели 2109"), а то и "подходах", как это предлагает ISO 19760. Нужно разобраться, но я думаю, что это целесообразно делать только в рамках общего разбирательства с описаниями жизненного цикла, которые должны будут отражать и форму, и "подходы", и все-все-все про эти жизненный циклы. А это описание жизненного цикла, очевидно, нужно рассматривать с точки зрения его использования разными заинтересованными сторонами. Это использование происходит в рамках ситуативной инженерии методов, которая без упоминания этого термина хорошо описана в самом стандарте -- сам стандарт адаптируется, с ним совместно используются другие стандарты с типовыми наборами практик для разных типов систем, затем выбирается необходимое описание/форма жизненного цикла и эти практики расписываются (путем обеспечения всех необходимых инструкций) для применения в конкретных периодах этого жизненного цикла.

Так что ждем-с набора опыта моделирования ЖЦ, эксперименты в самом разгаре.

Для самых любопытных приведу еще один термин:

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

Разбирательство с тем, "форма разработки" это, или "подход к разработке" или еще что -- тоже после окончания какого-то разбирательства с моделированием ЖЦ. То есть к середине декабря.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 6 comments