Документ управления интерфейсом - Interface control document

An документ управления интерфейсом (МКБ) в системная инженерия [1] и программная инженерия, обеспечивает запись всей информации интерфейса (такой как чертежи, диаграммы, таблицы и текстовую информацию), созданной для проекта.[2] Базовые документы интерфейса предоставляют подробные сведения и описывают интерфейс или интерфейсы между подсистемы или к система или же подсистема.

Обзор

ICD - это зонтичный документ над интерфейсами системы; Примеры того, что должны описывать эти спецификации интерфейса, включают:

  • Входы и выходы одной системы, задокументированные в отдельных SIRS.[требуется дальнейшее объяснение ] и HIRS[требуется дальнейшее объяснение ] документы, подпадут под «Документ по управлению интерфейсом Википедии».
  • Интерфейс между двумя системами или подсистемами, например «Интерфейс между собачьей будкой и уборной» также будет иметь родительский ICD.
  • Полный протокол интерфейса от самых низких физических элементов (например, ответных вилок, уровней напряжения электрического сигнала) до самых высоких логических уровней (например, уровень 7 прикладной уровень из Модель OSI ) каждый из них был бы задокументирован в соответствующей спецификации требований к интерфейсу и подпадал под один ICD для «системы».

Цель ICD - контролировать и поддерживать запись информации о интерфейсе системы для данного проекта. Сюда входят все возможные входы и все потенциальные выходы системы для некоторого потенциального или фактического пользователя системы. Внутренние интерфейсы системы или подсистемы задокументированы в соответствующих спецификациях требований к интерфейсам, в то время как человеко-машинные интерфейсы могут быть в Системный дизайн документ (например, проектный документ программного обеспечения )[нужна цитата ].

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

Характеристики

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

ICD должен описывать только подробную документацию по интерфейсу, а не характеристики систем, которые используют его для подключения. Функции и логика этих систем должны быть описаны в их собственных требованиях и проектных документах по мере необходимости (для всех них есть DID). Таким образом, независимые группы могут разрабатывать соединительные системы, использующие указанный интерфейс, независимо от того, как другие системы будут реагировать на данные и сигналы, отправляемые через интерфейс. Например, ICD и соответствующая документация интерфейса должны включать информацию о размере, формате и том, что измеряется данными, но не какую-либо окончательную смысл данных в их предполагаемом использовании любым пользователем.

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

Критика

Критики документации требований и системной инженерии в целом часто жалуются на чрезмерное внимание документации.[3][4] ИКД часто присутствуют на документарные проекты, но может быть полезно на гибкие проекты также (хотя явно не назван как таковой).[5][6] ICD не обязательно должен быть текстовым документом. Это может быть (развивающаяся) таблица входит в и выходит из, динамическая база данных, представляющая каждую подсистему в виде представления БД, набора диаграмм взаимодействия и т. д.

ICD часто используются там, где подсистемы разрабатываются асинхронно во времени, поскольку они обеспечивают структурированный способ передачи информации об интерфейсах подсистем между различными группами разработчиков подсистем.[7][8][9]

Рекомендации

  1. ^ Вольтер Дж. Фабрики, Бенджамин С. Бланшар (2005). Системная инженерия и анализ. Прентис-Холл, 2005
  2. ^ ПУНКТ ДАННЫХ ОПИСАНИЕ, Документ управления интерфейсом (ICD), DI-SESS-81248B (2015)
  3. ^ Фаулер, М.; Дж. Хайсмит (июль 2001 г.). «Манифест Agile». Журнал доктора Добба. Получено 2006-05-11., «Да, у физических документов есть вес и содержание, но реальная мера успеха абстрактна: получат ли вовлеченные люди необходимое понимание?»
  4. ^ Эмблер, С. (Март 2005 г.). «Гибкое моделирование и экстремальное программирование (XP)». AgileModeling.com. Получено 2006-05-11., «... устное общение между членами команды снижает потребность в документации внутри команды».
  5. ^ Документация Agile / Lean: стратегии гибкой разработки программного обеспечения
  6. ^ Много шума из ничего: документация
  7. ^ Каткоски, Марк Р .; Джей М. Тененбаум; Джей Гликсман (сентябрь 1996 г.). «Madefast: совместная разработка через Интернет». Коммуникации ACM. 39 (9): 78–87. Дои:10.1145/234215.234474.
  8. ^ Спинеллис, Диомидис (ноябрь 1998 г.). «Критика интерфейса программирования приложений Windows». Компьютерные стандарты и интерфейсы. 20 (1): 1–8. Дои:10.1016 / S0920-5489 (98) 00012-9. Получено 2012-12-12.
  9. ^ Леонард, Джейсон (май 2002 г.). «Объединение системных инженеров и разработчиков программного обеспечения» (PDF). Рациональное преимущество. Получено 2012-12-12.