개발방법 및 절차

(1) 운항자 관점의 요구반영

다른 IoT 분야의 플랫폼들과 선박 플랫폼의 큰 차이점 중 하나는, 실제 사용 자 의견을 확인하기가 상대적으로 어렵다는 점이다. 자율주행차량이나, 스마트 홈, 공장 자동화 등의 플랫폼은 관련된 사용자들이 많기 때문에 의견을 폭 넓 게 확인할 수 있고, 개발자 역시 사용 경험과 관련지식을 가지고 있을 수 있다.

그러나 선박 플랫폼의 사용자, 즉 운항자는 그 수가 상대적으로 많지 않고 관련된 경험과 의견 제시를 위해서는 승선한 경력뿐만 아니라 관련지식을 습득 하는데 많은 기간이 요구된다. 때문에 개발자들도 운항자 경력을 동시에 가지 기 어려워, 플랫폼 개발에서 운항자들의 사용의견 분석이 플랫폼의 기능과 품 질 및 성능향상을 위해 중요한 요소이다.

(2) S/W 아키텍처 설계 적용

항해정보플랫폼의 사용자로 예상되는 이해관계자가 이러한 설계과정에 참여 하고, 아키텍처 평가에도 사용적 관점을 반영할 수 있다면, 결과물의 품질과 성 능향상에 도움이 되며, 이후 개발 과정에도 중요한 근거가 될 것이다. 때문에 항해시스템플랫폼 아키텍처 개발과정에서 항해 경험이 있는 사용자, 즉 운항자 관점의 요구가 반영될 수 있도록 S/W 아키텍처 설계와 평가방법을 적용하였다.

S/W 아키텍처는 구현할 시스템에 대한 Top-down 뷰로 볼 수 있으며, 시스템의 구조 및 컴포넌트간의 관계를 표현하는 추상적 모델로서 시스템에 대한 기술적 명세와 공학적 청사진이 될 수 있다. 최근 정보통신 기술의 발달로 시스템들의 연결성이 강조되고 확대되면서, S/W 아키텍처는 더욱 중요해지고 있으며, 큰 규모의 시스템 S/W 구성에 선행되어야 하는 중요한 과정으로 주목받고 있다 (Bass, et al., 2013).

항해시스템 플랫폼은 새로운 개발사항이며, 아키텍처를 설계하기 위해서는 해당 플랫폼의 정확한 요구기능이 정의되어야 한다. S/W 분야에서는 항해시스 템과 같이 많은 서브시스템들이 포함된 신규 플랫폼의 개발 초기에, 여러 관점 과 시스템에 관련된 사람들의 이해를 높이기 위한 S/W 아키텍처 설계 과정을 적용하고 있다(Ehsan, et al., 2011). S/W 아키텍처 설계 과정은 S/W에 한정되지 않고 다양한 비즈니스와 시스템구성에 적용되고 있으며, 항해시스템 플랫폼 개 발단계에서 품질향상을 위한 방법으로 적용될 수 있다. 시스템 개발 이후에는 문제점에 대한 수정이 어렵고 높은 비용과 난이도가 발생하기 때문에 아키텍처 를 통해 개발 초기 문제를 예상하고 보완하여 보다 향상된 품질과 서비스의 시 스템을 구성하는 것이 필요하다. 또한 S/W 아키텍처는 목표로 하는 시스템구현 에 있어 사용자들과 개발자 사이에 잘못된 이해가 발생하지 않도록 요구사항을 명확히 하는 개발과정을 제시하고 있다. 사용자가 어떤 문제를 해결하거나 어 떤 목적을 달성하기 위해 필요한 조건이나 능력을 요구사항이라 하며, 사용자 들의 요구사항을 명확히 하는 것은 개발 프로젝트의 결과와 직결된다(김진태 등, 2006). Standish 그룹의 조사에서는 S/W 개발 프로젝트 31%가 완성 이전에

