공개소프트웨어

  • 공개소프트웨어
HOME > 공개소프트웨어
공개소프트웨어| 오픈소스 소프트웨어에 대한 기본 지식들을 제공합니다.
 
공개소프트웨어 도입유형 (내부개발)
조회 : 1,282  


공개소프트웨어 도입유형 (내부개발)

 

 

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

 

  공개소프트웨어를 도입하는 방법들 가운데 기관내부에서 직접 개발하는 방법에 대해서 알아보도록 하자. 공개소프트웨어는 아무것도 없는 상태에서 처음부터 개발하는 것이 아니라 공개되어 있는 수많은 공개소프트웨어들 가운데 도입하고자 하는 용도에 가장 적합한 공개소프트웨어를 선택하고 다운로드하여 기관내부의 개발자들에 의해 수정개발하는 것을 의미하는 것이다.

  기관내부 개발 방법으로 공개소프트웨어를 도입할 때에 고려해야 할 사항들을 간단히 정리해 보면 다음과 같다.

- 가장 적합한 공개소프트웨어 선택기준 마련
- 다운로드한 공개소프트웨어의 안정성 검토
- 적용되는 라이센스 정책마련
- 가장 적합한 개발방법론 마련
- 개발직원의 개발능력 검토
- 사용직원의 사용법 교육안 마련
- 개발소프트웨어의 문서화 작업
- 개발된 공개소프트웨어의 안정성과 영속성 대책 마련
- 기타 특정업무의 종속되는 대책 마련등

  이제 부터 실제 내부개발 방법시에 단계적으로 이루어지는 개발절차에 대해서 하나씩 살펴보자. 단, 앞장의 내용과 중복되는 내용에 대해서는 중복설명을 피하기 위하여 생략하였으므로 참고하기 바란다.


ㅇ 서비스의 정의 및 적용업무 분석

  가장 먼저 해야 할 작업이 어떤 업무에 적용하기 위하여 공개소프트웨어를 도입할 것인가를 정의해야하는 작업이다. 즉, 이러한 작업을 "서비스 정의"작업이라고 할 수 있으며 웹기반으로 개발할 것인지 아니면 기관내부 솔루션으로 사용하기위한 개발인지 아니면 유관기관과의 정보공유 및 협동 네트워크를 위한 개발인지를 정확하게 구분하고 이를 정의해야 한다.


ㅇ 기반 기술 정의

  다음으로 해야 할 것은 개발기술에 대한 분석과 정의이다. 공개소프트웨어의 개발에 필요한 기반기술들을 간단히 정리하면 다음과 같다.

- 운영체제, 웹서버, DBMS, 사용언어등에 대한 기반기술 분석 및 정의
- 공용 framework 개발 및 업무 서비스 요구 분석 및 설계 기술
- 분산 DB 구축 설계 및 관리 기술
- 그룹웨어의  확장  및 공유   수준 지정에 의한 access 범위 설정 기술
- 유관 기관 간 정보 DB 표준화 (XML 기반)

  이와 같이 관련 기반기술들이 정의가 되어있어야하며 개발직원에 대한 교육과도 연계되어야 할 항목이다.


ㅇ 적용 업무에 대한 분석

  개발하려는 공개소프트웨어가 적용될 업무에 대한 기본적인 분석이 이루어 져야한다. 즉, 공개소프트웨어를 직접 개발하기 이전에 다음과 같은 사항들이 이미 검토되어야 한다.

- 활용성 : 개발 이후의 당기관 또는 유관기관에서의 활용성 검토해야 한다.

- 수요의 규모 : 개발한 공개소프트웨어의 수요정도에 대한 검토해야 한다.

- 재활용성 : 개발한 공개소프트웨어가 타 업무에 재활용될 수 있는 정도에 대한 검토. 여기에는 재활용의 용이성이 포함되어야 한다.

- 표준성 및 표준의 준수여부 : 적용 범위가 넓은 업무에 적용되기 위하여 표준성 및 표준의 준수여부를 검토해야 한다.


ㅇ 개발기간 및 투입인력 분석

  공개소프트웨어를 직접 개발하기 위해서는 개발기간과 투입인력에 대한 세심한 분석과 정의가 이루어져야 한다. 개발기간에 대한 정의는 다음을 고려하여 작성하도록 한다.

- 5단계 개발기간 분석
  . 요구분석기간, 분석기간, 개발기간, 수정및 검토기간, 적용및 안정화기간
  . 각 기간별 위험관리 대책 마련(개발기간의 준수여부에 따라 기간초과에 따르는 위험관리)

- 개발인력에 대한 대책
  . 기반 기술(주로 Language)에 가장 적합한 기술인력 활용
  . 개발경험이 있는 내부 개발직원 활용
  . 개발책임자(PM)을 선정하여 프로젝트로 진행
  . 개발분야에 따라 외부개발직원을 투입대책 마련
  . 개발자 교육 대책 마련


ㅇ 개발한 공개소프트웨어의 사후 관리문제

  내부개발에 의해 개발완료된 공개소프트웨어는 일회성 프로젝트로 끝나지 않도록 사후관리가 이루어져야 한다. 사후관리에는 개발직원에 대한 사후관리를 포함한다.

- 개발한 공개소프트웨어를 관리대장에 등록하여 지속적인 관리가 이루어지도록 한다.

- 개발시에 사용한 기술을 종합정리하여 이를 문서화 한다. 주로 업그레이드 및 패치 방법 및 적용방법등에 대한 문서를 포함한다.

- 개발한 공개소프트웨어의 설치문서, 사용법문서, 업그레이드문서등을 표준화하여 작성한다.

  지금까지 설명한 내부개발 방법을 설명하였다. 하지만 실제 국내 현실면에서 내부개발 방법으로 개발되는 경우는 찾아보기 힘들다. 기관 내부에 공개소프트웨어 개발자를 확보하기도 어려울 뿐아니라 개발 프로젝트 진행에 대한 프로젝트 실무자 또한 확보하고 있는 경우가 드물다. 개발자나 프로젝트 실무자를 확보하고 있다 하더라도 실제 진행을 위해서는 보직변경 및 장기간 동일업무 종사여건등과 같은 조직내부적인 환경이 갖추어져야 할 것이다. 결론적으로 내부개발의 방법으로 프로젝트를 진행하기란 현실적인 어려움들이 존재하는 것이 사실이고 이러한 현실적인 어려움을 극복하고 프로젝트를 진행한다 하더라도 개발 및 프로젝트 노하우의 축적이 지속되기란 더욱 어려운 실정이다.

  결론적으로 지금까지 설명한 직접선택, 간접공급, 내부개발 이 3가지 방법으로 공개소프트웨어를 도입할 수는 있지만 국내 공개소프트웨어 업계의 현실과 기관의 현실을 고려할 때에 가장 현실성있는 방법이 간접공급 방식의 도입이다. 나머지 두가지 도입방법이 좋다 나쁘다라는 의미가 아니라 현실적으로 선택가능한 방법이 간접공급 방식이며 또한 지금 현재 기관들에서 가장 일반적이고 광범위하게 사용되고 있는 방법이기도 하다.


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


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

 
박성수
파파
헐렁고수