온톨로지(Ontology)

: 사람들이 세상에 대하여 보고 듣고 느끼고 생각하는 것에 대하여 서로 간의 토론을 통하여 합의를 이룬 바를 개념적이고 컴퓨터에서 다룰 수 있는 형태로 표현한 모델.

 개념의 타입이나 사용상의 제약조건들을 명시적으로 정의한 기술이다.

 일단 합의된 지식을 나타내므로 어느 개인에게 국한되는 것이 아니라 그룹 구성원이 모두 동의하는 개념.

그리고 프로그램이 이해할 수 있어야 하므로 여러 가지 정형화가 존재

온톨로지는 일반성 수준이 낮은 것에서 높은 순으로 아래의 네 가지 구분이 될수 있다. 그리고, 추가적으로

 두 가지 다른 형태를 제시할 수 있다. 

1. 영역 온톨로지(Domain ontology)
   : 전자,의학,기계,디지털 영역과 같이 특정 영역에만 통용되는 지식을 표현한 온톨로지
2. 메타데이터 온톨로지(Metadata ontology)
   : 온라인 정보의 내용을 기술하기 위한 어희를 제공하는 온톨로지를 지칭한다.
3. 일반 온톨로지(Generic or common sense ontology)
   : 시간, 공간, 상태, 사건 등과 같은 사물의 기본적 관념과 개념을 제공하는 세상에 대한 일반 지식을 포함하는 온톨로지이며, 결과적으로 이 형태의 온톨로지는 여러 영역에 공통으로 적용될 수 있다.
   
4. 표현 온톨로지(Representational ontology)
   : 영역 온톨로지처럼 특정영역을 대상으로 하지 않으며, 무엇을 표현해야 하는지 언급하지 않고 표현개체(representational entities)를 제공하는 온톨로지.
   

* 추가적인 두가지 온톨로지는 방법 온톨로지(Method)와 과업 온톨로지(Task)다.

   전자는 특정 문제해결 방법(Problem Solving Method)에 제한된 용어(terms)를 제공하고,

   후자는 특정과업에 제한되는 용어를 제공한다.

시맨틱 웹(Semantic Web)

: 현재의 인터넷과 같은 분산환경에서 리소스(웹 문서, 각종 화일, 서비스 등)에 대한 정보와 자원 사이의 관계-의미 정보(Semanteme)를 기계(컴퓨터)가 처리할 수 있는 온톨로지형태로 표현하고, 이를 자동화된 기계(컴퓨터)가 처리하도록 하는 프레임워크이자 기술이다. 웹의 창시자인 팀 버너스 리가 1998년 제안했고 현재 W3C에 의해 표준화 작업이 진행중이다.

시맨틱 웹의 목표

: 지금과 같이 사람만이 웹에 산재한 정보의 의미를 파악하는 것이 아닌, 자동화된 기계가 해석할 수 있는 일종의 표준 의미정보 교환의 수단 이 되는 것이 시맨틱 웹의 목적이다. 시맨틱 웹의 이상향은, 인터넷에 방대한 양의 온톨로지가 산재하고, 이를 자동으로 해석하여 처리할 수 있는 에이전트 소프트웨어에 사람 또는 에이전트가 질의를 하면, 컴퓨터가 자동으로 분산된 온톨로지를 탐색하고 추론하여 원하는 결과를 돌려주는 것이다.

http://www.foaf-project.org/

FOAF is about your place in the Web, and the Web's place in our world. FOAF is a simple technology that makes it easier to share and use information about people and their activities (eg. photos, calendars, weblogs), to transfer information between Web sites, and to automatically extend, merge and re-use it online.

The Friend of a Friend (FOAF) project is creating a Web of machine-readable pages describing people, the links between them and the things they create and do.

http://techit.co.kr/8757 - 옛날에는 개발을 더 잘했는데… 

http://allofsoftware.net/entry/%EC%98%9B%EB%82%A0%EC%97%90%EB%8A%94-%EA%B0%9C%EB%B0%9C-%EC%9E%98%ED%96%88%EB%8A%94%EB%8D%B0

우리나라 많은 회사들은 소규모일 때 상당히 개발을 잘 하는 것처럼 보인다. 짧은 기간에 꽤 멋진 Software를 뚝딱 뚝딱 잘 만들어 낸다. 이러한 제품이 시장에서 통해서 회사가 성장을 하게 되면 그 이후로 이상하게 개발이 점점 더 어려워지게 된다.

옛날에는 고참 두 명이 이정도의 Software를 6개월만에 이렇게 잘 만들어 냈는데, 지금은 팀원이 10명이나 되고 프로젝트 기간도 과거보다 더 줬는데, 제품의 버그는 더 많고, 제품도 옛날보다 형편 없어 보인다고 한다. 점점 개발이 더 어려워지는 이유는 무엇일까?

두번째 시스템을 만드는 것은 첫번째 시스템을 만드는 것보다 훨씬 힘들다. 두번째 시스템은 첫번째 시스템을 유지보수 하면서 만들어야 한다. 첫번째 시스템에 버그가 많거나 커스티마이징 요구가 많아서 소스코드 브랜치라도 몇 개 존재하면 유지보수에 많은 노력이 들어가서 두번째 시스템에 많은 노력을 들이기 어려워 진다.

