인터페이스 제어 문서

Interface control document

시스템 엔지니어링 및 소프트웨어 엔지니어링의 인터페이스 제어 문서(ICD)는 프로젝트에 대해 생성된 모든 인터페이스 정보(도면, 다이어그램, 표, 텍스트 정보 등)의 기록을 제공한다.[2] 기본 인터페이스 문서는 서브시스템 간의 인터페이스 또는 시스템 또는 서브시스템에 대한 세부사항을 제공하고 기술한다.

개요

ICD는 시스템 인터페이스 상의 주요 문서로, 이러한 인터페이스 규격에서 설명해야 할 예는 다음과 같다.

  • 개별 SIRS[further explanation needed] 및 HIRS[further explanation needed] 문서에 문서화된 단일 시스템의 입력과 출력은 "The Wikipedia Interface Control Document"에 포함될 것이다.
  • 두 시스템 또는 서브시스템 간의 인터페이스(예: "Doghouse to Outhouse Interface")도 상위 ICD를 가질 수 있다.
  • 가장 낮은 물리적 요소(예: 접촉 플러그, 전기 신호 전압 레벨)에서 가장 높은 논리적 수준(예: OSI 모델의 레벨 7 적용 계층)까지 완전한 인터페이스 프로토콜은 각각 적절한 인터페이스 요건 사양에 문서화되며 "시스템"에 대한 단일 ICD에 포함된다.

ICD의 목적은 주어진 프로젝트에 대한 시스템 인터페이스 정보의 기록을 제어하고 유지하는 것이다. 여기에는 시스템의 일부 잠재 또는 실제 사용자를 위해 시스템에 대한 모든 가능한 입력과 시스템으로부터의 모든 잠재적 출력이 포함된다. 시스템 또는 서브시스템의 내부 인터페이스는 각각의 인터페이스 요건 사양에 문서화되어 있는 반면, 인간-기계 인터페이스는 시스템 설계 문서(소프트웨어 설계 문서 등)에 있을 수 있다.[citation needed]

인터페이스 제어 문서는 시스템의 문서화된 인터페이스를 제어하고 함께 작동하는 인터페이스 버전 집합을 지정하여 요건을 구속하는 시스템 엔지니어링의 핵심 요소다.

특성.

응용 프로그램 프로그래밍 인터페이스는 인터페이스를 통해 시스템이 제공하는 기능과 서비스에 액세스하는 방법을 기술한다는 점에서 소프트웨어 시스템의 인터페이스 형식이다. 시스템 생산자가 다른 사람이 시스템을 사용할 수 있기를 원하는 경우 ICD 및 인터페이스 사양(또는 그에 상응하는 것)은 가치 있는 투자가 된다.

ICD는 연결에 사용하는 시스템의 특성이 아니라 상세한 인터페이스 문서화 그 자체만을 설명해야 한다. 이러한 시스템의 기능과 논리는 필요에 따라 자체 요구사항과 설계 문서에 기술되어야 한다(이들 모두에 대한 DID가 있다). 이러한 방식으로 독립 팀은 다른 시스템이 인터페이스를 통해 전송되는 데이터와 신호에 어떻게 반응할 것인지에 관계없이 지정된 인터페이스를 사용하는 연결 시스템을 개발할 수 있다. 예를 들어, ICD 및 관련 인터페이스 문서에는 크기, 형식 및 데이터로 측정되는 내용에 대한 정보가 포함되어야 하지만 사용자가 의도한 사용에서 데이터의 궁극적인 의미는 포함되지 않아야 한다.

적절하게 정의된 인터페이스는 한 팀이 단순한 통신 시뮬레이터로 상대편을 시뮬레이션하여 인터페이스의 구현을 시험할 수 있게 한다. 인터페이스의 저편에 있는 시스템의 비즈니스 논리를 알지 못하면 다른 시스템이 비즈니스 규칙과 논리를 변경할 때 깨지지 않는 시스템을 개발할 가능성이 높아진다.(인터페이스 요구사항 명세서에서는 한계나 건전성 검사에 대한 제공은 분명히 피해야 한다.) 따라서 유지보수와 확장성이 용이하도록 유도하는 우수한 모듈화 및 추상화가 달성된다.

비판

일반적으로 요구사항 문서화 및 시스템 엔지니어링에 대한 비평가들은 문서화에 대한 과도한 강조를 불평하는 경우가 많다.[3] [4] ICD는 문서 중심 프로젝트에 종종 존재하지만 신속한 변화를 위한 프로젝트에도 유용할 수 있다(명시적으로 이름이 지정되지는 않았지만).[5] [6] ICD는 텍스트 문서가 될 필요는 없다. 각 하위 시스템을 DB 보기로 나타내는 동적 데이터베이스, 상호 작용 다이어그램 세트 등 (진화) 표일 수 있다.

ICD는 서로 다른 서브시스템 설계 팀들 간의 서브시스템 인터페이스에 대한 정보를 전달하기 위한 구조화된 방법을 제공하기 때문에 종종 서브시스템이 비동기적으로 개발되는 경우에 사용된다. [7] [8] [9]

참조

  1. ^ Wolter J. Fabrycky, Benjamin S. Blancard(2005년). 시스템 엔지니어링 및 분석. 프렌티스홀, 2005년
  2. ^ 데이터 항목 설명, 인터페이스 제어 문서(ICD), DI-SESS-81248B(2015)
  3. ^ Fowler, M.; J. Highsmith (July 2001). "The Agile Manifesto". Dr. Dobb's Journal. Retrieved 2006-05-11."그래, 물리적 문서화에는 재치와 실체가 있지만, 진정한 성공의 척도는 추상적이다. 관련자들이 필요한 이해를 얻을 수 있을까?"
  4. ^ Ambler, S.W. (March 2005). "Agile Modeling and eXtreme Programming (XP)". AgileModeling.com. Retrieved 2006-05-11., "...팀 구성원들 간의 언어적 의사소통은 팀 내에서 문서화의 필요성을 감소시킨다."
  5. ^ 신속한 변화를 위한/희박 문서: 신속한 변화를 위한 소프트웨어 개발 전략
  6. ^ 별것 아닌 일에 대한 많은 비난: 문서화
  7. ^ Cutkosky, Mark R.; Jay M. Tenenbaum; Jay Glicksman (September 1996). "Madefast: collaborative engineering over the Internet". Communications of the ACM. 39 (9): 78–87. doi:10.1145/234215.234474.
  8. ^ Spinellis, Diomidis (November 1998). "A Critique of the Windows Application Programming Interface". Computer Standards & Interfaces. 20 (1): 1–8. doi:10.1016/S0920-5489(98)00012-9. Retrieved 2012-12-12.
  9. ^ Leonard, Jason (May 2002). "Bringing System Engineers and Software Engineers Together" (PDF). The Rational Edge. Retrieved 2012-12-12.