티스토리 뷰

728x170

 포스팅은 아키텍트가 되기 위한 과정을 설명합니다.


그 세번째 시간으로 아키텍처 분석과정 중 솔루션 및 재사용 자산 분석 절차에 대해 살펴보도록 하겠습니다.

프로젝트에 적용되는 솔루션 및 재사용 자산의 역할과 책임을 파악하고 요구사항과의 Gap를 분석하며, 각종 솔루션 및 재사용 자산을 적용할 경우 각 솔루션 간의 충돌 등의 문제를 미리 파악하여 구현 가능성을 확보하는데 목적이 있습니다.


1. 수행절차


  1. 리드아키텍트는 아키텍처 이슈 목록에 관련된 솔루션 및 재사용 자산에 대한 관련성을 파악하고 해당 태스크의 수행 대상을 선정하고 해당 아키텍트에게 업무를 분장한다.
  2. 아키텍트는 아키텍처 이슈 목록 및 아키텍처분석서를 기반으로 시스템 공통 기능을 담당하게 될 솔루션 제품 및 재사용 SW 자산을 파악한다.
    • SA는 일반적으로 어플리케이션 개발을 지원하는 솔루션 (즉, SSO, Reporting툴, X-Internet, Framework 등)과 재사용 자산 (기존 시스템에 적용된 공통 모듈 또는 내부 재사용 자산 등)에 관련한 내용을 담당한다.
    • TA는 일반적으로 인프라에 관련된 솔루션 (즉, WEB/WAS서버, DBMS, OS, 네트워크 솔루션 등)과 재사용 자산(기존 시스템에 적용된 공통 모듈 또는 내부 재사용 자산 등)에 관련한 내용을 담당한다.
    • DA는 일반적으로 데이터 관리에 관련된 솔루션 (즉, 데이터 컨버전, 데이터 용어관리 솔루션 등)과 재사용 자산(기존 시스템에 적용된 공통 모듈 또는 내부 재사용 자산 등)에 관련한 내용을 담당한다.
  3. 아키텍트는 파악된 솔루션 제품 및 재사용 자산 간의 연간관계를 고려하여 시스템에 배치하고 솔루션 관점에서의 시스템 구성도를 작성한다.
    • 아키텍트는 주요 공통 기능 등의 핵심 업무 요구사항(핵심 유스케이스 등) 분석을 통해 단일 이벤트에 대해 자주 협력하는 솔루션들의 연관관계를 확인한다.
  4. 아키텍트는 각각의 솔루션 및 재사용 자산에 대한 역할과 책임을 확인하고 이를 기반으로 해당 기능의 구현 가능성 및 구현 이슈를 도출한다. (요구사항과의 GAP 분석)
    • 아키텍트는 해당 솔루션 및 재사용 자산과 연관관계가 있는 솔루션들과의 충돌 문제가 없는 지 확인하고 도출된 이슈는 담당 솔루션 업체 등과 해결방안을 정리한다.
  5. 필요 시 PoC/BMT 등의 수행 필요성 여부를 검토하고 수행 계획을 수립 후 진행한다.
    • 아키텍처 요구사항 분석을 통해서 이슈가 예상되는 어플리케이션 솔루션 대상으로 실시한다.
    • 솔루션 중 Reference 프로젝트의 부족으로 미 검증된 솔루션을 대상으로 실시한다.
    • 어플리케이션 솔루션 분석 결과를 정리한다.
    • 주요 의사결정 항목 및 향후 이슈가 될 수 있는 부분에 대해서는 프로젝트 입장을 정리하고 해당 내용에 대해서 고객의 합의 또는 전달을 하여 근거를 명확히 한다.
  6. 본 태스크에서 수행된 내용을 포함해서 아키텍처 이슈 목록을 보완한다.


