Методология информационного моделирования: различия между версиями

Материал из Свод знаний по информационному моделированию
Перейти к навигации Перейти к поиску
(Добавлены разделы: Территориальное моделирование, Проектное моделирование, Строительное моделирование, и подразделы: Формирование Концептуальной модели, Формирование Проектной модели, Формирование Строительной модели)
 
(не показано 9 промежуточных версий 2 участников)
Строка 7: Строка 7:
 
Информационное моделирование - это в первую очередь управление информацией, которое начинается с комплексное управление проектом.
  
Информационное моделирование - это в первую очередь управление информацией, которое начинается с комплексное управление проектом.
 
=== Базовая методология управления информацией ===
  
=== Базовая методология управления информацией ===
−
В основе применения технологий информационного моделирования лежит методология Lean SIX SIGMA (Leaner)<ref>Leaner Six Sigma: Making Lean Six Sigma Easier and Adaptable to Current Workplaces {{cite book | vauthors=((Stern, T. V.)) | date= 2019 | title=Leaner Six Sigma: Making Lean Six Sigma Easier and Adaptable to Current Workplaces | publisher=Routledge, Taylor & Francis Group | doi=10.4324/9780429425967 | isbn=978-1-138-38792-8}}
 +
В основе применения технологий информационного моделирования лежит методология Lean SIX SIGMA. Подробнее с этими методологиями можно познакомиться на отдельной странице [[Six sigma|Шесть сигм]]
−
</ref>. Шесть Сигм - это философия и методология совершенствования всех процессов в вашей организации. Двумя основными подходами и методологиями являются '''DMAIC (DEFINE-MEASURE-ANALYZE- IMPROVE-CONTROL)''' и '''DFSS (DESIGN FOR SIX SIGMA)'''.
  
−
DMAIC предназначен для непрерывного и постепенного улучшения процессов. DFSS фокусируется на существенном перепроектировании продукта или процесса, а также на разработке нового продукта или процесса с целью достижения бездефектного или шестигранного уровня качества.
  
−
<br>
  
−  
−
Методологическая модель DMAIC включает следующие фазы:
  
−
# Define - Определять
  
−
# Measure - Измерять
  
−
# Analyze - Анализировать
  
−
# Improve - Улучшать
  
−
# Control - Контролировать
  
−
<br>
  
−  
−
Методологическая модель DFSS включает в себя множество методологий, которые могут быть сопоставлены с методологической моделью DMAIC следующим образом:
  
−
{| class="wikitable"
  
−
|+ Сравнение методологических моделей SIX SIGMA
  
−
|-
  
−
! DMAIC !! DFSS !! DFSS !! DFSS !! DFSS
  
−
|-
  
−
! DMAIC !! DMADV !! DMADOV !! DMEDI !! IDOV
  
−
|-
  
−
| Define || Define || Define || Define || Identify
  
−
|-
  
−
| Measure || Measure || Measure || Measure ||
 
−
|-
  
−
| Analyze || Analyze || Analyze || Explore<sup>*</sup> || Design
  
−
|-
  
−
| Improve || Design || Design || Develop ||
 
−
|-
  
−
| || || Optimize || || Optimize
  
−
|-
  
−
| || Verify<sup>**</sup> || Verify<sup>**</sup> || Implement || Validate<sup>***</sup>
  
−
|-
  
−
| Control || || || ||
 
−
|}
  
−
<br>
  
 
Рассмотрим подробнее данные методологические подходы в контексте применения технологий информационного моделирования.
  
Рассмотрим подробнее данные методологические подходы в контексте применения технологий информационного моделирования.
   
Строка 103: Строка 68:
   
 
=== Управление информацией и информационное моделирование ===
  
