Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Тип документа в инженерной области Документ управления интерфейсом (ICD) в системной инженерии и инженерии программного обеспечения, предоставляет запись всей информации интерфейса (такой как чертежи, диаграммы, таблицы и текстовая информация), созданная для проекта. В документах, описывающих интерфейс, приводятся подробные сведения и описание интерфейса или интерфейсов между подсистемами или с системой или подсистемой.
Type of document in engineering
An interface control document (ICD) in systems engineering
and software engineering, provides a record of all interface information (such as drawings, diagrams, tables, and textual information) generated for a project. The underlying interface documents provide the details and describe the interface or interfaces between subsystems or to a system or subsystem.
Характеристики
Интерфейс прикладного программирования - это форма интерфейса для программной системы, в которой описывается, как получить доступ к функциям и услугам, предоставляемым системой через интерфейс. Если производитель системы хочет, чтобы другие могли использовать систему, ICD и спецификации интерфейса (или их эквивалент) являются достойными инвестициями. В ICD следует описывать только саму подробную документацию интерфейса, а не характеристики систем, которые используют его для подключения. Функции и логика этих систем должны быть описаны в их собственных требованиях и проектных документах, если это необходимо. Таким образом, независимые команды могут разрабатывать соединительные системы, использующие указанный интерфейс, без учета того, как другие системы будут реагировать на данные и сигналы, которые передаются через интерфейс. Например, ICD и связанная с ним документация интерфейса должны включать информацию о размере, формате и том, что измеряется данными, но не о каком-либо окончательном значении данных в их предполагаемом использовании любым пользователем. Адекватно определенный интерфейс позволит одной команде проверить реализацию интерфейса, имитируя противоположную сторону с помощью простого симулятора связи. Не зная бизнес-логику системы на другой стороне интерфейса, более вероятно, что одна из них разработает систему, которая не ломается, когда другая система меняет свои бизнес-правила и логику. (В спецификации требований к интерфейсу следует избегать ограничений или проверки здравомыслия.) Таким образом, достигается хорошая модульность и абстракция, что позволяет легко поддерживать и расширять.
An application programming interface is a form of interface for a software system, in that it describes how to access the functions and services provided by a system via an interface. If a system producer wants others to be able to use the system, an ICD and interface specs (or their equivalent) is a worthwhile investment. An ICD should only describe the detailed interface documentation itself, and not the characteristics of the systems which use it to connect. The function and logic of those systems should be described in their own requirements and design documents as needed. In this way, independent teams can develop the connecting systems which use the interface specified, without regard to how other systems will react to data and signals which are sent over the interface. For example, the ICD and associated interface documentation must include information about the size, format, and what is measured by the data, but not any ultimate meaning of the data in its intended use by any user. An adequately defined interface will allow one team to test its implementation of the interface by simulating the opposing side with a simple communications simulator. Not knowing the business logic of the system on the far side of an interface makes it more likely that one will develop a system that does not break when the other system changes its business rules and logic. (Provision for limits or sanity checking should be pointedly avoided in an interface requirements specification.) Thus, good modularity and abstraction leading to easy maintenance and extensibility are achieved.
Критика
Критики документации требований и системной инженерии в целом часто жалуются на чрезмерное внимание к документации. ICD часто присутствуют в проектах, основанных на документах, но могут быть полезны и в гибких проектах (хотя и не называются явно). В МКБ не обязательно использовать текстовый документ. Это может быть (эволюционирующая) таблица входящих и выходящих данных, динамическая база данных, представляющая каждую подсистему в виде представления БД, набор диаграмм взаимодействия и т. Д. ICD часто используются там, где подсистемы разрабатываются асинхронно во времени, поскольку они обеспечивают структурированный способ передачи информации о подсистемных интерфейсах между различными командами проектирования подсистем.
Critics of requirements documentation and systems engineering in general often complain of the over emphasis on documentation. ICDs are often present on document driven projects, but may be useful on agile projects as well (although not explicitly named as such). An ICD need not be a textual document. It may be an (evolving) table of goes intos and comes out ofs, a dynamic database representing each subsystem as a DB view, a set of interaction diagrams, etc. ICDs are often used where subsystems are developed asynchronously in time, since they provide a structured way to communicate information about subsystems interfaces between different subsystem design teams.