2. 수행가이드


  1. 이 태스크는 프로젝트에 적용되는 솔루션 및 재사용 자산에 대해서 구현 시에 발생할 수 있는 이슈 대상을 사전에 도출하여 구현 가능성을 확보하기 위한 분석 활동이다. 특히 도입된 솔루션 또는 재사용 자산들을 개발환경으로 연계한 경험이 없는 경우에 작성한다.
    • 솔루션 제품 및 재사용 SW 자산은 PJT 제안서 및 요구사항정의서를 참조하여 도출한다.
    • 솔루션은 상용 제품 및 오픈 소스에 대한 솔루션 제품을 모두 포함하며 재사용 SW 자산은 SDS 자체의 재사용 SW 뿐 아니라 고객 시스템에서 사용하고 있는 재사용 SW 자산을 반드시 포함할 수 있도록 한다. (예: 고객이 이미 사용하고 있는 SSO 솔루션, 고객이 이미 사용하고 있는 웹 보안 솔루션 등)
    • 파악된 재사용 자산에 대한 활용방안 (수정필요 여부, 관련 라이센스 확보여부 등)과 PJT의 생산성 및 아키텍처 측면의 이슈를 고려하여 분석한다.
    • 요구사항의 변경 등으로 신규 솔루션의 도입 여부를 검토하고, Build/Buy/재사용 분석을 통해 현실적인 대안을 검토한다
    • 재사용자산의 경우 인프라 변경에 따른 도입 솔루션의 라이선스 영향도를 검토한다.
    • 솔루션들의 기술지원을 위한 주요 솔루션간의 제품 호환성 범위를 검토한다.해당 솔루션 및 재사용 자산의 역할과 책임을 명확히 파악하기 위해 업무 PL과 협의하여 해당 업무에서 필요한 주요 시스템 공통 기능을 파악하고 해당 기능을 담당하게 될 솔루션 또는 재사용 자산을 배치한다.
    • 상기 활동을 위해서 핵심 업무 요구사항(핵심 유스케이스)을 기준으로 확인할 필요가 있다. 즉, 액터의 단일 이벤트에 대해 자주 협력하는 특정 솔루션 군들이 서로 시스템적으로 충돌이 발생하는지 검토한다.
    • 솔루션 및 재사용 SW 자산 목록을 정리할 때 제품명과 버전을 반드시 명기하고 간단한 용도와 신규 도입 솔루션인지, 기존 고객이 도입하여 사용하고 있는 자산인지를 명시할 수 있도록 한다. (특히 제안 시에 사용한 견적서와 비교할 수 있도록 한다.)
    • 시스템에 적용할 솔루션 및 재사용 SW 자산들 간의 기능이 중복되는 제품이 없는지 파악하여 기능이 중복된다면 어떤 제품에서 해당 기능을 수행하게 할 것인지 결정한다.
  2. 솔루션 및 재사용 자산 분석에서 대상이 되는 제품별로 목차를 반복하여 작성하도록 하며 제품의 기능 중 시스템에서 활용할 기능과 요구사항과의 GAP 분석을 수행한다.
    • GAP 분석 시에는 요구사항에 맞지 않는 부분뿐 아니라 실제 구현 가능성 및 구현에 따른 이슈도 같이 정리한다. 위험도가 높을 경우에는 해당 제품 벤더 및 해당 업무 팀과 협의를 진행해야 한다.
    • 적용 이슈 부분은 별도의 절로 정리하여도 되고 아키텍처 이슈 리스트를 별도로 작성한 경우 아키텍처 이슈 리스트에 정리하여도 무방하다. 단, 정리된 이슈는 이후에 지속적으로 확인 및 해결해 나가야 하며 필요 시 POC를 통해 검증을 할 수 있도록 한다.
    • 구현하는데 있어서 특정 품질속성을 달성하는데 이슈가 되는 경우는 이후 SW아키텍처 설계전략 또는 기술 아키텍처 설계전략에서 구현 방향에 대해서 검토 한다.
  3. 타 솔루션과의 연계가 필요하다고 판단된 경우 타 솔루션과의 연계 시의 방안에 대해 기술한다. 여기서 방안이 꼭 확정될 필요는 없으나 최소한 연계의 방법에 대한 분석은 수행하여 정리하도록 한다. 각 연계 방식에 대한 이슈 등도 같이 정리할 수 있다.
  4. 프로젝트 기간이 긴 경우, 해당 제품의 기술로드맵 상 예상 업데이트 일정을 확인하고 도입된 어플리케이션들 간의 기능 중복 및 기존 버전과의 호환성 이슈 여부 검토 필요성을 확인한다.
  5. 프로젝트 규모와 일정, 고객의 표준 프로세스, 제품의 중요도 및 검증 기법 등을 고려하여 제품 선정 방법 및 절차를 정의한다.
  6. 제안 시에 고려되지 않은 솔루션을 도입하는 것은 비용을 동반하기 때문에 사전에 누락되지 않도록 유의하며, 오픈소스 및 사내 재사용 솔루션의 활용성도 검토한다.
  7. 프로젝트 핵심 요건 대비 솔루션(도입 혹은 재활용) 기능이 충분히 만족하는 지에 대한 솔루션 기능대비표 등을 통한 Gap 분석을 수행 하고, 업무시스템과 솔루션간의 통합과 관련한 전체 Topology 분석, 연동 제약사항 등을 정의한다.
  8. 현 운영중인 솔루션과의 통합 운영이 필요한 경우 기존 솔루션의 운영 형태 및 특성, 제약사항, 연계활용시의 성능목표 달성방안, 장애회피방안 등을 분석하여 통합적인 품질목표 달성을 위한 방안을 분석한다.
  9. 개발 어플리케이션과 도입 솔루션을 연계하기 위한 Glue code가 필요한 경우 해당 요건을 정의하고, 통합 시 솔루션의 커스터마이징이 필요한 경우 이에 대한 협의를 통하여 요건을 명확히 한다.
  10. 핵심 솔루션 또는 고객이 특별히 사전 검증을 요구하는 경우 BMT, POC 계획에 반영하도록 하고, 이를 수행하는데 필요한 벤더 기술지원 필요성에 대해서 사전에 확인한다.
  11. 현 구축시스템과 효율적으로 통합될 수 있는 지에 대한 적용성을 분석/검토하며, 발생할 수 있는 예상문제점, 제약사항을 확인한다.



그리드형
댓글
댓글쓰기 폼