취소되고, 53%가 개발 예상비용을 초과하는 것으로 나타났다. Leffingwell (1997)은 프로젝트 취소와 개발 비용 초과가 발생하는 이유로 사용자 입력 부 족과 요구사항 변경 및 불완전한 요구사항을 지적하였다. 즉 요구사항의 부적 절한 관리가 프로젝트의 주요 실패원인 이였으며, S/W 아키텍처 개발 과정을 적용하여 이러한 문제점을 보완할 수 있다. S/W 아키텍처의 설계과정은 새로운 시스템 개발 시, 내부 시스템간의 속성과 특성을 정의하여 이해관계자들의 이 해를 돕고 개발에 필수적인 아키텍처를 구성하는 방법이다. 항해시스템플랫폼 의 사용자로 예상되는 운항자가 이러한 설계과정에 참여하고, 아키텍처 평가에 사용적 관점을 반영한다면, 결과물의 품질과 성능향상이 가능하다. 운항자 관점 의 아키텍처 설계는 시스템 개발 과정에도 중요한 근거가 된다.

(3) 항해시스템플랫폼 아키텍처 개발절차

운항자 관점의 요구반영과 개발과정의 체계성을 위해 Fig. 18과 같이 개발절 차를 3개 과정(Phase)으로 계획하였다. 각 과정은 세부 단계(Step)로 구성되고 각 단계에는 필요한 활동(Activity)을 수행하여 항해시스템플랫폼 아키텍처가 제 시될 수 있도록 계획하였다.

Fig. 18 Navigational System Platform Architecture Design Phase

SEI(Software Engineering Institute)의 전형적인 S/W 아키텍처의 설계과정은 분석(Analysis), 설계(Design), 검증(Validation)으로 구분되며(Bass, et al., 2013), 분석과정은 Phase 1과 2에, 설계와 검증은 Phase 3에 적용하였다. 본 연구는 개발대상의 기능을 명확히 하기 위해 Phase 1을 추가하여 관련연구 조사 및 개 선점 도출과정을 수행하였고, 그 결과를 요구분석 단계에 제시하도록 하였다.

또한 운항자 관점의 요구도출을 위해 QAW를 이해관계자 요구분석 단계에 적 용하여 단순 설문이나 인터뷰 보다 상세한 요구사항과 불필요한 요구들에 대한 수정 및 개선을 수행하였다. 각 과정의 단계와 활동사항은 다음과 같다.

Phase 1은 선행 연구조사와 기술동향, 대상 시스템의 개선요소 도출을 통해 항해시스템플랫폼의 핵심 기능을 정의하고, 그 결과는 Phase 2의 QAW에서 Presentation을 통해 이해관계자들에게 전달한다.

Phase 2는 대상 시스템의 주요 항해장비들에 대한 분류 및 분석과 이해관계 자 중심의 QAW를 통해 기능 요구사항, 비기능 요구사항, 품질속성, 설계 및 개 발 제약사항 등을 파악하고 품질속성 시나리오를 작성한다. 본 연구에서는 Phase 2를 모듈 설계를 목적으로 품질속성 시나리오에 관련항해 장비들의 코드 화된 정보뿐만 아니라 이해관계자들의 정제를 통해 더욱 구체적인 내용 작성을 계획하였고, 품질속성 시나리오 명칭을 아키텍처 모듈 설계서로 정의하였다.

Phase 3은 작성된 아키텍처 모듈 설계를 근거로 아키텍처 개발을 수행하고, ATAM 평가과정을 적용하여 모듈 설계 내용과 아키텍처를 평가한다. 아키텍처 개발은 요구사항의 분석 결과를 토대로 관련 QA별로 구체적인 아키텍처 모듈 설계를 적용하는 과정이다. 이를 기반으로 아키텍처를 시각적으로 보여줄 수 있는 아키텍처 뷰로 개발 결과물이 제시된다(Clements, et al., 2010). 아키텍처 평가는 ATAM을 통해 QA에 대한 유틸리티 트리 작성과 아키텍처 모듈 설계에 대한 분석과 평가를 실시한다(Clements, et al., 2002). 아키텍처에 대해서도 필 요한 수정과 개선요소를 제시하고, 필요한 경우 식별된 문제점에 대한 수정사 항이 반영된다.