=== Управление информацией и информационное моделирование ===
−
Безусловно неотъемлемой частью информационного моделирования в современном мире является управление знаниями. Онтология является одним из инструментов управления знаниями. В качестве основы будем использовать наработки по онтологии стандартов ISO15926: [https://15926.org/topics/ontologies/ Онтология]
 +
Безусловно неотъемлемой частью информационного моделирования в современном мире является управление знаниями. Онтология является одним из инструментов управления знаниями. В качестве основы будем использовать наработки по онтологии стандартов ISO15926: [https://15926.org/topics/ontologies/ Онтология]. Более подробно об описании подходов к формированию онтологии гражданского строительства можно посмотреть в разделе [[Методология разработки онтологии строительной отрасли|Онтология]] настоящего портала.
  +
  +
=== Методология управления конфигурацией в рамках информационного моделирования ===
  +
Методология управления конфигурацией в рамках применения технологий информационного моделирования основывается на положениях национального стандарта [https://docs.cntd.ru/document/1200177489 ГОСТ Р 59193-2020 "УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ. Основные положения"].
  +
  +
  +
=== Управление требованиями в рамках информационного моделирования ===
  +
Методология управления требованиями в рамках применения технологий информационного моделирования основывается на положениях национального стандарта [https://docs.cntd.ru/document/573219705 ГОСТ Р 59194— 2020 "УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ. Основные положения"], а также международных стандартов [https://standards.ieee.org/ieee/1220/3372/ IEEE 1220-2005 "Standard for Application and Management of the Systems Engineering Process"]
  +
  +
В рамках настоящей методологии уточним понятия, определенные в национальном стандарте:
  +
{| class="wikitable"
  +
|+ Термины и определения методологии управления требованиями информационного моделирования
  +
|-
  +
! Термин !! Сокращение !! Определение !! Источник
  +
|-
  +
| Заинтересованная сторона || ЗС || Физическое лицо или организация (подразделение организации), которое(ая) выполняет по отношению к объекту какую-либо роль и, в связи с этим, имеет потребности (интересы, ожидания), связанные с объектом || п. 3.1.19 ГОСТ Р 59194—2020
  +
|-
  +
| Потребность (заинтересованной стороны) || Потребность || Оформленные или озвученные заинтересованной стороной интересы и ожидания, связанные с объектом моделирования ||
  +
|-
  +
| Исходное (заданное) требование || ИсхТ || Требование, полученное в результате анализа потребностей заинтересованной стороны || п. 3.1.11 ГОСТ Р 59194—2020
  +
|-
  +
| Ограничение || Огр || Составная часть требования или самостоятельное требование, описывающее внешнее ограничивающее условие (связанное с внешними по отношению к объекту воздействующими факторами), наложенное на объект, его конструкцию, процесс разработки, изготовления, эксплуатации, ремонта или утилизации || п. 3.1.14 ГОСТ Р 59194—2020
  +
|-
  +
| Проектное (системное) требование || ПТ || Требование, полученное в результате анализа и декомпозиции исходных требований, а также в результате деятельности по проектированию и конструированию || п. 3.1.15 ГОСТ Р 59194—2020
  +
|-
  +
| Прослеживаемость требования || ПрТ || Свойство требования, указывающее на возможность проследить источник (источники) требования (потребность заинтересованной стороны, исходное или проектное требование, принятое техническое решение) или отследить все дочерние требования || п. 3.1.16 ГОСТ Р 59194—2020
  +
|-
  +
| Текст ячейки || Текст ячейки || Текст ячейки
  +
|-
  +
| Текст ячейки || Текст ячейки || Текст ячейки
  +
|-
  +
| Текст ячейки || Текст ячейки || Текст ячейки
  +
|-
  +
| Текст ячейки || Текст ячейки || Текст ячейки
  +
  +
|}
  +
  +
Потребности заинтересованной стороны затем преобразуются в требования.
  +
Заинтересованной стороной может быть (перечень не полный и может быть расширен): заказчик, головной исполнитель программы, поставщик, разработчик, головной разработчик, изготовитель, головной изготовитель, эксплуатирующая организация, надзорные и регулирующие органы, ремонтные органы и др.
  +
Одна организация может совмещать роли, выполняемые в отношении объекта, и, следовательно, выражать потребности нескольких заинтересованных сторон (разными заинтересованными сторонами могут быть разные подразделения одной организации).
  +
Заинтересованными в объекте сторонами также являются организации (заказчики, разработчики, изготовители и т. д.), имеющие отношение к объектам, взаимодействующим с рассматриваемым
  +
  +
В рамках единой системы информационного моделирования под под объектом моделирования понимается
  +
Настоящий стандарт по терминологии и составу задач в целом соответствует [1]. Соответствие терминов настоящего стандарта и терминов [1] приведено в таблице А.2.
  +
В этом пункте и далее по тексту стандарта термин «объект» используется для обозначения объекта, к которому задаются требования. Объектом может быть финальное изделие (в том числе комплекс и т. п.), СЧ (в том числе система, агрегат, сборочная единица, деталь, комплект и т. п.), программа для ЭВМ (в том числе встроенное ПО), интерфейс, материал, объекты, связанные с процессами ЖЦ.
  +
Объект, к которому задаются требования, как правило, в процедурах УК по ГОСТ Р 59193 яв- ляется ОКнф (см. 3.1.13)
  +
  +
4 Основные положения
  +
4.1 В составе УТ выделяют два вида деятельности*:
  +
- разработка требований — инженерная деятельность по выявлению, анализу, декомпозиции, проверке, согласованию и утверждению требований к изделию и его СЧ, основанная на анализе потребностей заказчика и других заинтересованных сторон;
  +
- контроль требований — управленческая деятельность, направленная на поддержание актуальности и согласованности требований к изделию и его СЧ в ходе всего ЖЦ изделия (в том числе при изменении потребностей заинтересованных сторон). Эта деятельность является частью процесса УК в соответствии с ГОСТ Р 59193, выполняемого в отношении требований.
  +
4.2 Управление требованиями осуществляют совместно заказчик и поставщик изделия.
  +
Для координации деятельности по УТ, при необходимости, разрабатывают программу УТ, в котором перечисляют решаемые задачи УТ, методы их решения (с указанием применяемых документов по стандартизации), ответственных исполнителей, способы обмена данными, планируемые результаты, взаимосвязи с процессом УК.
  +
4.3 Требования задают к изделию в целом и к его СЧ (системам, агрегатам, узлам, деталям, программам для ЭВМ, в т. ч. встроенному ПО), к документам (информационным наборам, базам дан- ных и т. п.), материалам, интерфейсам, объектам, связанным с процессами ЖЦ (далее: объекты).
  +
4.4 Требования могут быть представлены в форме*:
  +
- базы данных (совокупности информационных объектов и наборов) в автоматизированной си- стеме;
  +
- документа (бумажного или электронного по ГОСТ 2.051).
  +
Требования могут быть представлены в составе функционального ЭМИ в АС УДИ по ГОСТ Р 58301. 4.5 Все требования к одному объекту, необходимые для решения определенной задачи в ходе
  +
ЖЦ, составляют спецификацию требований к объекту*. При разработке нового объекта формируют:
  +
- спецификацию исходных (заданных) требований к объекту — для формализации потребностей всех заинтересованных сторон и создания базы для валидации объекта;
  +
- спецификациюпроектных(системных)требованийкобъекту—дляразработкиконструкторской, технологической, эксплуатационной и ремонтной документации на объект и создания базы для верификации объекта.
  +
4.6 В модели ЖЦ объекта по ГОСТ Р 56136 выделяют КР двух типов, на которых выполняется работа с требованиями:
  +
- контрольные рубежи, на которых проверяют, согласовывают и утверждают разработанные требования к объекту (в результате требованиям присваивают статус готовности);
  +
- контрольные рубежи, на которых проверяют соответствие объекта требованиям (в результате требованиям присваивают статус выполнения).
  +
Общий порядок разработки и применения требований приведен в разделе 5.
  +
  +
5 Общий порядок разработки и применения требований 5.1 Общий порядок формирования требований к объекту*
  +
5.1.1 Исходные требования к объекту получают в результате анализа:
  +
- потребностей в отношении разрабатываемого объекта всех заинтересованных сторон;
  +
- требований к объектам данного типа, заданных в документах по стандартизации.
  +
Потребности заинтересованных сторон и требования документов по стандартизации могут быть
  +
связаны с назначением и функционированием объекта, процессом его разработки, изготовления, испытаний, эксплуатации, ремонта и утилизации.
  +
В качестве потребностей заинтересованных сторон также рассматриваются требования к рассматриваемому объекту как СЧ другого объекта (см. 5.1.5).
  +
5.1.2 Для разрабатываемых объектов на основании утвержденной спецификации исходных требований разрабатывают спецификацию проектных требований, обусловленных принятыми при проектировании и в результате анализа исходных требований техническими решениями.
  +
Для неразрабатываемых объектов на базе утвержденной спецификации исходных требований выбирают ранее разработанное техническое решение или покупное комплектующее изделие.
  +
5.1.3 Проектныетребованиявключаютформализованноеописаниефункцийобъекта,технические характеристики, описание принципов и режимов работы, условий эксплуатации, характеристики взаимодействия с внешними объектами (интерфейсы) и другие необходимые для дальнейшей разработки сведения об объекте в целом и процессах его ЖЦ*.
  +
Проектные требования определяют такие характеристики объекта в целом, которые позволят обеспечить удовлетворение исходных требований, но (по возможности) не предписывают применение конкретных технических решений (если такие решения не обусловлены ограничениями, установленными в исходных требованиях).
  +
5.1.4 Проектные требования к сложному объекту являются основой для разработки архитектуры (вариантов архитектуры) объекта в ходе проектирования. На основании проектных требований к объекту в целом и выбранного варианта архитектуры объекта разрабатывают требования к СЧ объекта*.
  +
5.1.5 Требования к СЧ должны соответствовать 5.1.3. Требования к СЧ являются исходными дан- ными для формирования спецификации исходных требований к СЧ (см. 5.1.1).
  +
  +
5.2 Задание сведений для верификации и валидации объекта
  +
5.2.1 Спецификацияисходныхтребованийявляетсябазойдлявалидацииобъекта.Спецификация проектных требований является базой для верификации объекта.
  +
5.2.2 С целью подготовки к верификации и валидации объекта для каждого требования (группы требований) указывают следующие сведения:
  +
- КР в модели ЖЦ объекта, на котором должна быть выполнена проверка;
  +
- МОС на данном КР;
  +
- критерииуспешностипроверкитребованийнаКР(диапазонызначенийхарактеристик,описание
  +
вариантов правильного функционирования и т. п.);
  +
- вид (виды) ДД, в которых должны быть задокументированы результаты проверки и которые бу-
  +
дут официально подтверждать соответствие объекта требованиям.
  +
  +
Если верификация объекта выполняется на нескольких КР (одинаковыми или разными методами), то перечисленные выше сведения указывают для каждого КР.
  +
5.2.3 Применяемые МОС, виды ДД и критерии успешности проверки, а также способы задания для требований перечисленных сведений устанавливают в программе УТ или в документах по стандартизации организации.
  +
5.2.4 Утвержденная спецификация требований к объекту должна использоваться для разработки ПМИ по ГОСТ 19.301 для валидации или верификации объекта*.
  +
5.3 Проверка, согласование и утверждение требований
  +
5.3.1 Требования (каждое требование в отдельности и спецификация требований в целом) имеют свой ЖЦ, в котором выделяют стадии и события, связанные с изменением статуса готовности требований. Стадии ЖЦ требований, применяемые статусы готовности требований и события, приводящие к изменению статуса готовности, устанавливают в программе УТ или в документах по стандартизации организации*.
  +
5.3.2 По окончании разработки спецификацию требований к объекту проверяют, согласовывают и утверждают. Утверждение отдельных требований выполняют только при внесении изменений в утвержденную спецификацию. Порядок проверки, согласования и утверждения требований устанавливают в документах по стандартизации организации.
  +
5.3.3 При проверке требований выполняют их валидацию и верификацию.
  +
5.3.4 При валидации требований проверяют:
  +
- полноту покрытия спецификацией требований всех потребностей заинтересованных сторон, ис-
  +
ходных требований и/или принятых технических решений;
  +
- правильность выражения требованием потребности заинтересованной стороны, отражения
  +
принятого технического решения и/или декомпозиции родительского требования;
  +
- наличие и правильность связи с потребностью заинтересованной стороны, родительским
  +
требованием или принятым техническим решением (см. 6.2.4—6.2.6);
  +
- непротиворечивость требований в спецификации.
  +
При валидации требований используют результаты компьютерного моделирования по
  +
ГОСТ Р 57412, испытаний, опыта эксплуатации аналогов и другие методы.
  +
5.3.5 При верификации требований проверяют:
  +
- отнесение всех требований в спецификации к одному объекту;
  +
- соответствие формулировки каждого требования критериям качества, установленным в
  +
документах по стандартизации организации (см. 6.1);
  +
- соответствие спецификации требований в целом критериям качества, установленным в
  +
документах по стандартизации организации (см. 6.1);
  +
- правильность заполнения атрибутов требований, установленных в документах по стандарти-
  +
зации организации (см. 6.2);
  +
- правильность классификации требований и установления связей между требованиями и
  +
(см. 6.2);
  +
- наличиеиправильностьоформлениясведенийдляверификацииивалидацииобъекта(см.5.2). Полный перечень проверок требований устанавливают в документах по стандартизации
  +
организации.
  +
5.3.6 После успешного прохождения проверки требования (спецификацию требований в
  +
целом) утверждают. Утверждение требований выполняют с применением электронной подписи или собственноручной подписи в удостоверяющем листе или в бумажном документе, содержащем требования.
  +
5.4 Применение требований при верификации и валидации объекта
  +
5.4.1 По результатам верификации или валидации объекта требованиям присваивают статус, указывающий что требование выполнено (статус выполнения).
  +
5.4.2 С одним требованием может быть связано множество статусов выполнения, относящихся к разным КР и конфигурациям. При этом каждый статус выполнения должен содержать ссылки на КР, проверенную конфигурацию объекта, МОС, а также на утвержденный ДД (комплект ДД), на основании которого принято решении о выполнении (не выполнении) требования.
  +
5.4.3 Видыипорядокприсвоениястатусоввыполнениятребованиямустанавливаютвдокументах по стандартизации организации. Примерами значений статуса выполнения могут быть:
  +
- требование выполнено;
  +
- требование выполнено с учетом разрешения на отклонение;
  +
- требование не выполнено (или отсутствует необходимый ДД).
  +
6 Общие требования к содержанию и оформлению требований 6.1 Содержание требований и спецификации требований
  +
6.1.1 Содержание требований должно соответствовать правилам, установленным в документах по стандартизации организации.
  +
Основные правила разработки содержания требований включают:
  +
- правильно сформулированное требование может быть проверено в ходе разработки и/или при предъявлении изделия заказчику;
  +
- правильно сформулированное требование должно описывать функцию, которую изделие должно выполнять, или характеристику, которой изделие должно обладать (а не возможности, которыми должны обладать пользователи/операторы изделия);
  +
- правильно сформулированное требование должно включать (или ссылаться на) описание условий и ограничений, при которых оно имеет смысл*;
  +
- правильно сформулированное требование не должно диктовать определенное техническое решение или ограничивать диапазон таких решений (без специальной необходимости, вызванной установленными ограничениями).
  +
Основные характеристики требований, на основании которых могут быть заданы правила формулирования требований в документах по стандартизации организации, приведены в Б.1 (приложение Б).
  +
6.1.2 Для требований, выраженных текстовым утверждением, в документах по стандартизации организации должны быть установлены правила построения предложений, с указанием: рекомендуемого порядка слов, использования определенных ключевых слов и выражений (например, выражающих обязательность требования), использования определенных словоформ, перечня запрещенных для использования слов и выражений и т. п. Некоторые примеры таких правил приведены в Б.2 (приложение Б).
  +
6.1.3 Спецификациятребованийвцеломдолжнасоответствоватьтребованиям,установленнымв документах по стандартизации организации. Некоторые характеристики спецификации требований, на основании которых могут быть заданы правила формирования спецификации требований в конкретном проекте, приведены в Б.3 (приложение Б).
  +
6.2 Атрибуты требований и связи между требованиями
  +
6.2.1 Обязательные атрибуты для требований и их возможные значения (при наличии) устанавливают в документах по стандартизации организации. Некоторые примеры атрибутов требований приведены в Б.4 (приложение Б).
  +
6.2.2 Каждое требование должно быть уникально идентифицировано для обеспечения прослеживаемости в ходе разработки. Уникальный идентификатор требования не изменяется в ходе ЖЦ объекта, в том числе при внесении изменений в требование. Все изменения одного и того же требования производятся путем создания новой версии требования*.
  +
Требования к идентификатору требования и идентификатору версии требования устанавливают в документах по стандартизации организации.
  +
6.2.3 Между требованиями к одному объекту, а также между требованиями к разным (взаимосвя- занным, взаимодействующим) объектам устанавливают связи, выполняющие разные функции:
  +
- связи подчиненности, описывающие, что одно требование получено из другого (родительского) требования (путем декомпозиции или в результате деятельности по проектированию и конструированию); - связи классификации, описывающие, что требования относятся к одному типу/группе — как правило, такие связи устанавливаются путем задания классифицирующего свойства в атрибуте требования или путем установления связи со специализированным объектом (разделом, папкой в
  +
автоматизированной системе).
  +
Классификация и группирование требований могут соответствовать положениям ГОСТ 15.016,
  +
ГОСТ 19.201, ГОСТ 34.602 и т. п.
  +
6.2.4 В случае наличия документов, описывающих потребности заинтересованных сторон (например, отчет о научно-исследовательской работе), или применения документов по стандартизации при задании требований к объекту, для исходных требований должны быть установлены ссылки на эти документы (пункты документов).
  +
6.2.5 Каждое проектное требования к объекту должно быть связано с утвержденными исходным требованием к этому объекту и/или с техническим решением по объекту, принятым в ходе разработки. 6.2.6 Каждое требование к СЧ должно быть связано с утвержденным проектным требованием к
  +
объекту в целом или с техническим решением по объекту, принятыми в ходе разработки.
  +
  +
7 Контроль требований
  +
7.1 Требования являются частью документации конфигурации и подлежат контролю в процедурах УК в соответствии с ГОСТ Р 59193.
  +
7.2 Требования должны быть связаны с соответствующим объектом конфигурации и должны иметь уникальный идентификатор, присваиваемый по правилам, установленным в организации.
  +
7.3 Разработанные на КР требования подлежат проверке в рамках аудита документации конфигурации в соответствии с ГОСТ Р 59193—2020 (раздел 6).
  +
7.4 После успешного завершения аудита требования становятся частью утвержденной конфигурации объекта по ГОСТ Р 59193 Спецификацию исходных требований к объекту включают в утвержденную требуемую конфигурацию объекта. Спецификацию проектных требований к объекту включают в утвержденную проектную конфигурацию объекта.
  +
7.5 Изменение требований, включенных в утвержденную конфигурацию, производят по правилам управления изменениями, установленным в ГОСТ Р 59193—2020 (раздел 7).
  +
7.6 Под изменением требований понимают:
  +
- изменение версии требований в утвержденной спецификации требований;
  +
- удалениетребования(й)изутвержденнойспецификациитребований(сзаменойилибеззамены); - добавление новых требований в утвержденную спецификацию требований.
  +
7.7 При анализе требований и оценке вариантов изменения по ГОСТ Р 59193—2020
  +
(подраздел 7.5), а также при определении необходимости изменения всех подчиненных конфигураций используют прослеживаемость требований.
  +
7.8 Всем изменениям утвержденных требований присваивают класс изменения. Определение класса изменения требований выполняют по ГОСТ Р 59193—2020 (подраздел 7.6).
  +
7.9 В случае изменения требования с присвоенным статусом выполнения возможны следующие варианты в зависимости от класса изменения (см. 7.8):
  +
- дляизмененияпервогоклассанеобходимоповторновыполнятьпроверкуконфигурацийобъекта, для которых установлено, что требование выполнено, на соответствие измененному требованию;
  +
- дляизмененийвторогоклассанетнеобходимостивповторныхпроверкахконфигурацийобъекта, для которых установлено, что требование выполнено (все статусы выполнения переносятся на новую версию требования автоматически).
  +
Следует отличать валидацию и верификацию требований к объекту от валидации и верифи- кации самого объекта.
  +
Валидация объекта представляет собой демонстрацию заказчику того, что объект удовлетво- ряет его потребностям и соответствует исходным требованиям. Валидация исходных (заданных) требований проводится на более раннем этапе для того, чтобы удостовериться, что эти исходные требования охватывают все значимые потребности всех заинтересованных сторон и правильно их выражают (формулируют) и следование таким требованиям позволит в будущем корректно выполнить валидацию объекта.
  +
Верификация объекта заключается в проверке того, что объект разработан в соответствии с заданными требованиями. Верификация требования заключается в проверке того, что сами требования разработаны в соответствии с предъявленными к ним требованиями (требования к формулированию, оформлению, структурированию и другим характеристикам требований как объекта разработки)
  +
  +
В зависимости от стадии (этапа) ЖЦ объекта возможно применение следующих МОС (перечень может быть расширен):
  +
- анализ документации;
  +
- расчет или компьютерное моделирование;
  +
- эксперимент с образцом или физическим макетом; - анализ опыта эксплуатации прототипа;
  +
- испытания опытного образца и его СЧ;
  +
- анализ опыта эксплуатации образца
  +
  +
=== Создание единого информационного пространства проекта ===
  +
Про отличительное особенности Единого информационного пространства (ЕИП) от Среды общих данных (СОД) приведены в статье [[Статьи:_Отличие_ЕИП_и_СОД|Отличие ЕИП и СОД]]
   
 
== Информационное моделирование для управления проектом ==
  
== Информационное моделирование для управления проектом ==
Строка 110: Строка 253:
   
 
В качестве базиса для дальнейшее работы можно использовать наработки ISO 15926: [https://15926.org/topics/plant-lifecycle-model/index.htm Plant Life-cycle Model]
  
В качестве базиса для дальнейшее работы можно использовать наработки ISO 15926: [https://15926.org/topics/plant-lifecycle-model/index.htm Plant Life-cycle Model]
  +
  +
Одной из важнейших составляющих управления проектом является управление качеством.
  +
  +
=== Управление качеством с применения ТИМ ===
  +
При реализации проекта с применением технологий информационного моделирования классические подходы к управлению качеством, определенные в ISO 9000, могут быть применены в полном объеме, но на новом цифровом уровне.
  +
  +
В первую очередь необходимо уточнить понятие "дефекта"<ref>37. Дефект - Каждое отдельное несоответствие продукции установленным требованиям</ref>. В контексте информационного моделирования данное понятие приобретает более широкую трактовку, по отношению к его определению в [https://docs.cntd.ru/document/1200001719 ГОСТ 15467-79 "Управление качеством продукции. Основные понятия. Термины и определения"].
  +
Этот же стандарт определяет понятия:
  +
* 40. Дефектное изделие - Изделие, имеющее хотя бы один дефект
  +
* 41. Явный дефект - Дефект, для выявления которого в нормативной документации, обязательной для данного вида контроля, предусмотрены соответствующие правила, методы и средства
  +
* 42. Скрытый дефект - Дефект, для выявления которого в нормативной документации, обязательной для данного вида контроля, не предусмотрены соответствующие правила, методы и средства
  +
* 43. Критический дефект - Дефект, при наличии которого использование продукции по назначению практически невозможно или недопустимо
  +
* 43. Критический дефект - Дефект, при наличии которого использование продукции по назначению практически невозможно или недопустимо
  +
* 44. Значительный дефект - Дефект, который существенно влияет на использование продукции по назначению и (или) на ее долговечность, но не является критическим
  +
* 45. Малозначительный дефект - Дефект, который существенно не влияет на использование продукции по назначению и ее долговечность
  +
* 46. Устранимый дефект - Дефект, устранение которого технически возможно и экономически целесообразно
  +
* 47. Неустранимый дефект - Дефект, устранение которого технически невозможно или экономически нецелесообразно
  +
  +
Одновременно с этим в зарубежной практике в области информационного моделирования закрепилось два понятия "Clash" и "Collision", которые часто трактуются как "коллизия".
  +
  +
=== Управление рисками с примененим ТИМ ===
  +
Еще одной важной составляющей управления проектами - является управление рисками.
  +
В этом контексте необходимо обратить внимание на стандарт [https://docs.cntd.ru/document/1200089294 ГОСТ Р 54141-2010 "Менеджмент рисков. РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ОРГАНИЗАЦИОННЫХ МЕР БЕЗОПАСНОСТИ И ОЦЕНКИ РИСКОВ. Эталонные сценарии инцидентов.]
   
 
== Территориальное моделирование ==
  
== Территориальное моделирование ==
Строка 118: Строка 284:
 
Сразу необходимо оговориться, что проектное моделирование можно разделить на несколько видов моделей:
  
Сразу необходимо оговориться, что проектное моделирование можно разделить на несколько видов моделей:
 
* Концептуальную - которая обеспечивает информацией традиционные этапы ОБИН и АГР
  
* Концептуальную - которая обеспечивает информацией традиционные этапы ОБИН и АГР
−
* Инженерных изысканий - модель формируемая по результатам инженерных изысканий - соответствует традиционному этапу Инженерные изыскания - Уровень А<ref>Здесь и далее наименования моделей приведены в соответствие с СП 333.1325800.2020 Таблицей 5.1</ref>
 +
* Инженерных изысканий - модель формируемая по результатам инженерных изысканий - соответствует традиционному этапу Инженерные изыскания - Уровень А<ref>Здесь и далее наименования моделей приведены в соответствие с [https://docs.cntd.ru/document/573514520 СП 333.1325800.2020] Таблицей 5.1</ref>
 
* Проектную - соответствующую стадии "П" - соответсвует традиционному этапу "Стадия П" - Уровень В
  
* Проектную - соответствующую стадии "П" - соответсвует традиционному этапу "Стадия П" - Уровень В
 
* Строительную модель - соответствующую "РД" - Уровень С
  
* Строительную модель - соответствующую "РД" - Уровень С

Текущая версия на 20:17, 26 июля 2022

Применение технологий информационного моделирования требует методологического сопровождения. Для упрощения процесса внедрения технологии информационного моделирования на данной странице будет описана методология внедрения и непрерывного развития применения технологий информационного моделирования в производственной деятельности.

Поскольку применения технологий информационного моделирования не привязано к конкретному этапу жизненного цикла, а больше связанно организационными процессами, поэтому здесь вы найдете базовые подходы и практики.

Управление информацией

Информационное моделирование - это в первую очередь управление информацией, которое начинается с комплексное управление проектом.

Базовая методология управления информацией

В основе применения технологий информационного моделирования лежит методология Lean SIX SIGMA. Подробнее с этими методологиями можно познакомиться на отдельной странице Шесть сигм Рассмотрим подробнее данные методологические подходы в контексте применения технологий информационного моделирования.

Определять

Определение - это первая фаза модели спроса. Примеры мероприятий на этом этапе включают:

  • Определение задач, определение приоритетов и отбор возможностей
  • Определение процессов, которые необходимо улучшить, и подготовка карт процессов
  • Разработка уставов проектных групп
  • Создание эффективных команд
  • Определение клиентских сегментов и требований

Измерять

Примеры мероприятий на втором этапе модели DMAIC включают:

  • Определение параметров, подлежащих измерению
  • Управление процессом измерения
  • Понимание вариативности
  • Оценка измерительной системы и выбор измерительных приборов
  • Определение производительности процесса

На этапе Измерять учитываются факторы, имеющие решающее значение для качества (анг. Critical-to-Quality factors - CTQ). CTQ - это общепринятый термин, используемый для определения требований заказчика. Однако этот термин также используется взаимозаменяемо с Критическими для удовлетворения (анг. Critical-to-Satisfaction) и Критическими для Успеха (анг. Critical-to-Success). CTQ имеют отношение ко всей модели DMAIC. Одновременно с этим для определения потребностей заказчика используется термин Critical to Customer (CTC).

Анализировать

Примеры мероприятий на третьем этапе процесса DMAIC включают:

  • Выявление потенциальных первопричин
  • Внедрение альтернативных методов
  • Проведение исследований источников вариаций
  • Проведение корреляционного анализа

Фаза Анализировать имеет решающее значение для результата. На этом этапе используются многие аналитические инструменты решения проблем.

Улучшать

Примеры четвертой фазы модели DMAIC включают:

  • Создание решений
  • Определение альтернативных вариантов
  • Ранжирование альтернатив
  • Выбор наилучшего решения
  • Обсуждение аспектов реализации
  • Реализация окончательного решения в соответствии с планом

На этапе Улучшать внедрение наилучшего решения обычно включает в себя более одного отдела. Обсуждение аспектов реализации наилучшего решения со всеми, кого это касается, является необходимостью до завершения и реализации плана.

Контролировать

Примеры мероприятий на заключительном этапе включают:

  • Разработать план контроля (указать контрольные точки и контрольные точки)
  • Внедрить подходящую систему мониторинга для контроля
  • Анализ и оценка воздействия изменений
  • Обновление документов, включая изменения в процессе
  • Закройте проект, вознаградите членов команды и расформируйте команду

На этапе Контролировать проводится проверка целостности данных. Здесь записывается план управления и перехода. Идея плана контроля, который также может быть важным результатом, заключается в том, что план контроля составлен таким образом, чтобы даже те, кто не знаком с Lean Six Sigma, могли его просмотреть и понять. Успех в Lean Six Sigma не основан на сложных или высокотехнологичных процедурах. Он полностью полагается на апробированные и проверенные системы. Это упрощает ситуацию, уменьшая множество сложностей. Один из способов снизить сложность - заставить всех членов проектной команды следовать базовой дорожной карте.

Модель DMAIC - это структура, которая может успешно определять улучшения процесса, предлагать решения и поддерживать улучшения. Это также подготавливает рабочее место к методичному подходу к сотрудничеству и анализу новых идей и инноваций. Leaner предполагает, что даже небольшие улучшения процессов могут принести пользу при использовании DMAIC-мышления. Некоторые улучшения процесса не требуют тщательного изучения на каждом этапе углубленной модели. Некоторые небольшие улучшения процесса могут выиграть от простого продумывания различных этапов модели.

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

Управление информацией и информационное моделирование

Безусловно неотъемлемой частью информационного моделирования в современном мире является управление знаниями. Онтология является одним из инструментов управления знаниями. В качестве основы будем использовать наработки по онтологии стандартов ISO15926: Онтология. Более подробно об описании подходов к формированию онтологии гражданского строительства можно посмотреть в разделе Онтология настоящего портала.

Методология управления конфигурацией в рамках информационного моделирования

Методология управления конфигурацией в рамках применения технологий информационного моделирования основывается на положениях национального стандарта ГОСТ Р 59193-2020 "УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ. Основные положения".


Управление требованиями в рамках информационного моделирования

Методология управления требованиями в рамках применения технологий информационного моделирования основывается на положениях национального стандарта ГОСТ Р 59194— 2020 "УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ. Основные положения", а также международных стандартов IEEE 1220-2005 "Standard for Application and Management of the Systems Engineering Process"

В рамках настоящей методологии уточним понятия, определенные в национальном стандарте:

Термины и определения методологии управления требованиями информационного моделирования
Термин Сокращение Определение Источник
Заинтересованная сторона ЗС Физическое лицо или организация (подразделение организации), которое(ая) выполняет по отношению к объекту какую-либо роль и, в связи с этим, имеет потребности (интересы, ожидания), связанные с объектом п. 3.1.19 ГОСТ Р 59194—2020
Потребность (заинтересованной стороны) Потребность Оформленные или озвученные заинтересованной стороной интересы и ожидания, связанные с объектом моделирования
Исходное (заданное) требование ИсхТ Требование, полученное в результате анализа потребностей заинтересованной стороны п. 3.1.11 ГОСТ Р 59194—2020
Ограничение Огр Составная часть требования или самостоятельное требование, описывающее внешнее ограничивающее условие (связанное с внешними по отношению к объекту воздействующими факторами), наложенное на объект, его конструкцию, процесс разработки, изготовления, эксплуатации, ремонта или утилизации п. 3.1.14 ГОСТ Р 59194—2020
Проектное (системное) требование ПТ Требование, полученное в результате анализа и декомпозиции исходных требований, а также в результате деятельности по проектированию и конструированию п. 3.1.15 ГОСТ Р 59194—2020
Прослеживаемость требования ПрТ Свойство требования, указывающее на возможность проследить источник (источники) требования (потребность заинтересованной стороны, исходное или проектное требование, принятое техническое решение) или отследить все дочерние требования п. 3.1.16 ГОСТ Р 59194—2020
Текст ячейки Текст ячейки Текст ячейки
Текст ячейки Текст ячейки Текст ячейки
Текст ячейки Текст ячейки Текст ячейки
Текст ячейки Текст ячейки Текст ячейки

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

В рамках единой системы информационного моделирования под под объектом моделирования понимается Настоящий стандарт по терминологии и составу задач в целом соответствует [1]. Соответствие терминов настоящего стандарта и терминов [1] приведено в таблице А.2. В этом пункте и далее по тексту стандарта термин «объект» используется для обозначения объекта, к которому задаются требования. Объектом может быть финальное изделие (в том числе комплекс и т. п.), СЧ (в том числе система, агрегат, сборочная единица, деталь, комплект и т. п.), программа для ЭВМ (в том числе встроенное ПО), интерфейс, материал, объекты, связанные с процессами ЖЦ. Объект, к которому задаются требования, как правило, в процедурах УК по ГОСТ Р 59193 яв- ляется ОКнф (см. 3.1.13)

4 Основные положения 4.1 В составе УТ выделяют два вида деятельности*: - разработка требований — инженерная деятельность по выявлению, анализу, декомпозиции, проверке, согласованию и утверждению требований к изделию и его СЧ, основанная на анализе потребностей заказчика и других заинтересованных сторон; - контроль требований — управленческая деятельность, направленная на поддержание актуальности и согласованности требований к изделию и его СЧ в ходе всего ЖЦ изделия (в том числе при изменении потребностей заинтересованных сторон). Эта деятельность является частью процесса УК в соответствии с ГОСТ Р 59193, выполняемого в отношении требований. 4.2 Управление требованиями осуществляют совместно заказчик и поставщик изделия. Для координации деятельности по УТ, при необходимости, разрабатывают программу УТ, в котором перечисляют решаемые задачи УТ, методы их решения (с указанием применяемых документов по стандартизации), ответственных исполнителей, способы обмена данными, планируемые результаты, взаимосвязи с процессом УК. 4.3 Требования задают к изделию в целом и к его СЧ (системам, агрегатам, узлам, деталям, программам для ЭВМ, в т. ч. встроенному ПО), к документам (информационным наборам, базам дан- ных и т. п.), материалам, интерфейсам, объектам, связанным с процессами ЖЦ (далее: объекты). 4.4 Требования могут быть представлены в форме*: - базы данных (совокупности информационных объектов и наборов) в автоматизированной си- стеме; - документа (бумажного или электронного по ГОСТ 2.051). Требования могут быть представлены в составе функционального ЭМИ в АС УДИ по ГОСТ Р 58301. 4.5 Все требования к одному объекту, необходимые для решения определенной задачи в ходе ЖЦ, составляют спецификацию требований к объекту*. При разработке нового объекта формируют: - спецификацию исходных (заданных) требований к объекту — для формализации потребностей всех заинтересованных сторон и создания базы для валидации объекта; - спецификациюпроектных(системных)требованийкобъекту—дляразработкиконструкторской, технологической, эксплуатационной и ремонтной документации на объект и создания базы для верификации объекта. 4.6 В модели ЖЦ объекта по ГОСТ Р 56136 выделяют КР двух типов, на которых выполняется работа с требованиями: - контрольные рубежи, на которых проверяют, согласовывают и утверждают разработанные требования к объекту (в результате требованиям присваивают статус готовности); - контрольные рубежи, на которых проверяют соответствие объекта требованиям (в результате требованиям присваивают статус выполнения). Общий порядок разработки и применения требований приведен в разделе 5.

5 Общий порядок разработки и применения требований 5.1 Общий порядок формирования требований к объекту* 5.1.1 Исходные требования к объекту получают в результате анализа: - потребностей в отношении разрабатываемого объекта всех заинтересованных сторон; - требований к объектам данного типа, заданных в документах по стандартизации. Потребности заинтересованных сторон и требования документов по стандартизации могут быть связаны с назначением и функционированием объекта, процессом его разработки, изготовления, испытаний, эксплуатации, ремонта и утилизации. В качестве потребностей заинтересованных сторон также рассматриваются требования к рассматриваемому объекту как СЧ другого объекта (см. 5.1.5). 5.1.2 Для разрабатываемых объектов на основании утвержденной спецификации исходных требований разрабатывают спецификацию проектных требований, обусловленных принятыми при проектировании и в результате анализа исходных требований техническими решениями. Для неразрабатываемых объектов на базе утвержденной спецификации исходных требований выбирают ранее разработанное техническое решение или покупное комплектующее изделие. 5.1.3 Проектныетребованиявключаютформализованноеописаниефункцийобъекта,технические характеристики, описание принципов и режимов работы, условий эксплуатации, характеристики взаимодействия с внешними объектами (интерфейсы) и другие необходимые для дальнейшей разработки сведения об объекте в целом и процессах его ЖЦ*. Проектные требования определяют такие характеристики объекта в целом, которые позволят обеспечить удовлетворение исходных требований, но (по возможности) не предписывают применение конкретных технических решений (если такие решения не обусловлены ограничениями, установленными в исходных требованиях). 5.1.4 Проектные требования к сложному объекту являются основой для разработки архитектуры (вариантов архитектуры) объекта в ходе проектирования. На основании проектных требований к объекту в целом и выбранного варианта архитектуры объекта разрабатывают требования к СЧ объекта*. 5.1.5 Требования к СЧ должны соответствовать 5.1.3. Требования к СЧ являются исходными дан- ными для формирования спецификации исходных требований к СЧ (см. 5.1.1).

5.2 Задание сведений для верификации и валидации объекта 5.2.1 Спецификацияисходныхтребованийявляетсябазойдлявалидацииобъекта.Спецификация проектных требований является базой для верификации объекта. 5.2.2 С целью подготовки к верификации и валидации объекта для каждого требования (группы требований) указывают следующие сведения: - КР в модели ЖЦ объекта, на котором должна быть выполнена проверка; - МОС на данном КР; - критерииуспешностипроверкитребованийнаКР(диапазонызначенийхарактеристик,описание вариантов правильного функционирования и т. п.); - вид (виды) ДД, в которых должны быть задокументированы результаты проверки и которые бу- дут официально подтверждать соответствие объекта требованиям.

Если верификация объекта выполняется на нескольких КР (одинаковыми или разными методами), то перечисленные выше сведения указывают для каждого КР. 5.2.3 Применяемые МОС, виды ДД и критерии успешности проверки, а также способы задания для требований перечисленных сведений устанавливают в программе УТ или в документах по стандартизации организации. 5.2.4 Утвержденная спецификация требований к объекту должна использоваться для разработки ПМИ по ГОСТ 19.301 для валидации или верификации объекта*. 5.3 Проверка, согласование и утверждение требований 5.3.1 Требования (каждое требование в отдельности и спецификация требований в целом) имеют свой ЖЦ, в котором выделяют стадии и события, связанные с изменением статуса готовности требований. Стадии ЖЦ требований, применяемые статусы готовности требований и события, приводящие к изменению статуса готовности, устанавливают в программе УТ или в документах по стандартизации организации*. 5.3.2 По окончании разработки спецификацию требований к объекту проверяют, согласовывают и утверждают. Утверждение отдельных требований выполняют только при внесении изменений в утвержденную спецификацию. Порядок проверки, согласования и утверждения требований устанавливают в документах по стандартизации организации. 5.3.3 При проверке требований выполняют их валидацию и верификацию. 5.3.4 При валидации требований проверяют: - полноту покрытия спецификацией требований всех потребностей заинтересованных сторон, ис- ходных требований и/или принятых технических решений; - правильность выражения требованием потребности заинтересованной стороны, отражения принятого технического решения и/или декомпозиции родительского требования; - наличие и правильность связи с потребностью заинтересованной стороны, родительским требованием или принятым техническим решением (см. 6.2.4—6.2.6); - непротиворечивость требований в спецификации. При валидации требований используют результаты компьютерного моделирования по ГОСТ Р 57412, испытаний, опыта эксплуатации аналогов и другие методы. 5.3.5 При верификации требований проверяют: - отнесение всех требований в спецификации к одному объекту; - соответствие формулировки каждого требования критериям качества, установленным в документах по стандартизации организации (см. 6.1); - соответствие спецификации требований в целом критериям качества, установленным в документах по стандартизации организации (см. 6.1); - правильность заполнения атрибутов требований, установленных в документах по стандарти- зации организации (см. 6.2); - правильность классификации требований и установления связей между требованиями и (см. 6.2); - наличиеиправильностьоформлениясведенийдляверификацииивалидацииобъекта(см.5.2). Полный перечень проверок требований устанавливают в документах по стандартизации организации. 5.3.6 После успешного прохождения проверки требования (спецификацию требований в целом) утверждают. Утверждение требований выполняют с применением электронной подписи или собственноручной подписи в удостоверяющем листе или в бумажном документе, содержащем требования. 5.4 Применение требований при верификации и валидации объекта 5.4.1 По результатам верификации или валидации объекта требованиям присваивают статус, указывающий что требование выполнено (статус выполнения). 5.4.2 С одним требованием может быть связано множество статусов выполнения, относящихся к разным КР и конфигурациям. При этом каждый статус выполнения должен содержать ссылки на КР, проверенную конфигурацию объекта, МОС, а также на утвержденный ДД (комплект ДД), на основании которого принято решении о выполнении (не выполнении) требования. 5.4.3 Видыипорядокприсвоениястатусоввыполнениятребованиямустанавливаютвдокументах по стандартизации организации. Примерами значений статуса выполнения могут быть: - требование выполнено; - требование выполнено с учетом разрешения на отклонение; - требование не выполнено (или отсутствует необходимый ДД). 6 Общие требования к содержанию и оформлению требований 6.1 Содержание требований и спецификации требований 6.1.1 Содержание требований должно соответствовать правилам, установленным в документах по стандартизации организации. Основные правила разработки содержания требований включают: - правильно сформулированное требование может быть проверено в ходе разработки и/или при предъявлении изделия заказчику; - правильно сформулированное требование должно описывать функцию, которую изделие должно выполнять, или характеристику, которой изделие должно обладать (а не возможности, которыми должны обладать пользователи/операторы изделия); - правильно сформулированное требование должно включать (или ссылаться на) описание условий и ограничений, при которых оно имеет смысл*; - правильно сформулированное требование не должно диктовать определенное техническое решение или ограничивать диапазон таких решений (без специальной необходимости, вызванной установленными ограничениями). Основные характеристики требований, на основании которых могут быть заданы правила формулирования требований в документах по стандартизации организации, приведены в Б.1 (приложение Б). 6.1.2 Для требований, выраженных текстовым утверждением, в документах по стандартизации организации должны быть установлены правила построения предложений, с указанием: рекомендуемого порядка слов, использования определенных ключевых слов и выражений (например, выражающих обязательность требования), использования определенных словоформ, перечня запрещенных для использования слов и выражений и т. п. Некоторые примеры таких правил приведены в Б.2 (приложение Б). 6.1.3 Спецификациятребованийвцеломдолжнасоответствоватьтребованиям,установленнымв документах по стандартизации организации. Некоторые характеристики спецификации требований, на основании которых могут быть заданы правила формирования спецификации требований в конкретном проекте, приведены в Б.3 (приложение Б). 6.2 Атрибуты требований и связи между требованиями 6.2.1 Обязательные атрибуты для требований и их возможные значения (при наличии) устанавливают в документах по стандартизации организации. Некоторые примеры атрибутов требований приведены в Б.4 (приложение Б). 6.2.2 Каждое требование должно быть уникально идентифицировано для обеспечения прослеживаемости в ходе разработки. Уникальный идентификатор требования не изменяется в ходе ЖЦ объекта, в том числе при внесении изменений в требование. Все изменения одного и того же требования производятся путем создания новой версии требования*. Требования к идентификатору требования и идентификатору версии требования устанавливают в документах по стандартизации организации. 6.2.3 Между требованиями к одному объекту, а также между требованиями к разным (взаимосвя- занным, взаимодействующим) объектам устанавливают связи, выполняющие разные функции: - связи подчиненности, описывающие, что одно требование получено из другого (родительского) требования (путем декомпозиции или в результате деятельности по проектированию и конструированию); - связи классификации, описывающие, что требования относятся к одному типу/группе — как правило, такие связи устанавливаются путем задания классифицирующего свойства в атрибуте требования или путем установления связи со специализированным объектом (разделом, папкой в автоматизированной системе). Классификация и группирование требований могут соответствовать положениям ГОСТ 15.016, ГОСТ 19.201, ГОСТ 34.602 и т. п. 6.2.4 В случае наличия документов, описывающих потребности заинтересованных сторон (например, отчет о научно-исследовательской работе), или применения документов по стандартизации при задании требований к объекту, для исходных требований должны быть установлены ссылки на эти документы (пункты документов). 6.2.5 Каждое проектное требования к объекту должно быть связано с утвержденными исходным требованием к этому объекту и/или с техническим решением по объекту, принятым в ходе разработки. 6.2.6 Каждое требование к СЧ должно быть связано с утвержденным проектным требованием к объекту в целом или с техническим решением по объекту, принятыми в ходе разработки.

7 Контроль требований 7.1 Требования являются частью документации конфигурации и подлежат контролю в процедурах УК в соответствии с ГОСТ Р 59193. 7.2 Требования должны быть связаны с соответствующим объектом конфигурации и должны иметь уникальный идентификатор, присваиваемый по правилам, установленным в организации. 7.3 Разработанные на КР требования подлежат проверке в рамках аудита документации конфигурации в соответствии с ГОСТ Р 59193—2020 (раздел 6). 7.4 После успешного завершения аудита требования становятся частью утвержденной конфигурации объекта по ГОСТ Р 59193 Спецификацию исходных требований к объекту включают в утвержденную требуемую конфигурацию объекта. Спецификацию проектных требований к объекту включают в утвержденную проектную конфигурацию объекта. 7.5 Изменение требований, включенных в утвержденную конфигурацию, производят по правилам управления изменениями, установленным в ГОСТ Р 59193—2020 (раздел 7). 7.6 Под изменением требований понимают: - изменение версии требований в утвержденной спецификации требований; - удалениетребования(й)изутвержденнойспецификациитребований(сзаменойилибеззамены); - добавление новых требований в утвержденную спецификацию требований. 7.7 При анализе требований и оценке вариантов изменения по ГОСТ Р 59193—2020 (подраздел 7.5), а также при определении необходимости изменения всех подчиненных конфигураций используют прослеживаемость требований. 7.8 Всем изменениям утвержденных требований присваивают класс изменения. Определение класса изменения требований выполняют по ГОСТ Р 59193—2020 (подраздел 7.6). 7.9 В случае изменения требования с присвоенным статусом выполнения возможны следующие варианты в зависимости от класса изменения (см. 7.8): - дляизмененияпервогоклассанеобходимоповторновыполнятьпроверкуконфигурацийобъекта, для которых установлено, что требование выполнено, на соответствие измененному требованию; - дляизмененийвторогоклассанетнеобходимостивповторныхпроверкахконфигурацийобъекта, для которых установлено, что требование выполнено (все статусы выполнения переносятся на новую версию требования автоматически). Следует отличать валидацию и верификацию требований к объекту от валидации и верифи- кации самого объекта. Валидация объекта представляет собой демонстрацию заказчику того, что объект удовлетво- ряет его потребностям и соответствует исходным требованиям. Валидация исходных (заданных) требований проводится на более раннем этапе для того, чтобы удостовериться, что эти исходные требования охватывают все значимые потребности всех заинтересованных сторон и правильно их выражают (формулируют) и следование таким требованиям позволит в будущем корректно выполнить валидацию объекта. Верификация объекта заключается в проверке того, что объект разработан в соответствии с заданными требованиями. Верификация требования заключается в проверке того, что сами требования разработаны в соответствии с предъявленными к ним требованиями (требования к формулированию, оформлению, структурированию и другим характеристикам требований как объекта разработки)

В зависимости от стадии (этапа) ЖЦ объекта возможно применение следующих МОС (перечень может быть расширен): - анализ документации; - расчет или компьютерное моделирование; - эксперимент с образцом или физическим макетом; - анализ опыта эксплуатации прототипа; - испытания опытного образца и его СЧ; - анализ опыта эксплуатации образца

Создание единого информационного пространства проекта

Про отличительное особенности Единого информационного пространства (ЕИП) от Среды общих данных (СОД) приведены в статье Отличие ЕИП и СОД

Информационное моделирование для управления проектом

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

В качестве базиса для дальнейшее работы можно использовать наработки ISO 15926: Plant Life-cycle Model

Одной из важнейших составляющих управления проектом является управление качеством.

Управление качеством с применения ТИМ

При реализации проекта с применением технологий информационного моделирования классические подходы к управлению качеством, определенные в ISO 9000, могут быть применены в полном объеме, но на новом цифровом уровне.

В первую очередь необходимо уточнить понятие "дефекта"[1]. В контексте информационного моделирования данное понятие приобретает более широкую трактовку, по отношению к его определению в ГОСТ 15467-79 "Управление качеством продукции. Основные понятия. Термины и определения". Этот же стандарт определяет понятия:

  • 40. Дефектное изделие - Изделие, имеющее хотя бы один дефект
  • 41. Явный дефект - Дефект, для выявления которого в нормативной документации, обязательной для данного вида контроля, предусмотрены соответствующие правила, методы и средства
  • 42. Скрытый дефект - Дефект, для выявления которого в нормативной документации, обязательной для данного вида контроля, не предусмотрены соответствующие правила, методы и средства
  • 43. Критический дефект - Дефект, при наличии которого использование продукции по назначению практически невозможно или недопустимо
  • 43. Критический дефект - Дефект, при наличии которого использование продукции по назначению практически невозможно или недопустимо
  • 44. Значительный дефект - Дефект, который существенно влияет на использование продукции по назначению и (или) на ее долговечность, но не является критическим
  • 45. Малозначительный дефект - Дефект, который существенно не влияет на использование продукции по назначению и ее долговечность
  • 46. Устранимый дефект - Дефект, устранение которого технически возможно и экономически целесообразно
  • 47. Неустранимый дефект - Дефект, устранение которого технически невозможно или экономически нецелесообразно

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

Управление рисками с примененим ТИМ

Еще одной важной составляющей управления проектами - является управление рисками. В этом контексте необходимо обратить внимание на стандарт ГОСТ Р 54141-2010 "Менеджмент рисков. РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ОРГАНИЗАЦИОННЫХ МЕР БЕЗОПАСНОСТИ И ОЦЕНКИ РИСКОВ. Эталонные сценарии инцидентов.

Территориальное моделирование

Моделирование территории это этап построения комплексной модели территории или города, которая позволяет проводить комплексный анализ и обеспечивает возможность формирование систем "умного города".

Проектное моделирование

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

  • Концептуальную - которая обеспечивает информацией традиционные этапы ОБИН и АГР
  • Инженерных изысканий - модель формируемая по результатам инженерных изысканий - соответствует традиционному этапу Инженерные изыскания - Уровень А[2]
  • Проектную - соответствующую стадии "П" - соответсвует традиционному этапу "Стадия П" - Уровень В
  • Строительную модель - соответствующую "РД" - Уровень С

Формирование Концептуальной модели

Формирование Проектной модели

Формирование Строительной модели

Строительное моделирование

Применение информационного моделирования на этапе строительства реализуется по следующей последовательности действий:

  • Получение требований от заказчика для дальнейшего управления
  • Приемка информационной модели от заказчика (генерального проектировщика) - проектная информационная модель
  • Формирование строительной информационной модели на основе проектной строительной информационной модели
  • Формирование информационной модели для пусконаладочных работ
  • Формирование исполнительной информационной модели

Информационное моделирование на этапе эксплуатации

Информационное моделирование при реконструкции и капитальном ремонте

Информационное моделирование на этапе вывода их эксплуатации

Информационное моделирование на этапе сноса и демонтажа

Библиография

  1. ↑ 37. Дефект - Каждое отдельное несоответствие продукции установленным требованиям
  2. ↑ Здесь и далее наименования моделей приведены в соответствие с СП 333.1325800.2020 Таблицей 5.1
Источник — https://www.imbok.pro/index.php?title=Методология_информационного_моделирования&oldid=498