공개소프트웨어

  • 공개소프트웨어
HOME > 공개소프트웨어
공개소프트웨어| 오픈소스 소프트웨어에 대한 기본 지식들을 제공합니다.
 
공개소프트웨어 기술로드맵 평가
조회 : 1,350  


공개소프트웨어 기술로드맵 평가

 

 

글쓴이 : 리눅스포탈(www.superuser.co.kr) 박성수(papa@superuser.co.kr)

  기관에서 소프트웨어를 도입할 때에는 상용소프트웨어뿐아니라 공개소프트웨어를 도입할 때에도 기술적인 로드맵을 확보해야 한다. 기술 로드맵이란 도입하는 소프트웨어에 발생 가능한 개선점과 전달 시간계획에 대한 개요를 제공해 주는 문서이다. 이 문서의 목적은 미리 파악해야하는 사항을 이해하기 쉽도록 사용자에게 도움을 주기 위한 것이다.

  기술 로드맵에는 개발자가 의도했던 내용대로 100% 정확한 결과가 무조건적으로 정확하게 나온다고 절대 보장해서는 안된다. 이것은 공개소프트웨어뿐아니라 독점공급되는 상용소프트웨어에 있어서도 분명한 사실이다. 하지만 이러한 객관적인 기술 로드맵의 확보는 공개소프트웨어를 도입하는 기관에게 있어 미래에 발생할 수 있는 특정기술의 무용성이나 쇠퇴등으로 부터의 위험요소를 평가하고 감소시키는데 큰 도움이 된다.  

  또한 이에 못지않게 중요한 것은 미래 비전에 대한 공급업체의 수행 능력이다. 만약 공급업체가 제품 로드맵, 또는 일반 기술플랫폼을 수정하거나 변경한다면 이는 위험요소가 매우 높은 업체로 인식해야 한다. 따라서 도입기관은 개발업체에서 공급하는 제품이 원래 의도했던 대로 미래지향적이지 못하거나 훌륭하지 못하다고 판단하게 될 것이다. 또한 공급받은 제품이 몇년 후에 발생할지 모르는 기술지원에 대한 보증도 할 수 없을 것이다.

  또한 기관은 미래의 위험요소를 보다 정확하고 적절하게 평가할 수 있도록 제품 로드맵을 검토해야 한다. 이러한 로드맵에 대한 정기적인 검토는 기관이 공급업체의 신뢰성과 능력을 파악하는데 큰 도움이 된다. 그리고 이러한 작업들은 미래의 계획수립시에 위험요소를 더욱 줄이는 훌륭한 방법이 다.

  로드맵 평가 및 검토 과정은 다음사항을 고려한 절차대로 이루어지는 것이 좋다.

- 공급받은 제품의 개발업체가 제공한 로드맵을 배치하고 기록한다.
- 개발업체가 최신 개발정보 및 제품 배포일 및 버전에 대한 정보를 비롯하여 사용자 커뮤니티에 대한 정보를 배치하고 기록한다.
- 현재의 타임라인(timeline)을 점검한다.
- 개발업체의 대표자에게 연락한다. 로드맵 및 배포 일정에 대한 업데이트의 주기등에 대한 정보를 확인한다.
- 제품 로드맵과 배포 일정을 모두 포함하는 웹 페이지의 개별 사본을 배치하고 기록한다.
- 변경내용을 확인할 수 있는 이전의 로드맵과 최신 로드맵을 비교한다. 특히 추가 예정되었던 사항이 제거된 항목이 있다면 이를 확인한다.
- 추가된 항목을 확인할 수 있는 이전버전과 소프트웨어 개발자의 최신 뉴스 항목을 비교한다
- 최초로 제안되었던 이정표의 내용들이 실제 실행되었는지 확인할 수 있도록 현재 뉴스 항목 웹 페이지에서 확인된 타임라인과 날짜를 비교한다
- 분석 기간이 요구된다면 이 주기를 비교한다.

  이러한 정보들은 공급되는 공개소프트웨어 제품뿐아니라 공급업체(개발업체)에 대한 위험요소 평가의 일부분으로 구성되어야 한다. 이러한 과정은 소프트웨어를 생산하고 유지관리하는 주요 부분에서 발생할 수 있는 문제점들을 도입기관에게 알려주는 매우 유용한 역할을 하게 된다.

  따라서 문제 발생에 대한 조기 경고를 함으로써 도입되는 공개소프트웨어의 위험요소를 줄일 수 있고 또한 효율적인 관리를 할 수 있다.

  자, 이제 기술로드맵의 변경에 따른 위험요소를 어떻게 관리하는가에 대해서 알아보자.

  공개소프트웨어를 개발하는 어떤 개발업체들은 품질 및 세부사항에 대한 기술 로드맵을 충분히 제공하지 못할 수도 있다. 더욱이 이미 마련되어 있는 자체 로드맵 또한 일관성있게 지키지 못하는 경우도 있다. 이러한 개발업체들로 인하여 도입기관은 장기적인 미래전략 수립을 하는 것이 매우 힘들게 된다. 결론적으로 이러한 로드맵에도 위험요소가 존재하고 있다.

이러한 로드맵에 대한 위험요소를 줄이는 방법은 아주 간단한 원칙에서 찾을 수 있다. 기관이 타기관 또는 사용자들이 광범위하게 사용하고 있는 공개소프트웨어 제품을 미리 선택하고 공급업체에게 이미 선택한 제품을 공급하도록 한다면 위험요소의 상당부분을 줄일 수 있다. 일반적으로 많은 사람들로 부터 광범위하게 사용되어지고 있는 소프트웨어에 대한 위험요소는 매우 낮을 뿐아니라 기관 및 사용자들이 요구하는 거의 모든 기능과 특징들을 이미 갖추고 있기 때문이다.

  이상과 같이 공개소프트웨어의 도입에 따른 로드맵 확인과 로드맵의 평가, 그리고 로드맵의 관리방법과 위험요소들에 대하여 알아 보았다. 결론적으로 공개소프트웨어를 선택하고 도입할 때에는 기술로드맵이 있는가를 확인하고 이를 평가하는 과정을 거쳐야 한다. 이러한 작업들로써 우리는 미래에 있을 위험요소 즉, 미래 위험요소를 줄일 수 있다.


[원글링크] : https://www.linux.co.kr/home2/board/subbs/board.php?bo_table=lecture&wr_id=1014


이 글을 트위터로 보내기 이 글을 페이스북으로 보내기 이 글을 미투데이로 보내기

 
박성수
파파
헐렁고수