또한 두번째 시스템은 첫번째 시스템과 호환성을 고려해야 한다. 두번째 시스템은 첫번째 시스템을 사용하던 고객들의 수많은 요구를 수용해야 한다. 첫번째 시스템은 간단 명료한 기능의 매력으로 인해서 많은 사용자들이 사용을 했지만, 이를 사용하던 사용자들은 계속 요구사항을 요구하게 되고 이러한 요구사항을 적절히 조절하여 수용하는 것이 쉬운 일이 아니다.

두번째 시스템 개발에는 많은 개발자가 투입되고 특히 초급 개발자가 많이 투입되곤 한다. 소수의 개발자끼리 개발을 할 때는 커뮤니케이션 문제가 별로 발생하지 않았는데, 개발자 인원이 많아지면 기존의 주먹구구 방식으로 똑같이 개발을 하면 문제가 발생하지 않을 수 없다. 초급 개발자들은 자기 역할을 제대로 못하는 것 같고, 일이 효과적으로 분배가 되지 않아서 결국 소수의 고참 개발자들이 대부분의 개발을 하는 결과를 초래하기도 한다.

두번째 시스템은 아키텍쳐를 전면 개편하기도 한다. 첫번째 시스템을 개발해 놓고 계속 유지보수를 하면서 사용자의 요구사항을 하나씩 추가해 나가기 시작하면 기존의 아키텍쳐로는 한계라고 불평을 자주 하게 된다. 특히, 첫번째 시스템을 개발했던 개발자들이 퇴사한 상태라면 더욱 더 첫번째 시스템을 비난한다.

그러면서 두번째 시스템에는 완전히 새로운 아키텍쳐를 적용하곤 하는데, 그동안 엄청나게 많은 노력을 들인 첫번째 시스템을 버리고 기능도 몇 배로 많아진 두번째 시스템에 완전히 새로운 아키텍쳐를 적용하면 첫번째 시스템이 시장에서 안정화되면서 겪었던 시간과 노력의 몇 배를 다시 투입해야 한다. 이런 경우 프로젝트가 지연되기 일쑤이고, 출시 후에도 많은 버그와 고객의 불평으로 상당기간 고생을 하게 된다.

그럼, 어떻게 해야 과거처럼 개발을 착착 해낼 수 있을까?

조직이 커졌다면 당연히 시스템과 프로세스가 바뀌어야 한다.

과거에 소수 인원이 개발할 때는 주먹구구식으로 개발을 했어도 문제가 없는 것처럼 보이지만, 사실은 문제가 똑같이 있었는데, 워낙 인원이 적으니 서로 의견을 활발하게 주고 받으면서 문제를 해결해 온 것이다. 인원이 조금만 늘어도 이런 행운은 기대할 수 없다. 조직에 걸맞는 시스템, 프로세스를 적용해서 체계적으로 개발을 해야 한다.

첫번째 시스템도 이런 과정을 거쳐서 체계적으로 개발이 되었다면, 두번째 시스템 개발자들에게 비난을 덜 들을 수 있었을 것이다. 두번째 시스템 개발자들이 완전 새로 개발하려는 이유 중 하나가 첫번째 시스템에 대한 문서가 쓸만한 것이 없고, 아키텍처가 뒤죽박죽이라서 개선을 못하고 버리려고 하는 것이다.

회사가 켜졌을 때 문제 해결 차원에서 시스템과 프로세스를 갖출 것이 아니라, 1,2명이 회사를 시작하더라도 체계적으로 개발하는 것이 가장 좋은 방법이다. 이미 첫번째 시스템은 점점 뒤죽박죽이 되어가고 조직은 엉망이라면 시스템과 프로세스를 갖추는 일이 먼저 필요하다.

My IP Address, Whoami (Who am I?) - Your Online Information, Browser Headers, DNS, Whois, ISP

http://www.hashemian.com/whoami/

소프트웨어 프로세스 품질인증 - SP

http://www.software.kr/mbs/swkr/subview.jsp?id=swkr_020501000000

사업 개요

SW프로세스 품질인증(‘SP인증’)제도는 SW산업진흥법 제23조에 근거하여 국내SW기업의 SW사업 수행능력을 강화하고 SW사업의
부실방지를 목적으로 기업의 SW개발단계별 작업절차 및 산출물 관리 역량 등을 분석하여 SW개발 프로세스 역량수준을 평가·인증하는 제도입니다.

① 지식경제부(정책기관)
- SW프로세스 품질인증제도 관련 정책 수립, 인증기준 및 인증지침 고시 등

② 정보통신산업진흥원(인증기관)
- SW프로세스 품질인증 업무 전반을 주관
   (*인증심사 신청 접수부터 인증 사후관리까지)
- 인증심의회 운영
- 인증심사원을 통한 인증심사 실시

③ SW기업(인증신청인)
- SW프로세스 품질인증 신청
- 인증획득 후 인증표시에 대한 활용

http://www.software.kr/mbs/swkr/subview.jsp?id=swkr_020504000000

소프트웨어프로세스 품질인증 절차  ( 인증신청기업 안내 )

소프트웨어프로세스 품질인증 수수료  ( 인증수수료 납부기준 안내 )

[SERI] 중국의 4大 변화상과 기업의 대응

http://www.seri.org/db/dbReptV.html?menu=db02&pubkey=db20120724001