분산객체와 웹 서비스의 차이점

UP!/Web Service 2008. 8. 21. 14:09
               논문명 :  Web Services Are Not Distributed Objects
- Werner Vogels Cornell University -
 
1. 논문내용
많은 사람들은 웹 서비스가 분산객체기술의 한 부분에 의존한다는 점에서 분산객체의 진화라고 생각한다. 하지만 이런 오해는 전반적으로 퍼져있는 웹 서비스에 대한 오해의 한 부분에 불과하다.
 
   1.1 Fundamental Errors
많은 개발자와, 아키텍트, manager, 학회에서는 웹 서비스를 Corba, DCOM, RMI를 포함하는 분산객체의 일종으로 보고 있다. 그러나 이런 것은 과거에 실패한 분산객체 어플리케이션에서 해당되는 것이다. 이런 오해는 둘 다 공통 architectural view를 사용하기 때문인데 실제적으로 서로 다른 어플리케이션 타입이다.
웹 서비스는 XML문서, 문서 exchange 사용한 document-oriented computing 기반이다, 반면 분산객체의 경우에, 객체 instance를 요구하거나, 함수호출을 요구하거나, 결과값을 받거나, 객체인스턴트를 해체하기 위한 RPC를 사용한다.
 
1.2 Minimalist Web Service Model
웹 서비스의 대한 오해는 기본 개념의 이해가 적은 여론이나 제조업자의 책임이 있다.
 
웹 서비스의  3가지 컴포넌트
 - the service란  메시지를 트랜스포트, 어플리케이션 프로토콜을 통한 전송을 처리할 수 있는 일종의 소프트웨어이다. 우리는 컴포넌트가 어떻게 구성되었는지, 객체지향기술이 사용되었는지 알 필요가 없다. 유일한 요구 사항은 서비스가 잘 정의된 XML 문서를 잘 처리할 수 있어야 한다는 것이다. 
 
 - The XML document는 소비자가 서비스를 통해  프로세스를 처리하기 위해 모든 어플리케이션 정보를 포함하기 때문에 웹 서비스의 핵심이라고 할 수 있다.  웹 서비스가 처리해야 하는 문서는 흔히 XML 스키마로 통용된다.
 
 - address는 쉽게 생각해서 포트 참조자 이다.
또한 선택적으로 envelope가 있는데 이는 message-encapsulation protocol이다.
  
   1.3 The greatest threat to Web services' large-scale success is vendor politics
1.3.1 Web Service Are Just Like Distributed Objects
일반인으로 하여금 웹 서비스의 잘못된 개념을 갖게 하는 주된 이유는 많은 웹 서비스 툴 제작업자가 웹 서비스를 구현함에 편리한 분산객체기술을 제공했다는 것이다. 이런 단순화와 편리성은 사용자에게 구현의 편리함을 제공하지만, 개발자로 하여금 분산객체와 웹 서비스의 대한 명확한 개념의 전달을 막는 요인이 된다.
 
웹 서비스는 분산객체특성의 어떤 것도 공유하지 않는다. 또한 객체개념, 객체참조, 라이프사이클을 포함하지 않다. 웹 서비스는 method의 인터페이스로 특성 되지 않는다. 웹 서비스는 유일하게 XML 문서 및 문서 캡슐화를 다룬다.
 
웹 서비스는 대부분 분산객체 시스템에서 제공하는 기본적인 분산컴퓨팅기능을 어떤 것도 제공하고 있지 않다. 두 기술에 대한 주요한 차이점은  client 와 server, producer 와 consumer 사이에 어떻게 통신을 하는 가를 이해하면 분명해 진다.분산 객체 시스템에서 정보는 객체에서 제공하는 인터페이스를 통해 캡슐화가 되지만, 웹 서비스에서 정보는 XML 문서 디자인으로부터 캡슐화가 된다. 두 개의 기술 모두 같은 목적을 수행하기 위해 실행되지만, 서로 다른 기술을 사용한다. 웹 서비스와 분산객체기술은 잘 알려진 접근을 통해 서로 상호작용 가능할 수 있다. 첫째로 우리는 객체시스템(J2EE)으로부터 어떤 객체(CORBA, DCOM)를 캡슐화가 가능하다. 양자택일로 우리는 분산객체 시스템의 트랜스포트 LAYER와 같은 SOAP를 사용할 수 있다.
 
1.3.2 Web Services Are RPC for the Internet
RPC는 프로그램 언어 안에 실행 프로시저 콜을 사용하기 위한 네트워크 추상화를 제공한다. 기본적으로 웹 서비스는 XML 문서와 전송과 문서를 처리하기 위한 원격 서비스 ENTRY를 위한 네트워킹 추상화를 제공한다.  웹 서비스는 XML 문서 프로세서로 검토될 수 있다. 그러나 이런 패러다임은 현재 어플리케이션 개발에 통합하기는 어렵다. 현재 툴 제작자들은 웹 서비스를 단수화하기 위해 개발자들이  전통적인 프로시저를 콜을 적용할 수 있는 기반을 제공하는데 최선을 다하고 있다. 
 
1.3.3 Web Services Need HTTP
웹 서비스는 트랜스포트 불가론 자다. 이것은 우리가 트랜스포트 프로토콜이나. 어플리케이션 프로토콜을 통해서 웹 서비스를 접근할 수 있는 것이다. 웹 서비스의 경우는 메시지 전송을 위해 SOAP를 사용한다. 이는 웹 서비스가 메시지를 전송함에 있어 프로토콜이 HTTP에 국한될 필요는 없다는 것이다.  실제로 메시지를 보내기 위해서 SOAP를 사용한 TCP or UDP상세서 메시지를 보낼 수 있고 또 메시지는 E-MAIL에 SOAP 메시지를 캡슐화되어 SMTP로 전송될 수 있다.
 
1.3.4 Web Service Need Web Server
몇몇 사람들은 웹 서비스에서 웹을 뺄 것인지 그대로 둘 것인지에 대해 토론을 해 왔다. 웹 서비스의 개념을 명확히 하고자 했던 이런 노력은 실제적으로 더 많은 혼동을 일으켰다. 이들 enterprise 개념에서는 WEB이라는 용어를 사용하고 있지 않다. 그들은 웹 서버나 HTTP와 같은 기술에 의존하지 않기 때문이다. 
…
 
1.3.5 Web Service Are Reliable Because They Use Tcp
TCP는 메시지를 전송에 신뢰성을 보증해 준다. 이런 점에서 TCP를 사용하는 웹 서비스 또한 신뢰성을 보증해 주는 것처럼 보여 질 수 있다. 그러나 이런 것은 TCP 프로그램에 있어 부분적으로 신뢰성을 보증해 주는 것이다. 일반적으로 웹 서비스나 분산시스템은 end-to-end 신뢰성을 요구한다. TCP는 분실된 메시지에 대한 재전송을 통해 신뢰성 있는 통신을 가능하게 한다. 하지만 중복된 메시지에 대한 선별할 수 있어야 진정한 신뢰성 있는 통신이라고 할 수 있다.
신뢰성 있는 분산 시스템을 구축하고자 한다면 우리는 서버요구의 프로세스 상태를 받아야 한다.  문서 수신여부, 서버의 문서 소비에 대한 피드백 요구는 재전송 기술 선택과 지역 쓰레기 모음에 필수적이다. 또한 추가적으로 순서대로 메시지 처리에 대한 보증이 필요하다. 이런 보증들이 완벽히 추가 보안되지 않는다면, 웹 서비스는 신뢰성이 보증된다고 할 수 없다.
 
1.3.6 Debugging Web Services ls impossible
웹 서비스는 internet-scale 분산 컴퓨팅이 가능하기 때문에 웹 서비스 개발자는 전통적인 디버깅 과 모니터링 툴을 다룰 수 없는 문제에 직면했다. 비록 전통적인 툴은 이런 문제에 대한 약간의 도움이 되지만 미흡하다. 그래서 SOAP scope와 같은 새로운 진단 툴이 대두되었다.
 
1.4 Conclusions
웹 서비스는 분산컴퓨팅, 애플리케이션 영향, 시스템개발에 중요한 역할을 할 것이다. 산학에 종사하는 개발자, 연구자는 잘못된 웹 서비스의 개념을 버려야 하며, 우리는 제한된 기능과 실천 구조를 극복해야 한다. 모든 사람들이 웹 서비스를 분산객체 기술이 아닌 interoperable document-centric computing으로 인식한다면 웹 서비스 기술에 많은 노력을 기울이게 될 것이다.  
 

'UP! > Web Service' 카테고리의 다른 글

Web Service  (0) 2008.08.21
그리드 서비스를 위한 Repository 시스템 개발  (0) 2008.08.21
분산객체시스템 종류  (0) 2008.08.21
웹 서비스와 관련된 10가지 질문  (0) 2008.08.21
XML,SOAP,UDDI,WSDL  (0) 2008.08.21
Posted by 으랏차
,

분산객체시스템 종류

UP!/Web Service 2008. 8. 21. 14:08
출처 : http://ebiz.u-aizu.ac.jp/~paikic/ecswtech/ec_tech/oot/corba_iiop/corba_iiop_9.html
---------------------------
⑷ 분산 객체 종류
 ㈎ DCE(Distributed Computing Environment)
 OSF(Open System Foundation)에서 개발 되었고, 절차지향 기술 모델을 기반으로 하는 분산 환경의 표준이다. DCE는 RPC호출을 통한 풍부한 의미를 지원한다. DCE의 구성요소 다음과 같다.

        RPC
        디렉토리 서비스
        분산 시간 서비스
        멀티 쓰레드
        보안
        분산 파일 서비스

 ㈏ DCOM(Distributed Object Model)
 DCOM 은 원격 객체 액세스를 지원하는 마이크로소프트의 기술이다. 윈도우 환경에서 컴포넌트간의 연동을 위한 분산 객체 시스템이다. 네트웍 에서 원격 객체가 제공하는 서비스들을 요청하기 위해 클라이언트 응용프로그램을 사용하도록 지원한다. 객체들은 다수의 언어에서 작성 될 수 있으며 표준을 따르면 다른 객체에 의해 호출된다. 언어 독립성을 제공한다.

 ㈐ CORBA
 CORBA 는 비영리 단체인 OMG(Object Management Group) 에 의해 90년대 초반에 만들어졌다. CORBA는 객체 사이 의 통신을 위한 표준이다. CORBA의 핵심은 ORB (Object Request Broker)이다. ORB는 객체의 위치가 로컬 이나 네트워크 상에 관계없이 서비스를 요청하고 응답을 받을 수 있도록 지원한다. CORBA 지원 응용프로그램에 있는 클라이언트 는 객체의 위치는 물론 어떤 프로그래밍 언어로 객체가 작성되는지, 어떤 플랫폼에 객체가 상주하는지에 대한 정보를 가지고 있을 필요 가 없다. 따라서 CORBA는 객체 기반의 분산 시스템을 지원한다.

 ㈑ RMI(Remote Method Invocation)
 RMI 는 자바 기반 분산 객체 기술이다. Java RMI은 분산된 객체를 마치 로컬에 있는 객체를 다루듯이 사용할수 있으며 기존의 소 켓 프로그래밍과 같은 복잡한 설계 절차와 애러를 발생시키는 요인을 극소화 시켰다. 모든 네트웍 프로그래밍의 자세한 부분, 즉 소 켓 API 를 사용해서 구현되는 부분은 RMI package, client stub 그리고 server stub에 의해 숨겨진 다. RPC(Remote Procedure Call)와는 달리 RMI 는 Java VM 환경에서 실행된다. 따라서, 자바 이외 의 다른 언어는 지원하지 않는다. RMI의 특징은 객체지향 다형성을 제공한다.
 JavaRMI는 다음과 같은 특징을 갖는다.

        원격 호출의 제공
        서버에서 애플랫으로의 콜백 제공
        분산모델을 자바 환경으로의 통합
        분산 객체와 비분산 객체의 명확한 구분

 ㈒ 기타
 ① JOE
 썬에 의해 개발된 자바로 구현된 ORB이다. CORBA표준을 따르며, 썬 시스템에서 사용 가능하다

 ② NCA(Network Computing Architecture)
 오 라클의 네크웍 컴퓨팅 아키텍쳐는 클라이언트/서버 네트워크, 웹 그리고 인트라넷 상의 분산 객체 응용 프로그램을 개발하는데 적합 한 개방형 표준 프레임워크이다. CORBA의 IIOP를 기반으로 CORBA/COM 연결을 통해 ActiveX/COM을 통합하였 다.

 ③ Netscape ONE
 웹과 인트라넷 상에서의 분산객체 애플리케이션을 개발하기 위한 개방형 표준 프레임워크이다. CORBA와 IIOP는 그 핵심 요소를 이룬다.

 ④ OpenDOC
 애플 컴퓨터, IBM, 로터스 등에 의해 제안된 데스크탑 환경 내의 객체 요소이다.

 ⑤ SOM/DSOM
 SOM(System Object Model)과 DSOM(Distributed)은 IBM에 한정된 객체 프레임워크이다.

'UP! > Web Service' 카테고리의 다른 글

그리드 서비스를 위한 Repository 시스템 개발  (0) 2008.08.21
분산객체와 웹 서비스의 차이점  (0) 2008.08.21
웹 서비스와 관련된 10가지 질문  (0) 2008.08.21
XML,SOAP,UDDI,WSDL  (0) 2008.08.21
COBRA  (0) 2008.08.21
Posted by 으랏차
,

웹 서비스와 관련된 10가지 질문

UP!/Web Service 2008. 8. 21. 14:08
출처 : http://itroom.net/contentChannel/article.php?aca_idx=1&scol_serial=200210261348150000
--------------------

웹 서비스와 관련된 질문 중에서 가장 많이 언급되는 10가지 질문
본 기사는 웹 서비스와 관련된 질문 중에서 가장 많이 언급되는 10가지 질문에 대한 해답이다. 따라서 독자들은 웹 서비스 개요뿐만 아니라 좀더 세부적인 내용도 충분히 참고할 수 있을 것이다.
 
웹 서 비스는 분산시스템을 제작이 중요한 진화적 과정을 거치고 있다는 것을 의미한다. 그러나 사람들은 웹 서비스가 정확히 무엇을 말하 는 것이며 웹 서비스 프로토콜 스택(stack)이 무엇인지, W3C가 지원하고 있는 웹 서비스 표준이 존재하는지에 대해서는 잘 알 고 있지 못하는 것 같다.

본 기사는 웹 서비스와 관련된 질문 중에서 가장 많이 언급되는 10가지 질문에 대한 해답이다. 따라서 독자들은 웹 서비스 개요뿐만 아니라 좀더 세부적인 내용도 충분히 참고할 수 있을 것이다.

1. 웹 서비스란 무엇인가?

웹 서비스 정의에 대해 많은 논란이 있었다. 그렇지만 사람들의 공통적인 의견을 추린다면 웹 서비스란 인터넷을 통해 표준화된 XML 메시지 시스템을 사용하는 소프트웨어의 작은 조각이라고 말할 수 있다.

XML 은 웹 서비스의 모든 통신을 인코딩 하는데 사용된다. 예를 들어 클라이언트는 XML 메시지를 통해 웹 서비스를 시작하며 요청에 대 응하는 XML 응답을 기다린다. 결국 XML을 사용하여 모든 통신이 이루어지기 때문에 웹 서비스는 특정한 OS나 언어에 구애받 지 않는다. 이는 곧 자바와 펄(Perl)이 서로 통신할 수 있고 윈도우 애플리케이션과 유닉스 애플리케이션도 통신할 수 있다는 뜻 이다.

이러한 기본적인 정의 이외에도 웹 서비스는 아래와 같은 두 가지 추가적인 속성을 가지고 있다.
첫 째, 웹 서비스는 XML로 정의된 공개 인터페이스를 가진다. 인터페이스는 클라이언트가 사용할 수 있는 메소드를 정의하고 메소드 에 대한 용법을 설명한다. 현재 인터페이스 정의는 WSDL(Web Service Description Language)를 통해 서 이루어진다. (FAQ 7번 참고)
둘째, 웹 서비스를 작성한다면 그것을 발행(Publish)하기 위한 단순한 메커니즘 이 필요하다. 마찬가지로 인터페이스를 공개하거나 서비스를 사용하고자 하는 곳에 제공하기 위한 메커니즘도 필요하다. 현재 유력 한 웹 서비스 디렉토리 서비스 는 UDDI(Universal Description, Discovery, and Integration)을 통해 이루어지고 있 다. (FAQ 8번 참고)
웹 서비스는 현재 뉴스 배급회사와 같은 거대한 시스템을 비롯하여 날씨, 주식 정보, 배송추적 과 같은 세부적인 시스템에까지 운영되고 있다. 현재 사용가능한 웹 서비스의 범위를 보고싶다면 웹 서비스 디렉토리인 XMethods 를 방문해보자.

2. 웹 서비스에서 새로워진 점은? 

사람들은 지금도 RPC(Remote Procedure Calls)을 사용하고 있다. 그리고 과거에도 HTTP를 통해 RPC를 전달하는 방법을 모르고 있었던 것은 아니다.

그렇다면 과연 무엇으로 인해 웹 서비스가 과거 기술과는 달리 새로워졌다는 것인가? 정답은 XML이다.

XML은 웹 서비스의 핵심이며 RPC, 웹 서비스, 웹 서비스 디렉토리를 기술하는 공통 언어를 제공한다.

XML 이전에도 다른 애플리케이션 간에 데이터를 공유할 수 있었지만 XML은 이것을 좀더 쉽게 할 수 있게 해주었다. 같은 맥락으 로 웹 서비스 없이도 코드와 서비스를 공유할 수 있었지만 XML로 인해 같은 기능을 좀더 수월하게 수행할 수가 있게 되었다.

XML으로 모든 것을 표준화시킴으로써 서로 다른 애플리케이션은 좀더 편하게 상대방과 통신할 수 있고 이로 인해 소프트웨어에 대한 관심이 증가되고 있다.

3. 웹 서비스에 대한 글은 읽었지만 실제로 웹 서비스가 동작되는 것은 본적은 없다. 웹 서비스가 실행되는 것을 보여줄 수 있는가? 

웹 서 비스에 좀더 관심이 있다면 IBM Alphaworks 사이트에 있는 IBM 웹서비스 브라우저를 실행해 보아라. 이 브라우저 는 웹 서비스 데모를 제공하고 있다. 브라우저 화면 뒤에서는 SOAP, WSDL, UDDI 기술이 웹 서비스 검색과 실행을 위 한 단순한 plug-and-play 인터페이스를 제공하기 위해 작동되고 있다. 예를 들어 주식 시세 서비스, 교통 정보 서비 스, 날씨 정보 서비스를 발견했다면 각각의 서비스는 독립적으로 작동되기 때문에 건물 벽돌처럼 쌓을 수 있다. 그러므로 여러 개 로 된 서비스 결과를 마치 my.yahoo, my.excite처럼 하나의 페이지에 담을 수 있다.
--------------------------------------------------------------------------------

참고 기사: 아마존의 새로운 웹 서비스 사용하기

위에서 예로든 IBM Alphaworks 사이트 말고도 한빛미디어 네트워크 페이지에 등록된「아마존의 새로운 웹 서비스 사용하기」에서 웹 서비스에 대한 더 자세한 내용을 참고할 수 있습니다.
--------------------------------------------------------------------------------
4. 웹 서비스 프로토콜 스택(stack)은 무엇인가? 

웹 서비스 프로토콜 스택은 웹 서비스 정의, 발견, 실행을 위해 사용되는 프로토콜의 집합이다. 핵심 프로토콜 스택은 다음과 같이 4개의 층(layer)으로 이루어져 있다.
서비스 전송 계층: 애플리케이션 간 메시지 전송의 책임이 있다. 현재 HTTP, SMTP, FTP와 BEEP(Blocks Extensible Exchange Protocol) 같은 새로운 프로토콜을 포함한다.
XML 메시지 계층: 종단(end)에서 메시지가 해석되기 위해 공통된 XML 포맷으로 메시지를 인코딩 해야 하는 책임이 있다.
서비스 기술(description) 계층: 웹 서비스를 설명하기 위해 공개 인터페이스를 기술해야 하는 책임이 있다. 현재 WSDL이 사용된다.
서비스 발견(discovery) 계층: 공통 레지스트리로 서비스를 집중화시키거나, 발행(publish)/검색(find) 기능을 제공해야 하는 책임이 있다. 현재 UDDI가 사용된다.
웹 서 비스의 본질을 이루고 있는 XML-RPC, SOAP, WSDL, UDDI 이외에도 웹 서비스 프로토콜 스택 은 WSFL (Web Services Flow Language), SOAP- DSIG (SOAP Security Extensions: Digital Signature), USML (UDDI Search Markup Language) 과 같은 새로운 프로토콜을 포함하고 있다. 이러한 프로토콜을 자세히 알려면 오라일리 on XML.com에 있 는 Pavel Kulchenko의 기사 「Web Services Acronyms, Demystified」를 참고하기 바란다.

다행하게도 웹 서비스를 구현하기 위해서 이러한 전체 프로토콜 스택을 이해 해야 할 필요는 없다. HTTP에 대해서 알고 있다면 XML 메시지 층위에서 웹 서비스를 실행해 볼 수 있기 때문이다.

--------------------------------------------------------------------------------
참고 도서
Web Services Essentials
Ethan Cerami
--------------------------------------------------------------------------------

5. XML-RPC는 무엇인가?

XML-RPC는 RPC를 수행하기 위해 XML 메시지를 이용하는 프로토콜이다. 요청은 XML로 인코딩 되며 HTTP POST 메소드를 통해 전송된다. XML 응답은 HTTP 응답 메시지 안에 포함되어 있다.

좀더 보기 쉽게 표현한다면 "XML-RPC = HTTP + XML + RPC"라고 할 수 있다.

XML-RPC는 플랫폼 독립적이기 때문에 다양한 애플리케이션과 통신 할 수 있다. 예를 들어 자바 클라이언트는 XML-RPC를 통해 펄 서버와 대화 할 수 있다.

XML-RPC를 좀더 빨리 이해할 수 있게 날씨 정보 서비스에 대한 XML-RPC 요청(request) 예를 들어보겠다. (HTTP 헤더는 생략)

   weather.getWeather
 
     
10016
   
요청은 단순한  요소로 이루어져 있다. 이것은 메소드 이름(getWeather)과 메소드 파라미터(zip code)를 가지고 있다. 날씨 정보 서비스에 대한 XML-RPC 응답(response)은 다음과 같다.
     
         65

응답은 리턴 값(현재 온도)을 포함하고 있는 하나의  요소로 구성되어 있다. 이 경우에 리턴 값은 정수 값이다.

다양한 방법으로 XML-RPC는 SOAP보다 단순해 질 수 있기 때문에 웹 서비스를 가장 쉽게 시작할 수 있는 방법이다.

공 식적인 XML-RPC 스펙은 XML-RPC.com에서 참고할 수 있다. 위 사이트에서는 펄, 파이썬, 자바, 루비(Ruby)로 이 루어진 XML-RPC를 시험해 볼 수 있다. 완전한 실행 목록을 보려면 XML-RPC 홈페이지를 방문해 볼 것을 권장한다.

6. SOAP은 무엇인가? 

SOAP 은 컴퓨터 사이에서 정보를 교환하기 위한 XML 기반 프로토콜이다. 비록 SOAP이 다양한 메시지 시스템에서 사용될 수 있고, 다 양한 전송 프로토콜 위에서 전달될 수 있지만, 중요한 것은 HTTP를 통해 RPC가 가능하다는 것이다. XML-RPC처럼 SOAP 도 플랫폼 독립적이기 때문에 다양한 애플리케이션의 상호통신이 가능하다.

이해를 돕기 위해서 날씨 정보 서비스 요청에 대한 SOAP 메시지 예를 살펴보도록 하자. (HTTP 헤더는 생략)


   xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   
     
         xmlns:ns1="urn:examples:weatherservice"
         SOAP-ENV:encodingStyle=" http://www.w3.org/2001/09/soap-encoding
         10016
 


보 다시피 이 요청은 XML-RPC보다 다소 복잡하고 XML 네임스페이스와 XML 스키마를 사용하였다. XML-RPC와 비슷하게 요청 의 바디부분은 메소드 이름(getWeather)과 파라미터 목록(zipcode)을 가지고 있다.  
   
Programming Web Services with SOAP

날씨 정보 서비스 SOAP 응답은 다음과 같다.

   xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   
     
         xmlns:ns1="urn:examples:weatherservice"
         SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding">
         65



응답은 단순한 정수 리턴 값(현재 온도)을 나타내고 있다.

W3C 는 SOAP 표준 제정을 진행하고 있다. 최근 개발 초안은 SOAP 1.2 이며 두 부분으로 나뉘어 졌다. Part 1 은 SOAP 메시지 프레임워크와 엔빌로프(envelop) 스펙을 기술하고 Part 2는 SOAP 인코딩 법칙과 SOAP-RPC 규 약, HTTP 바인딩을 기술하고 있다.

7. WSDL은 무엇인가? 

WSDL(Web Services Description Language) 은 현재 웹 서비스 프로토콜 스택 층 위에서 서비스 기술(description)층을 나타내고 있다. 간단히 말해 WSDL란 웹 서 비스의 공개 인터페이스를 설명하기 위한 XML 문법이다. 공개 인터페이스는 다음과 같은 것들을 포함한다.
- 공개적으로 사용할 수 있는 기능들의 정보
- XML 메시지를 위한 데이터 타입 정보
- 사용된 전송 프로토콜에 관한 바인딩 정보
- 특정한 서비스 위치에 관한 주소 정보
WSDL은 XML 메시지 시스템에 꼭 필요한 것은 아니지만 SOAP 메시지를 기술하기 위한 빌드인 익스텐션(built-in extensions)을 포함하고 있다.

다음은 WSDL 예제이다. 이것은 이전 SOAP 예제에서 사용된 날씨 정보 서비스에 대한 공개 인터페이스를 기술하고 있다. 이 예제를 이해하려면 많은 것을 알아야 하지만 일단은 두 가지만 생각해보자.
첫째,  요소는 컴퓨터사이에서 전송되는 각각의 XML 메시지를 설명한다. 이 경우에는 getWeatherRequest, getWeatherResponse를 가지고 있다. 둘째,  요소는 SOAP과 특정 URL을 통해서 사용 가능한 서비스를 설명하고 있다.


   targetNamespace="http://www.ecerami.com/wsdl/WeatherService.wsdl"
   xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:tns="http://www.ecerami.com/wsdl/WeatherService.wsdl"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   
     
         transport="http://schemas.xmlsoap.org/soap/http"/>
         
         
           
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:weatherservice"
               use="encoded"/>
         
           
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:weatherservice"
               use="encoded"/>
   
      WSDL File for Weather Service
     
         
            location="http://localhost:8080/soap/servlet/rpcrouter"/>
 
WSDL 을 사용해서 클라이언트는 웹 서비스의 위치를 지정할 수 있고 공개적으로 사용 가능한 기능들을 불러 낼 수도 있다. WSDL을 감지 하는 유틸리티를 통해 모든 프로세스는 자동적으로 수행되며 새로운 서비스는 부가적인 작업 없이 쉽게 애플리케이션에 통합 될 수 있 다. 예를 들자면 Mind Electic사의 GLUE 플랫폼을 참고하기 바란다.

WSDL은 W3C에 제출되었지만 현재까지 공식적인 위치를 가지고 있지 않다. 최근 초안인 W3C 페이지를 참고하기 바란다.

8. UDDI는 무엇인가? 

UDDI(Universal Description, Discovery, and Integration)는 웹 서비스 프로토콜 스택에서 서비스 발견 계층을 나타낸다.

UDDI는 원래 마이크로소프트(Microsoft), IBM, 아리바(Ariba)에 의해서 만들어 졌고, 웹 서비스와 비즈니스를 발행(publish)/검색(Find)하기 위한 기술적인 스펙을 나타낸다.

UDDI는 다음과 같이 두 부분으로 구성되어 있다.
첫 째, UDDI는 비즈니스와 웹 서비스에 대한 분산 디렉토리를 만들기 위한 기술적인 스펙이다. 데이터는 특정한 XML 포맷으로 저장 되고, UDDI 스펙은 존재하는 데이터를 검색하고 새로운 데이터를 발행하기 위한 세부적인 API를 포함하고 있다.
둘 째, UBR(UDDI Business Registry)는 UDDI 스펙에 대한 완전한 실행 방법이다. 2001년 5월 마이크로소프 트와 IBM에 의해서 시작된 UDDI 레지스트리는 누구나 UDDI 데이터를 검색해 볼 수 있고 기업은 그들의 서비스를 등록할 수 도 있다. 그리고 UDDI의 데이터의 범주를 크게 나누면 다음과 같이 세 가지 카테고리로 나뉜다.








White 페이지: 회사에 대한 일반적인 정보를 포함하고 있다. 예를 들면 비즈니스 이름, 비즈니스 세부내용, 비즈니스 주소가 있다.








Yellow 페이지: 회사나 서비스가 제공하는 분류된 데이터를 포함하고 있다. 예를 들면 표준 분류법을 토대로 산업별, 제품별, 지리적 코드별로 나뉜 데이터를 가지고 있다.







Green 페 이지: 웹 서비스에 대한 기술적인 정보를 포함하고 있다. 일반적으로 외부 스펙을 가리키거나 웹 서비스 호출에 대한 주소를 가지 고 있다. 마이크포소프트 UDDI 사이트, IBM UDDI 사이트를 참고하고 완전한 UDDI 스펙은 uddi.org에서 사용 할 수 있다.  
















9. 웹서비스를 어떻게 시작할 것인가? 

웹 서 비스를 시작하는 가장 쉬운 방법은 XML-RPC를 이용하는 것이다. XML-RPC 스펙이나 필자 의 책 『Web Service Essentials』나 사이먼 세인트 라우런트(Simon St. Laurent), 조 존스턴 (Joe Johnston), 에드 덤빌(Edd Dumbill)이 함 께 쓴 『Programming Web Services with XML-RPC』를 참고하자.

일단 XML-RPC의 기 초를 익히고 난 후 SOAP, WSDL, UDDI를 차근차근 배우면 된다. 이러한 주제들은 모 두 『Web Service Essentials』에서 다루고 있다. SOAP에 대해 더 자세한 내용을 알고 싶다면 더그 디드웰 (Doug Tidwell), 제임스 스넬(James Snell), 파벨 쿨첸코(Pavel Kulchenko) 가 쓴 『Programming Web Services with SOAP』을 참고하면 된다.

10. W3C는 웹 서비스 표준을 지원하고 있는가? 

W3C(World Wide Web Consortium) 는 활발하게 웹 서비스 프로토콜 표준화를 추진하고 있다. 2000년 11월 W3C는 XML Protocol Activity를 설립 했다. 이 그룹의 목표는 SOAP의 정식 표준을 제정하는 것이다. SOAP 1.2 초안은 현재 검토 중이며 공식적인 W3C의 권 고 안을 통해 진행중이다.

2002년 2월 25일 W3C는 Web Service Activity 조직 편성을 발표하 였다. 이 새로운 조직은 두 개의 새로운 작업 그룹뿐만 아니라 현재의 SOAP 작업그룹도 포함하고 있다. 첫 번째 그룹은 WSDL 에 관한 웹 서비스 기술 작업과 관련된 것이며, 두 번째 그룹은 웹 서비스 프로토콜 프레임워크에 대한 웹 서비스 구조를 만드는 활 동이다.

W3C의 Web Service Activity에 대한 더 자세한 정보를 얻고 싶다면 오라일리 XML.com 을 들어가서 에드 덤빌(Edd Dumbill)의 기사 「Welcome Web Services Activity」를 참고하기 바란 다.

'UP! > Web Service' 카테고리의 다른 글

그리드 서비스를 위한 Repository 시스템 개발  (0) 2008.08.21
분산객체와 웹 서비스의 차이점  (0) 2008.08.21
분산객체시스템 종류  (0) 2008.08.21
XML,SOAP,UDDI,WSDL  (0) 2008.08.21
COBRA  (0) 2008.08.21
Posted by 으랏차
,

XML,SOAP,UDDI,WSDL

UP!/Web Service 2008. 8. 21. 14:08
웹서비스는 커뮤니케이션의 형태가 웹이 출현하면서 Person to Person에서 Person to Machine으로 진화되었고, 이제 다시 Machine to Machine(빌 게이츠는 Software to Software라고 표현한다)으로 인간의 수작업 이 최소화 되고 Application 간의 커뮤니케이션이 이루어지는 것을 의미한다.

이미 구축된 HTTP라는 인프라 를 그대로 사용하면서 XML, SOAP, WSDL, UDDI를 통해 이를 가능토록 한다는 것인데 XML은 모르는 분이 없으실테 고, SOAP(Simple Object Access Protocol)은 한마디로 메세징 프로토콜로 상세한 구현절차에 상관 없이 데 이터 간의 커뮤니케이션을 가능케 하는 효과적인 패키저의 역할을 수행하는 프로토콜이다.

서비스 제공자는 요청자의 구현절차에 대해서는 아무 런 정보도 알지 못하고 서비스 요청자와 서비스 제공자 모두 요청 및 응답 메시지의 형태와 내용 밖에는 아무 것도 모르기 때문에- 알 필요가 없기 때문에- 작업을 단순화시켜 주는 요인이 된다. 즉,SOAP을 사용하면 프로토콜을 맞추기 위해 개발자 간의 약속 이 더 이상 필요 없게 된다. 웹 서비스 구현은 요청 및 응답 메시지가 변경되지 않는 한, 해당 서비스의 이용자에게 아무런 영향을 주지 않고 변경이 가능하다. 대신 기존 코드를 SOAP으로 감싸주는 박막 작업이 필요 하며 새로운 코드로 바뀌더라도 관련 변경 작업은 서비스 이용자에게 노출되지 않는다.

UDDI(Universal Description, Discovery, and Integration) 는 과거 야후!와 비교될 수 있다.1994년 야후!가 웹를 통해 사용자가 원하는 정보 리스트를 찾을 수 있는 방법을 제시했다 면 UDDI는 웹기반의 소프트웨어가 다른 소프트웨어와 어떻게 연결될 수 있는지를 제시한다.

UDDI는 일종의 애플리 케이션의 야후!로 이 레지스트리를 통해 필요한 서비스를 검색하고 활용할 수 있는 방법을 알 수 있으며 이런 UDDI의 특성으로 인 해 벌써부터 일부 전문가들은 UDDI가 Integration Broker로 발전될 것이라는 전망을 내 놓기도 한다.

분 명히 UDDI 는 enterprise application integration, supply chain management, collaborative planning 등 의 영역에서 다이나믹한 변화들을 만들어 낼 것이라고 예상된다. 아리바나 커머스원등의 B2B 서비스업자
들은 비용절감 효과를 극대화 하면서 그들의 비즈니스를 보다 풍부하게 할 수 있을 것이고 반면에 Tibco와 같은 XSP들은 자체적인 UDDI 레지스트리 구축을 신중히 검토해야 할 것이다.

UDDI 에 등록하는 것은 누구나 가능하며 그 방법은 야후!에 등록하듯 등록하는 방법이 있고 IBM이나 MS에서 제공하는 툴키트를 다운로 드 하여 UDDI 공개 API들을 사용하여 등록하는 방법이 있는데 후자의 방법이 빠를 뿐만 아니라 늘 신선한 레지스트리를 유지시 킬 수도 있기 때문에 앞으로 이 방법이 선호될 것으로 예상된다.

WSDL(Web Service Definition Language) 은 말 그대로 웹 서비스를 정의하는 언어로 UDDI에서 서비스를 이용하고자 하는 사용자가 해당 서비스의 형태가 어떻게 생겼다는 것 을 알 수 있게 XML로 정의된 것을 의미한다.

앞에서 웹서비스의 근간이 되는 기술 이슈들에 대해 간단하게 살펴 보 았다.그런데 하나하나의 기술 단어들만 나열하고 있으면 좀처럼 감이 오질 않는다.그러니까 XML,SOAP,UDDI,WSDL에 대 해 각기 풀다보면 한 눈에 들어오지 않는 것이 사실이다. 웹서비스를 유기적으로 다시 구조를 짜 맞추면 이해하기가 한결 수월한데 그것은 아래와 같이 4개로 표현될 수 있다.

1.Lookup and discovery(such as Universal Description, Discovery, and Integration-UDDI, a mechanism for locating services and discovering what they do)
2.Description(a way of description what input and outputs the services recognize Web Services Description Language-WSDL)
3.Transport(the means of sending messages between services-Simple Object Access Protocol-SOAP)
4.Environment(the facility for developing and deploying the services-Visual Studio .NET,WebSphere, WebLogic...)

위 의 유기적인 웹서비스 시스템이 구축되어진다면 웹을 통해 서비스를 판매하고자 하는 업자는 이제 자신이 구축해야 할 서비스들의 목록 을 구분하고 그것을 다 시 Core Services, Infrastructure Services, Application Services로 나눌 수 있 을 것이고 그 중 Application Services는 UDDI를 통해 개발이 아닌 임대를 하여 서비스를 할 수 있을 것이다.

지금까지 이야기 한 것을 바탕으로 웹서비스의 혜택을 표현하면 이렇다.

"Web Service Benefits include faster time to market, convergence
of disparate e-business initiatives, significant reduction in cost of ownership, real-time updating and dynamic linking of partner than IT staffs, automates the process of linking business partners and their core competencies across a value chain quickly and efficiently on the Internet".

Web Service에 대한 컬럼을 마치면서 davidndanny는 다음과 같이 3가지 제안을 하고자 한다.

1. 새로운 서비스 브로커들은 그들의 사적인 네트워크를 통해 밸류체인을 다시 배열하고 새로운 멤버들이 합류할 경우 비용 효율적이고 빠 른 방법으로 통합된 서비스를 제공할 능력을 보유해야만 한다.뿐만 아니라 새로운 서비스 브로커들의 자격은 서비스 보증에 대한 합리 적 방안,법적 문제에 대한 노하우를 포함한다.
2. 포탈은 애플리케이션 벤더들과의 Application 협업 시스템을 신속히 구축하고 그에 따르는 지적 재산권,사용 범위 등을 규정하는 가이드라인을 공표하여 현재의 Text data를 제공하는 구조에서 벗어나
다이나믹한 서비스를 제공할 방법에 대해 집중적으로 고민해야 한다.

3. 정부는 관련 기관들과 긴밀히 협조하여 Web Service 표준 규약에 적합한 형태의 한국형 UDDI를 신속히 구축,웹서비스 인프라를 만들어야 하며 또한 국제적인 홍보에 앞장서야만 한다.

http://ibiznet.inews24.com/column/column_view.php?key=2258&cate=030100

'UP! > Web Service' 카테고리의 다른 글

그리드 서비스를 위한 Repository 시스템 개발  (0) 2008.08.21
분산객체와 웹 서비스의 차이점  (0) 2008.08.21
분산객체시스템 종류  (0) 2008.08.21
웹 서비스와 관련된 10가지 질문  (0) 2008.08.21
COBRA  (0) 2008.08.21
Posted by 으랏차
,

COBRA

UP!/Web Service 2008. 8. 21. 14:06
*** CORBA(Common Object Request Broker Architecture)

1989 년대에, 현존하는 객체지향 기술을 바탕으로 응용 프로그램들을 결합하기 위한 객체지향 표준을 제정하기 위 해 OMG(Object Management Group)가 탄생하였다. OMG는 700개 이상의 컴퓨터 관련 단체들이 참가하여 객체 지향 기술을 기반으로 이종의 분산된 환경 하에서 응용 프로그램들을 통합하고 상호연동할 수 있는 표준기술을 제정했는데, 바로 이 표 준이 OMA(Object Management Architecture)이다.

OMA는 응용 프로그램간의 통합뿐만 아니 라 객체의 생성, 소멸에서부터 저장, 트랜잭션(transaction) 기능에 이르기까지 분산 객체 환경에서 필요한 모든 서비스 를 총칭하는 것이다. 이들 기능 중 CORBA는 컴퓨터 내부의 Bus처럼 서로 다른 프로그램들 사이의 Bus 역할을 하는 모듈로 서 프로그래머가 원하는 메소드 등의 위치에 관계없이 마치 로컬에 있는 것처럼 사용할 수 있도록 하는 기능을 제공한다. 따라 서 CORBA는 OMA에서 가장 중요한 요소가 된다.

CORBA는 어플리케이션으로 하여금 한 operation이 분산 객체에 의해서 수행되게 하며, 그 operation의 결과에 대하여 그 요청을 만든 어플리케이션에게 리턴하도록 한다. 이것은 기본 적인 클라이언트/서버 기능이며, 클라이언트는 요청을 만들어 서버에게 주고 그 서버는 그 요청에 대해 응답한다. 데이터는 클라이언트 로부터 서버로 전달되며, 그 데이터는 특정 객체의 특정 operation으로 구성되어 있다. 데이터는 그러고 나서 응답의 형태 (form)로 클라이언트에게 리턴된다.

CORBA를 사용함으로써 다음과 같은 이점을 얻을 수 있다.
1. CORBA는 많은 언어를 지원한다. CORBA는 또한 하나의 분산 어플리케이션에서 이것을 혼합된 형태로도 지원한다.
2. CORBA는 분산과 객체 지향을 지원한다.
3. CORBA 는 산업 표준이다. 이것은 벤더들 사이에서의 경쟁을 유발하고 질좋은 구현들이 존재할 수 있도록 해준다. CORBA 표준은 또한 개발자들에게 구현들 사이에서의 일정 수준의 portability를 제공한다.
4. CORBA는 고수준의 상호작용성을 제공한다. 이것은 서로 다른 CORBA제품에서 만들어진 분산 객체들이 서로 통신 할 수 있도록 한다.


* 참조 사이트

1. Corba Homepage
   http://www.corba.org

2. OMG Homepage
   http://www.omg.org/

3. OMG Korean Working Group
   http://dpnm.postech.ac.kr/komg/

*** OMG에 대해

OMG 는 지난 89년 5월 8개 회사(3Com, 아메리카 온라인, 캐논, 데이터 제너럴, HP, 필립스 텔레커뮤니케이션즈, 썬 마이크로 시스템즈, 유니시스)가 주축이 돼 설립했다. 그 해 10월 비영리 집단으로서 독립적인 활동을 시작했다. 기술적으로 훌륭하며 상업적 으로 가치가 있고 소프트웨어 산업에서 벤더 독립적인 것을 개발하기 위한 노력으로 현재 OMG의 회원은 800개사를 넘어섰 다. OMG에서는 분산객체 관리 시스템의 요구 사항을 충족시키기 위해 CORBA를 제안했다. 이러한 디자인 과정에서 OMG가 무게 를 두고 있는 부분은 완전히 개방된 객체 구조를 생성한다는 점이다. 즉, 현재의 소프트웨어는 기본적으로 이식성 (portability)과 상호 운용성(interoperability)을 가져야 한다는 요구 조건을 기본으로 하고 있다.

OMG가 제안한 표준은 현재 대다수의 컴퓨터 회사나 연구 분야에서 받아들여지고 있는데 그 성공 비결은 다음과 같다.

OMG 는 프로그램 코드 자체를 제안하는 것이 아니라 인터페이스 명세만 제안한다. 이 인터페이스 명세 는 IDL(Interface Definition Language)이라는 특정 프로그래밍 언어에 종속되지 않는 독립적인 언어이며 특 정 운영체제 또는 네트워크에 종속되지 않는다.

각 ORB 구현 제품은 CORBA 2.0/2.3/3.0 명세를 따르면 이 제품들 간에 상호 운용할 수 있다.

OMG 는 세계 표준인 CORBA/IIOP, 객체 서비스, 인터넷 퍼실리티(Internet Facilities), 도메인 인터페이스 규격 (Domain Interface Specification)을 통해 '세상 어디서나 사용하는 미들웨어'라는 슬로건을 내걸고 발전 해 나가고 있다.

OMG는 표준화 객체 소프트웨어의 도입을 통해 컴포넌트 기반의 소프트웨어 시장을 형성하는 역할을 했 다. 즉, 애플리케이션 개발을 위한 공통적인 프레임워크를 제공하기 위해 세부적인 규격을 제정하고 있는 것이다. OMG에 대 한 더 많은 정보는 OMG 홈페이지(www.omg.org)를 참고하기 바란다.

*** CORBA의 각종 서비스

CORBA 의 서비스에 대한 일반적인 정의를 내리자면, ORB를 이용해 소프트웨어를 개발할 때 개발된 코드를 재사용하기 위해, 개발 소프트웨 어 도메인에 독립적으로 작업할 수 있는 프로그램을 말한다. 이것은 개발에 필요한 중요한 문제를 해결하기 위해 여러 중요한 기능 을 한 가지씩 담당할 수 있게 만들어졌고, 이 서비스들을 조합해 당면한 문제들을 해결할 수도 있다. 현재 OMG는 15개 의 CORBA 서비스 규격을 발표했다.

*** COSS1에 정의된 CORBA 서비스

* 명명 서비스 (Naming Service) : 객체 정보의 등록 및 검색과 관련된 기능을 제공하는 서비스로 네트워크에 산재돼 있는 구현객체들 이 자신의 정보를 등록하고, 클라이언트 프로그램들은 자신이 필요한 구현객체의 정보를 이름으로 검색, 구현객체 정보를 취득한다. 취 득한 구현객체의 정보로 구현객체에 접근할 수 있도록 해주는 서비스가 명명 서비스다.

* POS 서비스 : POS 는 CORBA 객체가 종료돼도 객체의 상태를 유지 관리해주는 서비스다. 클라이언트 프로그램은 이 POS를 이용해 객체의 현재 상태 를 다른 매체에 저장하고 필요할 때 PID를 이용, 저장된 객체를 복구해 사용할 수 있다.

* 생명 주기 서비스 (Life Cycle Service) : 이 서비스는 객체의 초기 생성부터 소멸되는 시점까지 일련의 객체 생명 주기를 관리하는 서 비스로, Naming, Externalization, Relationship 서비스와 연계해 사용한다.

* 이벤트 서비스(Event Service) : 이벤트 서비스는 객체들간의 이벤 트 메시지를 처리할 수 있는 서비스로, 객체들 간의 콜백 기능을 이벤트 서비스로 대치해 사용할 수 있다.

*** COSS2에 정의된 CORBA 서비스

* 트랜잭션 서비스(Transaction Service, OTS) : OTS는 객체의 트랜잭션을 관리하는 서비스로 RDB에서 트랜잭션을 관리하듯이, CORBA 객체에 대한 트랜잭션을 처리할 수 있게 지원하는 서비스다.

* 동 시 동작 제어 서비스(Concurrency Control Service) : 객체들의 특정 자원에 대한 동시 접근을 제어하는 서비 스다. 예를 들어, 프린팅하는 기능을 갖는 구현객체가 프린터를 사용중일 때 다른 객체가 프린터를 사용하지 못하게 하고, 먼저 프린 터를 사용하는 객체가 프린터를 독점하지 못하게 제어하는 기능을 지원하는 서비스다.

* 관계 서비스(Relationship Service) : 객체 사이의 관계를 관리하는 서비스로 디자인 시에 작성된 관계 외에도 관계가 없는 객체 사이를 런타임에 관계를 설정할 수 있게 지원하는 서비스다.

* 외 부화 서비스(Externalization Service) : 객체 상태의 저장 및 재생을 지원하는 서비스로 POS는 플랫 파 일, 관계형 데이터베이스, 객체 데이터베이스 등을 사용해 관리하지만 이 서비스는 객체 상태를 스트림화하기 때문에 다양한 방법으 로 저장하고 나중에 재생해 사용할 수 있는 기능을 지원한다.

*** COSS3에 정의된 CORBA 서비스

* 보 안 서비스(Security Service) : CORBA 객체들의 보안을 관리하는 서비스로 네트워크를 기반으로 하는 분산 환경에 서 시스템을 공격하고자 하는 사람, 부적절한 방법으로 시스템을 이용하는 사용자에 의해 발견될 수 있는 모든 보안 구멍 (security holes)을 막도록 설계했으며 안전한 환경에서 상호 작용하는 객체가 보안 정책이 집행 중이라는 사실 을 알 수 없도록 설계돼 있다.

* 시간 서비스(Time Service) : 분산된 객체간의 시간 동기화를 관리하 는 서비스다. 예를 들어, 서울과 미국에서 9시에 어떤 통계 작업을 진행하고자 할 때 서로 시각에 대한 개념이 다르기 때문에 집계 가 잘 안 될 수 있다. 이때 이 서비스를 통해 서로의 시간을 동기화할 수 있으면 정확히 9시에 통계 작업이 진행돼 원하는 결과 를 얻을 수 있을 것이다.

*** COSS4에 정의된 CORBA 서비스

* 질의 서비스 (Query Service) : 질의문을 사용, 객체를 검색하는 기능을 갖는 서비스로 질의문에서 작성된 기준에 만족하는 어트리뷰트 를 갖는 객체를 검색해 낼 수 있다. 이 서비스에서 사용하는 질의문은 SQL이나 OQL 중 하나를 사용할 수 있다.

* 라 이선싱 서비스(Licensing Service) : 사용자가 객체를 사용하기 위한 라이선스를 관리하는 서비스로, ORB 기반의 컴 포넌트를 개발하고 서비스를 제공하는 제공업자가 사용자들이 사용한 컴포넌트들에 대한 사용 대가를 회수할 때에 필요한 자료 및 기능 을 제공하기 위해, ORB 기반의 컴포넌트 사용에 대한 라이선스를 관리하는 서비스다.

* 프로퍼티 서비스 (Properties Service) : 객체의 동적 프로퍼티를 생성하고, 이를 관리하는 서비스다. 이미 IDL에 정의되어 있 는 객체에 프로퍼티를 추가할 경우 보통의 경우 해당 객체의 IDL을 수정, 다시 컴파일해 사용해야 한다. 하지만 이 서비스를 사용 하면 런타임에 특정 객체의 프로퍼티를 동적으로 생성해 사용할 수 있는 기능을 지원한다.

*** COSS5에서 정의된 CORBA 서비스

* 트 레이더 서비스(Trader Service) : 객체를 등록하고, 검색할 수 있도록 지원하는 서비스로 Exporter가 트레이더에 게 기능 정보를 제공하면, Importer가 필요한 기능을 질의문으로 만들어 객체 정보를 검색하는 서비스다. 이 서비스를 사용하 면, Exporter가 제공하는 기능 정보를 Importer가 트레이더를 통해 필요한 기능의 객체를 검색하고, 검색된 객체 정보 를 이용해 네트워크에 분산돼 있는 구현객체에 접근, 필요한 기능을 사용할 수 있다.

* 컬렉션 서비 스 (Collection Service) : 이 서비스는 객체들에 대한 리스트 관리를 지원하는 서비스로, 동일한 객체들을 일렬 로 묶거나(list), 서로 다른 객체들을 꾸러미(bag)로 만들 필요가 있을 때 사용하는 서비스다.

'UP! > Web Service' 카테고리의 다른 글

그리드 서비스를 위한 Repository 시스템 개발  (0) 2008.08.21
분산객체와 웹 서비스의 차이점  (0) 2008.08.21
분산객체시스템 종류  (0) 2008.08.21
웹 서비스와 관련된 10가지 질문  (0) 2008.08.21
XML,SOAP,UDDI,WSDL  (0) 2008.08.21
Posted by 으랏차
,

ERP의 활용과 필요성

UP!/Software Engineering 2008. 8. 21. 14:03
1. 기업의 경쟁력 (3가지 측면)
1) 제품, 서비스의 경쟁
- 과거 : 제품과 서비스의 차별화가 명확.
- 현재 : 차별화가 어렵다.
Lifecycle이 짧다.
=> 경쟁력 유지를 위해서는 끊임 없이 혁신이 필요.
 
2) Business process의 경쟁
- Business process : 기업이 고객에게 가치를 제공하기 위한 Value chain 속의 가치 창조 구조를 의미
 . 신제품 개발 설계 process
 . 생산 process
 . 조달 process
 . 판매 영업 process
 . 위 process들을 연계 시킨 사업 process
- 고객 만족도, 비용의 차별화는 Business process의 속도와 효율의 향상으로 가능
 
3) 신제품과 새로운 서비스,  새로운 Business process를 창조하는 능력의 경쟁
- 제품, 서비스 분야의 경쟁력과 Business process에서 경쟁력을 유지하기 위해 원천이 되는 경쟁력.
 
2. 정보 기술 활용 현황
1) 업무 통합화의 결여 = Speed 경영의 방해 요인
 - 업무의 자동화, 기계화를 부문별로 추진
 - 독립적이고 정보의 흐름이 단절
 - 업무간 연계가 불 가능  : 통합화의 문제 발생
 - 연계 불능으로 사전 회의나 문서 연락이 필요
 - 업무 흐름의 속도 향상에 저해 요인
 
2) 정보 일원화의 결여 = Speed 경영의 방해 요인
 - 업무간 통합 불능
  . 중복 정보 발생
  . 각기 다른 정보 보유
 - 정보 공유 불능
  . 여러 부문에 걸친 공동 작업(Collaboration)에 어려움
  . 자율적인 판단과 신속한 의사 결정의 어려움
 
3) 즉시성 결여 = 기민한 경영의 방해 요인
 - Batch 형태의 업무처리
 - Summary 형태로 존재
 - 정확한 판단과 의사결정을 적시에 내리기 어렵다.
 
4) Global화 결여 = Global 경영의 방해 요인
 - 국내 사업에 특화시켜 구축 : Global화 대응에 미흡
 
5) 정보 시스템의 경직화 = 기업 혁신의 방해
 - 안정된 환경, 안정된 경영을 전제로 구축
 - 시스템이 복잡 방대해졌다.(계속되는 유지 보수)
 - 환경 변화에 신속한 대응 미흡
=== 기업 경쟁력을 확보하기 위해서는 정보 기술의 활용이 필수적이다.
 
3. ERP 도입의 필요성
1) ERP는
 - 정보 자원 기술을 이용하여 영업 생산, 회계, 인사, 구매, 자재 등 조직 내의 모든 업무를 통합 처리
   하고
 -  Real-Time으로 정보를 주고 받으며
 - 선진의 Business Process를 내장하고 있으므로 별도의 첨단 경영 기법이나 경영 Consulting을 받지
   않고도 경영 혁신을 할 수 있다.
         
2) 필요성
 (1) 치열한 경쟁의 시대 능동적인 대응 필요
       - 효율적이지 못한 기업은 도태된다.
 (2) 업무의 복잡성과 정보 시스템의 대규모화로 정보량의 방대한 증가
 (3) 정보 기술의 급속한 발전
      - H/W 비용의 저하
      - 방대한 자료의 축적과 처리 기술의 발달
 (4) 기업 환경의 글로벌 화
      - 세계 표준, 다국적, 다언어 처리 기능 요구
      - 상거래 제도와 관습, 문화의 경계를 넘어 정보를 통합할 수 있는 구조가 필요
 (5) Outsourcing을 통한 자사의 핵심 역량에 집중
 (6) 기능의 통합
      - 원부자재의 조달, 제품의 제조, 판매에 이르기 까지 공급 체인 전체의 기능 통합
      - 조직 전체 기능의 실시간 통합
 (7) Business Speed
      - 부품 조달 기간의 단축
      - 생산 리드 타임의 단축
      - 고객 응답 시간의 단축
 
4. ERP 시스템이 갖추어야 할 조건
1) Integration(통합성)
   - 기존 정보 시스템 : 부분적으로 지원 (인사, 회계, 생산, 재고 등)
   - ERP 에서는 프로세스 관점에서 기능의 통합이 전제
   - 통합을 통해 얻을 수 있는 장점
      . 작업 및 데이터의 중복 배제
      . 각종 자료간의 불일치 해소
      . 프로세스의 최적화
      . 업무의 비효율성 제거
2) Real-time Processing (실시간 처리)
  - Source data의 발생과 동시 관련 업무에 Real-time으로 자동 처리
  - 정보 제공의 적시성을 향상
  - 정보 이용자에게 유용한 정보의 제공
 
3) End-user Computing(사용자 처리) 기능 강화
  - 프로세스의 통합과 Real-time Processing이 가능하도록 설계됨으로써 End-user 입장에서 각종 자료
    의 접근이 가능하여야 한다. (Client/Server 구조를 통해 EUC 환경이 강화되어야 한다)
  - EXCEL 기능 활용
 
4) Flexibility (유연성)
  - Hard-coding 방식을 탈피하여 Parameter 설정 방식으로 설계되어야 함
  - Hard-coding의 문제점 ; 개발 기간의 장기화 개발 비용의 상승 유지 보수의 어려움
  - 타 시스템과의 Interface의 용이성이 좋아야 한다.
 
5) Version-up의 용이성
- 최신의 정보 기술을 수용할 수 있도록 vendor의 노력이 필요.
- 새로 개발된 시스템은 기존 시스템에 대한 지원이 용이해야 한다.
 
5. ERP 구축과 경쟁력
 
     경쟁기업
자기업
경쟁기업
구축
미구축
자기업
구축
중립
경쟁우위
미구축
열세
퇴보
 
6. 분야별 경쟁력 강화 요소
1) 회계 분야
  - 중복 Data 배제, 통합 정보 관리와 회계 업무의 정확도 향상 및 결산 기간 단축
  - 기업 내부 기능의 통합, 기업 외부와의 연계 및 자금 정보의 통합 관리
  - 정보 기술을 활용한 서류 업무의 감소
  - 기업 내 사업부서, 단위 공장간의 통합으로 실시간 회계 처리
  - Global company의 본사 및 해외 지사의 통합
  - 회계 정보의 합리적 처리
  - Cash Flow의 실시간 통제
  - 정보 기술을 바탕으로 한 의사 결정이다.
  - 국제화 경쟁에 대응하는 Multi Language 및 Multi Currency 지원
 
2) 인사분야
  - 인사 보안 능력 향상
  - 서류 작업 감소
  - 인사와 관련한 신속한 의사 결정 지원.
  - 교육 훈련 및 인재 양성 프로그램 지원.
  - 인사 전략, 조직 관리, 채용 관리, 경력 관리지원.
  - 인사 관리 업무의 정보 서비스 능력 향상
  - 다양한 인사 정보 제공(그래픽, 동영상)
  - 제조 및 회계와 연동한 급여 시스템 지원.
 
3) 정보 기술 분야
  - 분산 환경에 의한 시스템의 경량화 및 유연성 확보
  - 기업 내부 및 외부와의 이 기종 시스템의 연계 및 정보 교류(개방형 시스템, EDI 기술 등)
  - 업무의 자동화(Work Flow)
  - 업무의 분석 기능 강화 (DW 활용) : End-user 수준별(담당자, 관리자, 경영자) 보고서의
                                                     다양화 ( Graphic, Table 등)
  - 기업간, 국가간의 자유로운 시스템 접근 : Web, EDI, EC기술 등
  -  End-user의 정보 시스템의 친숙도 향상 : GUI
  - 재택 근무 환경제공
 
3) 제조/물류/서비스 분야
  - 산업별(제조, 물류, 서비스, 공공 등) 특화된 자문 기능의 대응 및 통합관리
  - 대용량 Data 처리 속도 향상에 따른 simulation 능력 향상
  - 전반적인 제조 process의 효율 향상, 산업별 표준 process의 효율 향상
  - 물류 및 제조 정보의 공동 활용으로 구매 및 설계 비용 감소
  - 신제품 설계 process의 지원 : 신제품 개발 활동의 유연성 확보
  - 제조/물류/서비스에 관련된 각종 정보의 신속한 지원 → 의사결정 속도 향상
  - 산업별 자기업에 맞는 독자적 시스템 구현
  - Internet/EDI 를 활용한 공급망 관리, 영업/고객 지원
 
7. ERP 도입 시 해결 과제


< ERP 도입의 과제 : B30>
1) 경영자의 이해
  - ERP 도입으로 기업의 어떤 변혁이 가능한지 이해.
  - 기업 변혁을 위해서 ERP도입을 서둘러야 한다는 점 이해
2) 경영 전략의 명확화
  - 명확한 경영전략 => 명확한 혁신 이해.
  - 혁신 목표 설정이 애매하면 ERP 도입은 성공하지 못함.
3) 현장 일임주위에서 탈피
  - 업무 혁신 : 조직, 부문의 현장 업무 흐름의 재검토가 필요 (Global화도 고려)
  - 현장 부문이 주체가 되어 개선을 거듭하는 식의 과거 성공 체험을 바탕으로 현장 일임주의로는
    ERP 도입의 성공은 불가능
4) 전체 최적의 추구
  - 각 부문별 부분 최적 → 각 부문에 걸친 전체 최적
5) 조직의 문화와 풍토에 대한 혁신의식
- 조직 구조의 변혁: 현재 상황을 유지하려는 저항이 크다.
- 경영자를 포함한 구성원 전원이 조직의 문화와 풍토를 변혁.
6) 기간 업무를 위한 정보 시스템의 전반적인 재구축
  - 대규모 개발이 필요 : 신속하게
  - System의 Flexibility 확보 : 신속한 변경이 가능하도록
  - ERP 패키지 활용이 효과적
7) ERP package 이용에 대한 불안감
  - 기성품에 대한 불안감 해소
  - ERP package는 업계 표준 process를 제공한다.
    (다년간 경험과 계속되는 개선으로 노하우를 가지고 있다.)
8) ERP package에 대한 습득
  - 전문적인 지식과 방법이 필요
  - 수작업으로 회귀하려 함

'UP! > Software Engineering' 카테고리의 다른 글

전사적 자원관리(Enterprise Resource Planning : ERP)  (0) 2008.08.21
공급망관리  (0) 2008.08.21
시스템구현  (0) 2008.08.21
[CMMI] CMMI Project Status  (0) 2008.08.21
객체지향 분석과 설계  (0) 2008.08.21
Posted by 으랏차
,

전사적 자원관리(Enterprise Resource Planning : ERP)

UP!/Software Engineering 2008. 8. 21. 14:03
전사적 자원 관리(ERP)는 1970년대에 개발되어 사용했던 자재소요량계획(Material Requirements Planning : MRP)에서 출발하여 제조자원계획(Manufacturing Resource Planning : MRP II)과 컴퓨터 통합 제조시스템 (Computer Intergrated Manufacturing : CIM)을 걸쳐 국제화된 기업 환경에서 기업의 현안에 대해서 실시간 분석 및 기업 전체의 최적화를 제공 할 수 있도록 유연한 IT 인프라를 바탕으로 하여 기업 내부의 모든 업무 기능을 통합하는 정보 시스템임.
 
1. ERP의 발전 과정
MRP(Material Requirements Planning: 자재소요량계획: 70년) → MRP-II(Manufacturing Resource Planning: 제조자원계획: 80년) → CIM(Computer Integrated Manufacturing: 컴퓨터 통합제조 시스템: 80년 중반) → ERP(전사적 자원관리: 90년 중반) 
 
1) MRP (자재 소요량 계획)
 - Material Requirements Planning
 - 1960년대 중반 IBM의 Joseph Orlicky가 개발업계에서 실무자들에 의해서 개발됨(학계나 이론가에
   의해서 개발된 것이 아님)
 - 자재 소요량 계획에 중점을 둔 system
 - 개념 : 이미 수립된 제품 생산 계획을 바탕으로 조립품, 부품, 원자재 등의 종속 수요 품목에 대해서
           “필한 물건(품목)을 필요한 때(납기)에 필요한 만큼(소요량)”을 구매하여 제조하기 위한 수배
           계획을 수립하는 것. 즉, 자재 소요량을 합리적으로 관리하기 위한 자재 및 구매 관리 중심의
           system
 - 재고 품목 : 독립 수요 품목과 종속 수요 품목으로 구분
  . 독립 수요 품목 : 최종 제품(end items) 생산용으로 사용되지 않는 스페어 부품
  . 종속 수요 품목 : 최종 제품을 구성하는 구성품(components) 원료(raw-material), 부품(part), 중간
                          조립품(subassembly))
 - MRP의 성공 요인
  . 당시 전통적인 재고 관리 시스템은 독립 수요 품목 위주로 개발되었으나 더 중요한 것은 종속 수요
    품목에 대한 관리가 더 필요했음 - 당시 MRP는 종속 수요 품목 관리에 초점을 둠. 즉, 필요한 자재
    를 적절한 시기에 필요한 장소에 공급한다는 문제를 효과적으로 다룰 수 있었음.
 - ERP의 시조
 - 주요 기능 : 자재 수급 관리, 재고의 최소화
 
2) MRP-II (제조 자원 관리 system)
 - Manufacturing Resource Planning.
 - 기업의 전반적인 효율성 향상과 비용 절감을 위해서는 관리 대상을 회사 내부 전체로 확대한
   system 이 필요.
 - 제조, 영업, 회계, 설계와 관련된 제조 기업의 정보 시스템
 - 주요 기능 : 제조 자원 관리, 원가절감
 
3) CIM (컴퓨터 통합제조 시스템)
 - Computer Integrated Manufacturing
 - MRP-II의 부족함을 인식
 - 기업의 영업, 생산, 기술분야에서 물류와 정보, 관련 설비나 시설의 통합을 중시한 제조업 정보
   시스템
 - 문제점 : 기술 인력의 부족, 기술의 제휴, 기능 통합의 어려움, 구축 기간의 장기화 등으로 확산이
               저조.
 
4) ERP ( Enterprise Resource Planning: 전사적 자원관리)
  - CIM과 정확한 구분이 없다.
  - Gartner Group의 정의
    . 91년 최초로 ERP개념 제창
    . 정의 : 제조(Manufacturing) 회계(Financial) 물류(Distribution) 그리고 다른 업무 기능들
      (Business Function)이 균형을 이루도록 해주는 응용 애플리케이션 소프트웨어의 집합(A set of
       applications software that brings manufacturing, Financial, distribution and other business
       function into balance)
  - 주요 기능 : 전사적 자원 관리, 경영 혁신 (기업 내 관련 기능의 통합 관리 및 기업 외부의 모든 관
    련 자원과 연계한 전사적인 자원관리 system)
    . 기업의 자원 : 사람(Man), 설비(Machine), 자재(Material), 자금(Money), 정보(Information), 시간
       (Time), Service 등을 포함    
  -  BPR (Business Process Reengineering : 비즈니스 프로세스 재 구축)기법을 도입하여 업무
                                                          개선 효과 얻음
-  ERP는 BPR과 같이 추상적인 개념이 아니다.
 . 패키지 내에 프로세스가 저장되어 있음
 . Parameter에 의해서 실제로 기업에 적용 가능
 . 최고의 실행(Best Practice)를 가지고 있음
 . ERP를 도입함으로써 선진 기업의 프로세스를 도입할 수 있다.
 
- ERP는 혁신적인 새로운 개념이 아니다.
 . 80년대에도 기업의 모든 자원의 통합에 대한 요구는 있었다
- 대용량의 데이터의 저장과 실시간 처리 기술이 요구됨.
 . 당시에는 기술력에 한계가 있었다.
 . 따라서 최근 IT의 발전 (H/W 비용의 급락과 첨단 IT 의 출현)으로 인하여 기업의 방대한 데이터 수
   집과 저자, 가공이 가능해 짐으로 인하여 통합 Package로 개발 될 수 있었음.
 
- 기업 환경이 생산자 중심에서 소비자 중심으로 전환되고 있는 상황에서 기업들은 생존경쟁에서 살아
  남기 위한 대안으로 IT자원을 활용한 첨단 경영 기법의 도입 요구가 증대하면서 ERP가 주목을 받기
  시작함.
 
- 종합 정의
“기업이나 단체의 인사, 회계, 물류, 제조, 서비스 등 전 분야에서 일어나고 있는 전체 기능들에 대해 효과적 관리와 통제를 위한 통합 정보 시스템”으로 “관계형 또는 객체지향형 DBMS, GUI, 개방형 system, client/server, 4GL, web지원, EDI, Data warehouse의 최신 정보기술을 지원하는 Business system구조를 가진 system”이다.
     
5) 향후 추세
- ORP(Optimization of Resources and Process:자원과 프로세스의 최적화 시스템) or
  e-ERP(Extended ERP: 확장 ERP)
- 주요 기능 : 기업간 최적화, Win-Win-Win
- 자원과 프로세스 최적화 시스템(ORP: Optimization of Resources and Process) : 기업 구성원들이 기
  업의 모든 자원의 사용을 최적화하여 의사 결정권자로 하여금 최적의 의사결정을 할 수 있게 지원해
  주는 시스템 임. 기존의 ERP 패키지들은 "What-If" 시뮬레이션 등과 같은 기능이 없음
   -> 따라서 ERP를 이용해서 수립된 계획이 최적의 계획인지를 알 수 없었음.
   -> 그러나 ORP는 프로세스와 자원을 최적화 하기 위해 각종 정보와 시뮬레이션 모델을 이용하여 최
       적의 의사결정을 하는데 도움을 준다
- 확장 ERP (Extended ERP) : ERP의 확장 개념으로 기업의 내부 업무는 물론 기업과 기업간의 업무까
  지도 통합하여 최적화를 지향하는 시스템 임.
 
6) 기존 시스템과의 차이점
    구   분
기존 시스템
전사적 자원관리
구축 목적
업무의 단순한 전산화
(업무의 스피드 향상에 역점)
기업의 전략을 강화
(경쟁력 향상)
지역적 관점
특정 국가 및 지역에 국한
(Local)
국가나 지역에 관계 없이 지원(Global)
적용 범위
부분적 지원
업무의 통합적인 차원에서 지원
도입 결정
과정
업무를 부분적으로 지원 하기 때문에 중간 관리자에 의해 도입을 결정함 (Bottom-Up)
 
지원기능이 통합적인 관점에서
제공되므로 최고 경영자의 결정과
지시에 의해 이루어짐
(Top-Down)
구축 방법
Source Code의 작성과 수정
Parameter설정
(Customizing의 최소화)
System의
 Up-grade
어렵다
(Source Code의 신규 작성과 수정이 어려움)
쉽다
(전문 공급업체에서 기업 환경 변화에 능동적으로 대응함)
 
2. ERP의 출현 배경
1) 경영 패러다임의 변화
- 과거의 경영 : 고도 성장의 매출 확대, 이익 중시 경영
- 현재의 경영
    . 기업의 자금 능력 약화
    . 수익성 감소
    . 치열한 경쟁 시대 (대경쟁: Mega-competition)
- 다국적 기업의 평균 수명 : 40 – 50년
- 평균 수명이 긴 이유
. 민첩성(기업의 외부 환경에 발 빠른 대응)
. 결속력(기업 문화를 바탕으로 한 구성원의 단결)
. 보수적인 자금 운영
. 효율적 투자
 
2) 기업의 환경 변화 요인 (7가지)
(1) 세계화/국제화 : 무역 자유화 → 경쟁력 확보 → 세계화/국제화(다국적기업)
     => 다국적 기업의 관리를 위해 세계화/국제화된 정보 시스템의 필요성 대두
(2) 정보의 다량화/분산화 : 지역적으로 분산된 다량의 기업 정보를 통합 관리 요구
(3) 빠른 제품의 라이프 사이클과 수익성 감소. : 제품이나 서비스의 다양한 요구 → 제품 수명 단축
     → 제품의 라이프 사이클 단축 → 제품 개발에 투자 비용이 상승
(4) 제품의 초 고급화 : 최고의 기능과 최고의 품질 요구 → 품질 좋은 제조 절차(일품생산) 필요 =>
     일품 생산 형태의 주문까지 지원할 수 있는 정보 시스템 요구
(5) Knowledge worker의 등장 : 지식 기반 사회에서 핵심 역할은 인간이며, knowledge worker의 생
     산성은 기업 경쟁력 확보와 직결 => 새로운 정보 시스템은 지적 작업자의 사무 생산성을 극대화
(6) 외부 경쟁자의 도전 : 차별화 된 경쟁력 확보 (제품의 생산, 판매 A/S등 전 과정에서 총체적인 경
     쟁 우위력을 확보)
(7) 강화된 고객 지원 체계 : 상세한 고객 정보 확보와 활용으로 고객의 기호와 개성에 맞는 제품이나
     서비스 제공. => 방대한 고객 정보 확보와 활용은 새로운 정보 시스템 요구.
 
3. 정보 시스템 관련 기술의 변화 (9개 기술)
(1) GUI (graphical user Interface)기술
   - Text Base의 UI 환경 : 사용자의 접근성 미흡
   - GUI : 기업내 모든 사용자의 접근성 용이 (관리자, 경영자 계층)
 
(2) Open Standard System
   - Stand-Alone System (지역적 혹은 독립적으로 운영) Interface와 Integration 취약
   - Open system : 이 기종간의 Interface와 Integration이 가능. 전 사적 자원 관리를 가능케 함.
 
(3) Client/server 기술
   - 중앙 집중식 system : 대형화, 집중화에 따른 비용의 중가 Down sizing 필요성 인식
   - Client/server system
    . Server system : 공용성 정보의 관리, 보관
    . Client system : 개별 정보의 관리, 보관
    . 중앙 집중식 system 보다 초기 투자 비용이 상대적으로 낮다.
 
(4) Relational Database (RDB) 와 객체지향 (object-oriented) 기술
  - RDB : 분산 환경에 적합
  - OO기법 : 새로운 설계와 개발 기법.
 
(5) 4GL과 Case Tool
  - 4GL(fourth generation Language)
   . 사용자가 programming에 대한 전문 지식이 없어도 programming을 할 수 있도록 지원
   . 개발의 신속성
  - CASE (Computer Aided Software Engineering)
   . 개발 생산성 증대
   . 개발의 자동화 지원
   - 복잡한 기업 정보 시스템을 구축하는데 유용한 기술
 
(6) Work Flow
  - 기업 업무가 복잡해지고, 표준화가 어렵다.
  - 기간 업무의 자동화, 표준화, 관련 업무의 Interface, 정보의 효율적 관리, 운영
 
(7) EDI 기술
EDI (Electronic Data Interchange) : 사람의 개입이나 재입력 없이 자료 전송 수단으로 활용. 기업간 정보 교환의 수단으로 활용.
 
(8) Data Warehouse 기술
  - 다양한 Data로부터 활용 가치가 있는 정보 요구 (사용자의 요구와 필요에 부합하는 정보 요구 : 각
    종 Table이나 Graphic 정보)
  - DW기술 : 원천(Raw) data의 분류, 결합, 가공 기술
 
(9) Web 기술
  - Web 기술 : 시간과 지역에 관계없이 정보 system에 쉽게 Access 가능
4. 정보 기술의 발전 추세
1) 정보 기술의 변화 (3대 변화)
  - Don Tapscott와 Art Caston이 저서 “패러다임 쉬프트 (Paradigm Shift)” 에서 소개
  (1) Personal computing → Work group computing
  (2) 개별 System → 통합 System
  (3) 기업 내부 Computing → 기업간 기업의 Computing환경
 
2) 정보 기술의 요소 기술 전환
  - Don Tapscott와 Art Caston이 저서 “패러다임 쉬프트 (Paradigm Shift)” 에서 소개
   (1) Computer Chip         : 반도체           → Micro processor
   (2) System                   : Host system     → Network system
   (3) S/W 공급                : 공급자 독점      → Open Standard
   (4) 정보 형태                : 단일 미디어      → 멀티미디어
   (5) 고객과 공급자 관계   : 종속             → 협력 관계
   (6) S/W개발                 : 독립된 개인 기술    → Module화, 표준화, 공동 개발
   (7) User Interface         : Text Base          → GUI. (Graphical User Interface)
   (8) 응용 Program          : 독자형             → 통합형, Module형, 재사용 강화

'UP! > Software Engineering' 카테고리의 다른 글

ERP의 활용과 필요성  (0) 2008.08.21
공급망관리  (0) 2008.08.21
시스템구현  (0) 2008.08.21
[CMMI] CMMI Project Status  (0) 2008.08.21
객체지향 분석과 설계  (0) 2008.08.21
Posted by 으랏차
,

공급망관리

UP!/Software Engineering 2008. 8. 21. 14:02
제1장 공급 사슬 관리의 개요
1 공급 사슬 관리의 개념
- 공급 사슬 (Supply chain) 이란 “공급 업체로부터 재화나 용역이 생산 과정을 거쳐 소비자에 이르는 과정에서 전반적인 유통에 관련된 정보 및 프로세스의 집합체 (Schroeder, 2000)
- 공급 사슬은 재화나 용역이 원재료의 공급 업체, 제조 업체, 유통 업체, 소매 업체 마지막으로 최종 소비자에 이르는 과정에서 원재료, 관련 정보, 지불, 서비스 등의 일련의 흐름을 의미하는데, 즉, 제품이 제조되고 최종 소비자에게 전달되는 과정으로 여러 기업이나 조직이 관여 함으로 하나의 확장된 기업 (extended enterprise) 개념으로 볼 수 있다.
- 공급 사슬의 주체
    . 고객                         . 제조 업체
    . 소매업체                   . 부품, 원자재 공급업체
    . 도매업체 / 배송업체
- 공급 사슬 관리 (Supply chain Management) 란
공 급 사슬상에 존재하는 불필요 하고 비효율적인 요소들을 제거하여 공급 사슬에 참여하는 조직의 공통 비용을 절감하고, 이익을 증대시켜 궁극적으로 소비자 가치를 극대화 하려는 기업간 win-win 전략으로 제품의 원재료 조달에서부터 소비자에 이르기 까지의 공급 사슬에 참여하는 모든 업체들을 전략적인 제휴를 바탕으로 정보 기술을 활용하여 통합의 효율성을 추구하는 경영 방식이다.
- SCM 이란
고객과 참여하는 관계자들에게 부가 가치를 창출하기 위해서 최초 공급자로부터 소비자에게 이르는 과정에서 제품, 서비스, 정보의 흐름과 같은 비즈니스 프로세스들을 통합적으로 운영하는 전략이다 (Global Supply Chain Forum, 1988)
- SCM 이란
고객이 요구하는 서비스를 만족시켜 주면서 비용을 최소화 시키기 위해서 적정 수량의 제품을 적정한 장소까지 적정한 시간에 생산 및 유통될 수 있도록 공급자, 생산자, 물류업자, 유통업자 들을 효율적으로 통합하기 위한 경영 방식이다. (Simchi-Levi, 2000 : 대영, 고 266)

2. 공급망 관리의 출현
- 1980년대에 미국에서 시작된 개념
- SCM 에 관련한 기법들
. ECR (Efficient Consumer Response),
. QR (Quick Response)
. CAO (Computer-Assisted Ordering)
. CRP (Continuous Replenishment Program)
. CFAR (Collaborative Forecasting and Replenishment)
. CPFR (Collaborative Planning, Forecasting and Replenishment)
- 주요 업체
 . i2 Technologies
 . J. D. Edwards
 . SAP.
- 초기 SCM은 주로 제조업체와 유통업체를 대상으로 발전.
- 향후 금융, 보험, 의료, 연예 등 서비스 업체로 확산 전망
- 국내에서는 90년대 중반에 미국계 Consulting 업체와 SI 업체들에 의해서 개념이 소개됨.
3. 공급망 관리의 중요성과 목적
1) SCM 의 중요성
 (1) 공급 사슬의 연계에 대한 중요성
   - 다양한 형태의 경쟁 상황에 직면 (Global 화)
   - 기업 자체적인 경영 효율화에 한계 봉착
      . 자전거 생산 업체가 내부적으로 경영의 효율화를 이루었다 하더라도 도매상이나 소매상까지
        운송하는 시스템이 제대로 구축되지 않았다면 결과적으로 제품 자체의 경쟁력을 잃을 수도 있
        다.  따라서 자전거를 잘 만드는 것도 중요하지만 운송 시스템도 잘 갖추어 판매 효율화를 이룩
        하도록 한다.
   - 최근 기업 경영은
      . 자기 기업이 경쟁력이 별로 좋지 않아도 다른 기업들과 Outsourcing, 전략적 제휴, 파트너 쉽 등
        을 통해 연계 관계를 강화시키거나, 효율적으로 활용하여 전체적인 제품 공급 라인을 효율화 시
        킬 수 있다면 이것도 경쟁력을 강화 시킬 수 있는 방법 이라는 것을 인식함.
   - 공급 라인의 변화
      . 과거 : 제조업체 -> 도매상 -> 소매상 -> 소비자
      . 현재 : 소비자 -> 소매상 -> 도매상 -> 제조업체
 
   제조업체 중심에서 소비자 중심으로 변화 => SCM 의 핵심 요소
   - 기업의 경영 효율화 = 생산 효율과 판매 효율화로 달성할 수 있음.
      . 생산의 효율화 : 좋은 제품의 생산, 품질, 원재료와 도구의 적시 적절한 구매 등 기업 전방 분야
        의 효율화를 이룰 수 있다.
      . 판매 효율화 : 물류, 배송 등 기업 후방 분야의 효율화로 이룰 수 있다.
    - 따라서 1980년대 90년대 들어서 기업의 위 전방 부분과 후방 부분의 연계가 기업전략의 핵심으
      로 부각
    - SCM이 최근에 관심을 집중시키는 이유
      . SCM은 1800년대 이후 산업 사회로 진입하면서 항시 관심을 가지고 있었음
      . 80년대, 90년대에 활용되기 시작한 공급망 관리 기법들 (이 당시 혁신적인 경영 전략가들에 의
        해서 경영전략의 TOOL로 인식되기 시작함)
   . ECR (Efficient Consumer Response),
   . QR (Quick Response)
   . CAO (Computer-Assisted Ordering)
   . CRP (Continuous Replenishment Program)
   . CFAR (Collaborative Forecasting and Replenishment)
   . CPFR (Collaborative Planning, Forecasting and Replenishment)
   . 기업의 Computing 환경이 또한 Mainframe에서 PC 환경으로 변화되고, 졍영 전략과 정보 기술의
     접목으로 새로운 관점에서 관심을 갖게됨
 
 (2) SCM과 유통 관리의 차이점
   . 유통관리의 대상 : 제조업체, 도매상, 소매상
   . 90년대 초에 SCM이 기업의 경쟁 전략으로 부각하자 많은 유통관리 분야의 학자나 전문가들이 유
     통관리가 SCM의 함 부분으로 흡수될까 봐 우려함
   . SCM이 유통관리를 포함하고 있는 것은 사실이지만 50%정도는 서로 다른 점도 있음
   . 차이점
      SCM : 제조업체의 생산 효율성과 유통업체의 판매 효율성에 목적을 둠
      유통관리 : 제조업체의 생산 효율성 보다는 유통 업체의 판매 효율성에 중점을 둠
2) SCM 의 목적
 (1) 소비자들의 다양한 요구를 제품의 공급 과정에 일치(Synchronization)시키려고 함
   - Synchronization
      . 소비자의 요구에 소매점이 자신의 활동을 일치
      . 소매점의 요구에 도매상이 자신의 활동을 일치
      . 도매상의 요구를 제조업체가 그들의 활동을 일치
      . 제조업체의 요구를 원재료 공급 업체가 그들의 활동을 일치
      . 궁극적으로 공급 라인 전체가 일치하게 된다.
    - 공급 사슬간의 연결 고리가 제대로 연결되지 못하면
      . 비용이 더 들거나
      . 손해가 발생
   - 수도 배관의 예

 (2) 소비자 만족을 통한 매출 확대
   - SCM은 소비자를 기본으로 시작하여 소매점, 도매상, 제조업체, 원재료 공급업체로 연결됨
   - 따라서 공급망 상의 모든 구성 요소를 유기적인 통합하여 고객의 만족을 극대화하여  매출을 확대
     한다.
   - SCM이 소비자로부터 시작한다 하여 (Customer Chain Management)라고도 함
   - 또, SCM을
      . 소매상이 여러 도매상을, 제조업체가 여러 원재료 공급업체를 탐색하면서 거래를 한다 하여
        Supply Network, Supply Web이라고도 함
 (3) 공급망 상의 총 가치의 극대화
   - 총가치 : 공급사슬 관리상에 투입된 전제 비용과 이로 인해 창출된 전체 수익과의 차이를 의미함
   - 공급사슬 관리상에 투입된 전체 비용 : 소매상, 도매상, 제조업체, 원재료 공급업체들이 사용한 총
     비용
   - 공급사슬 관리상의 전체 수익 : 최종 산출물인 제품을 구입하기 위해 소비자가 지불한 가격의 총합
   - 공급 사슬 수익성(Suppply Chain Profitability)  총가격 – 총 비용.
   - 공급 사슬 수익성의 극대화는 공급망 상의 개별 업체에 의해서 이루어지는 것이 아니고 공급망 상
     의 모든 업체가 공급망 상의 총 가치를 극대화시키므로 가능하다.
     
 (4) 공급망의 최적화로 수익의 극대화
   - 참여하는 일부 업체만으로는 공급망의 최적화는 이룰 수 없다.
   - 공급망 상의 업체간의 비용 전가 등은 종국적으로 소비자 가격을 올리게 되어 수익의 극대화에 역
     행이 됨

'UP! > Software Engineering' 카테고리의 다른 글

ERP의 활용과 필요성  (0) 2008.08.21
전사적 자원관리(Enterprise Resource Planning : ERP)  (0) 2008.08.21
시스템구현  (0) 2008.08.21
[CMMI] CMMI Project Status  (0) 2008.08.21
객체지향 분석과 설계  (0) 2008.08.21
Posted by 으랏차
,

시스템구현

UP!/Software Engineering 2008. 8. 21. 14:02
시스템 구현 단계는 설계 내용을 원시 코드로 설계 내용과 프로그램 작성 내용 일치 여부 검증 오류를 발견, 수정 용이 요구사항 변경, 기능 추가 시 원시 코드와 문서화 작성이 용이하도록
 
1. 프로그래밍 언어의 선택 기준
1) 친밀감이 있어야 한다
2) 프로그래밍 언어의 개념이 단순, 명료, 통일성을 가져야한다
3) 복잡한 연산이나 요구되는 연산 결과의 정확도를 고려해야 한다.
4) 구조적인 표현이 가능하고 검증이 쉬워야 한다.
5) 적절한 자료구조, 연산, 자연스러운 구문 제공이 가능해야한다.
6) 프로그래밍 지원 환경이 좋아야 한다.
7) 기계에 대한 독립성이 있어서 이식성이 높아야한다.
8) 프로그램의 길이가 짧은 언어가 좋다.
 
2. 구조적 프로그래밍의 개요
구조적 프로그래밍의 출현 배경
고전적인 소프트웨어 개발 문제점 해결
문제점
생산성과 신뢰성의 저하
유지보수, 확장성의 결여
시스템 관리 곤란
 
3. 구조적 프로그래밍의 배경 사상
1) GO TO 문 유해론
2) 프로그램의 기본 구조
① 순차처리 구조
② IF THEN ELSE 구조
③ DO WHILE 구조 or DO UNTIL 구조
 



4. 구조적 코딩기법
구조적 코딩이란?
- 구조정리에 따라서 프로그래밍하는 것
- 3개의 기본적인 제어구조를 조합한 구조로 표현한 것
- DO CASE, DO UNTIL, 순환(Recursion)기법 추가 사용
∙ CASE 구조
- 어떤 조건을 판별한 결과 3개 이상의 처리로 나누어지는 경우에 적용되는 구조
- 입구도 하나, 출구도 하나다

 
DO CASE 흐름도를 유사코드로 표현하면
DO CASE entry-name
 CASE 조건1
  처리1
 CASE 조건2
  처리2
 CASE 조건3
  처리3
              :
              :
 CASE 조건N
  처리N
END-CASE
    
◉ DO UNTIL구조
       DO WHILE 구조        DO UNTIL 구조

* 모듈의 호출방법
   모듈을 호출하는 경우 GO TO 문을 사용하지 않는다.
   Call 명령이나 PERFORM 명령 등을 사용한다.

5 의사 코드와 흐름도와의 관계
구조적인 프로그램 작성
- 프로그램 명세서를 작성
- 명세서의 작성에는 의사코드를 많이 사용
- 구조적 프로그래밍 발전 ⇒ 흐름도 필요 없음
1) 문서화를 위한 관점
① 흐름도 : 『How』의 표현수단 우수, 『What』 표현수단 부적합
② 의사코드 : 『What』 『How』 동시 표현 가능한 문서화 기법
③ 프로그래머가 생각한 결과의 전달 수단으로 의사코드가 흐름도보다 우수

2) 주의력 집중을 위한 관점
흐름도 :
4각형, 화살표, 마름모꼴, 원, 타원, 사다리꼴 등의 도형을 사용
도형을 배치항 위치, 크기 고려 ⇒ 생각 방해 요인
의사코드 :
문제의 논리적 해결에 주의력 집중 가능
3) 특정언어로의 변환이 쉬운 관점
의사코드 사용 제어구조 표현 규칙
① 제어구조를 표현하는 용어를 사용한다.
② 구조적 문장 표현과 문장 시작 위치를 일치 시킨다.

4) 다른 프로그래밍기법과 연결되는 관점
구조적 프로그래밍을 쉽게 하는 기법
구조화 설계
프로그램을 독립된 한개의 기능단위로 분할하여가는 기법
구조적 프로그래밍의 필수 불가결한 것
독립성이 높은 모듈구조로 설계하여가는 방법을, 지침으로 표시한 것
HIPO
 
6. 프로그램 설계
프로그램 작업의 유형
1) 자료 변환 프로그램
2) 분류(sort) 프로그램
3) 병합(merge) 프로그램
4) 분배(distribution) 프로그램
5) 대조(matching) 프로그램
6) 추출(extract) 프로그램
7) 갱신(update) 프로그램
8) 생성(generate) 프로그램
 
7 소프트웨어 생산성
소프트웨어의 생산성을 높이기 위한 방법
 1) 먼저 인적자원의 확보가 선행되어야 한다
 2) 여러 가지 업무를 개발한 경험자를 참여시킨다
 3) 적절한 인원으로 팀을 이루고, 조직 내에 갈등이 생기지 않도록 한다
 4) 개발자를 지리적으로 분산시키지 않는다
 5) 개발에 사용자 참여
 6) 고급언어 사용
 7) 구조적 개발 방법론 등, 최신 기법 도입
 8) 개발 도구들을 도입하여 분석과 설계 및 프로그램 생성에 활용
 9) 재사용 가능한 모듈 활용, 모듈화 적극 추진
10) 프로토타이핑을 한다
11) 개발자들의 자질 향상을 위해 교육 훈련을 시킨다
12) 개발 환경을 개선한다
13) 진척 관리를 철저히 한다
14) 개발자 스스로가 생산성을 측정할 수 있도록 한다
15) 시험 방법을 잘 선택해야 한다
생산성에 영향을 미치는 또 다른 요소
 1) 프로젝트의 크기
 2) 프로젝트 개발 경험
 3) 프로젝트가 복잡성
 4) 정보 처리 유형
 5) 개발 조직체의 규모
 6) 자원 및 일정
 7) 초과 근무 수당
 8) 현업과의 협조
 9) 경영자의 관심 정도
10) 대상 고객
11) 기존 소프트웨어 개선, 오류 정정, 새로운 시스템으로 변환하는 경우
정보 처리 유형
① 일괄 처리용
② 실시간용
③ 과학 기술 계산용
④ 시스템 소프트웨어
⑤ 통신용
⑥ 자동 제어용
⑦ 멀티미디어용
⑧ 인공지능용
⑨ ROM 내장용
⑩ 데이터 베이스 응용 4세대 언어용

'UP! > Software Engineering' 카테고리의 다른 글

전사적 자원관리(Enterprise Resource Planning : ERP)  (0) 2008.08.21
공급망관리  (0) 2008.08.21
[CMMI] CMMI Project Status  (0) 2008.08.21
객체지향 분석과 설계  (0) 2008.08.21
문서화  (0) 2008.08.21
Posted by 으랏차
,

[CMMI] CMMI Project Status

UP!/Software Engineering 2008. 8. 21. 14:01


Agenda
•          Project History
•          CMMI Structure
•          Comparisons with SW-CMM v1.1, SE-CMM, and EIA/IS 731_
•          Assessment Methodology
•          Training
•          Transition Timelines and Strategies
 
What is a CMM?
•          Capability Maturity Model:
A reference model of mature practices in a specified discipline, used to assess a group’s capability to perform that discipline
•          CMMs differ by
–         Discipline (software, systems, acquisition, etc.)
–         Structure (staged versus continuous)
–         How Maturity is Defined (process improvement path)
–         How Capability is Defined (institutionalization)
•          “Capability Maturity Model®” and CMM® are used by the Software Engineering Institute (SEI) to denote a particular class of maturity models
 
Commonly Used CMMs
 
 
 
What is the Problem?
•          Different structures, formats, terms, ways of measuring maturity
•          Causes confusion, especially when using more than one CMM
•          Hard to integrate them in a combined improvement program
•          Hard to use multiple models in supplier selection
 
 
 
The CMMI Project
•          DoD sponsored collaboration
between industry, Government, academia
•          Over 100 people involved
      
•    U.S. Army, Navy, Air Force
•    Federal Aviation  Administration
•    National Security Agency
•    Software Engineering Institute
•    ADP, Inc.
•    AT&T Labs
•    BAE
•    Boeing
•    Computer Sciences Corporation
•    EER Systems
•    Ericsson Canada
•    Ernst and Young
•    General Dynamics
•    Harris Corporation
•    Honeywell
•    KPMG
•    Litton
•    Lockheed Martin
•    Motorola
•    Northrop Grumman
•    Pacific Bell
•    Q-Labs
•    Raytheon
•    Rockwell Collins
•    Sverdrup Corporation
•    Thomson CSF
•    TRW
 
CMMI Models
Source Models
•          Capability Maturity Model for Software V2, draft C (SW-CMM V2C)
•          EIA Interim Standard 731, System Engineering Capability Model (SECM)
•          Integrated Product Development Capability Maturity Model, draft V0.98 (IPD-CMM)
 
                                 
 
•          Combined System Engineering / Software Engineering model
–         IPPD version being developed
•          Can be applied to:
–         Just the software engineering projects in an organization
–         Just the system engineering project in an organization
–         Both
 
 
CMMI Process Areas - Staged Representation
 
 
 
  
Common Features For Each Process Area
•          Commitment to Perform includes practices that ensure the process is established and will endure.
–          Establishing organizational policies and leadership.
•          Ability to Perform includes practices that establish the necessary conditions for implementing the process completely.
–         Resources, organizational structures, and training.
•          Activities Performed includes practices that directly implement a process area.
–         Developing plans and procedures, performing work, tracking work, and taking corrective actions as necessary.
•          Directing Implementation includes measurement practices that are necessary to collect and analyze data related to the process.
–         Insight into the performance of the process.
•          Verification includes practices that ensure compliance with the process that has been established.
–         Reviews and audits.
 
CMMI - Continuous Representation
                            
Which Representation Should We Use?
•          The staged and continuous representations are equivalent but expressed in different ways
–         Equivalent staging defined
•          Staged
–         Specific Process Areas for each Maturity Level
–         Guides incremental improvement by focusing attention on the next level’s Process Areas
•          Continuous
–         Each Process Area has Capability Levels
–         Organizations must decide your own improvement path
»         What level of capability is appropriate for each Process Area based on their business needs
•          Generally, you should keep the representation you started with
–         SW-CMM: staged; EIA 731: continuous
 
CMMI Model Components
•          CMMI Models contain institutionalization (Generic) and implementation (Specific) parts:
•          Front matter
•          Process Areas that contain:
–         Generic and Specific Goals
–         Generic and Specific Practices
(in Common Features in staged representation)
–         Subpractices
–         Notes
–         Discipline-specific amplifications
•          Glossary and model scoping guidelines
 
SW-CMM v1.1 vs. CMMI
Process Areas
    
 
SW-CMM v1.1 vs. CMMI
Common Features
                             
 
SE-CMM and SECM (EIA/IS 731) vs. CMMI
Common Features - Engineering
       
 
CMMI Assessment Requirements (CAR)
•          Similar to the current CMM Appraisal
Framework (CAF) V1.0
–         A guide to assessment method developers
•          Specifies the requirements for classes of
assessment methods
–         Class A: Full, comprehensive assessment methods
–         Class B: Initial, incremental, self-assessments
–         Class C: Quick-look
•          Method developers can declare which class their method fits
•          Method buyers will understand the implications of the method proposed
 
Standard CMMI Assessment Method for Process Improvement (SCAMPI)
•          A Class A Method
•          Similar to CBA IPI method
–         Led by authorized Lead Assessor
–         Tailorable to organization and
model scope
–         SEI will continue to compile results
•          Rules of evidence have been expanded
•          Products:
–         SCAMPI Method Description
•          In work
–         Maturity questionnaire, work aids, templates
–         Incorporation of SECM appraisal methods
–         Reducing the cost of assessments
 
CMMI Lead Assessor Program
•          Similar to existing SEI Lead Assessor
and Lead Evaluator programs
–         To be administered by SEI
•          Will transition current SW & SE Lead Assessors
–         Specific requirements, steps under discussion
•          Lead Assessor requirements:
–         Introduction to CMMI Training
–         Assessment team experience
–         Advanced CMMI Training
–         SCAMPI Lead Assessor Training or
Upgrade Training (for current Lead Assessors)
 
Expectations
•          We have simplified the method, but…
–         CMMI models have more process
areas and more practices than each
of the individual source models
•          Our goal:
–         Assuming an organization
of 3-6 projects, 6-9 team members,
experienced Lead Assessor
–         SCAMPI assessment of all process areas through Levels 2-5 in 2-3 weeks
–         SCAMPI assessment of process areas through Levels 3 in 1-2 weeks
 
Introduction to the CMMI Course
Staged & Continuous (Separate Courses)
•          Introduction course will enable the participant to
–         Understand the importance of defined processes
–         Understand the rationale for process improvement
–         Comprehend the CMMI model
–         Identify ways of applying the CMMI model
for process improvement
•          Broad audience
–         Systems and software developers
–         Systems and software managers
–         Practitioners of disciplines that support systems and software
–         Government and industry acquirers of software-intensive systems
•          Other courses in development
 
CMMI Transition Plan
 
                
 
How Do I Transition My Organization?
•          Decide whether the staged or continuous representation is more appropriate
•          Decide the scope of the improvement effort
–         Software projects only
–         Systems engineering projects only
–         All projects
•          Perform an gap analysis of your current practices against the model changes from SW-CMM and/or EIA 731
–         New Process Areas
–         New Common Features
–         New/different practices
–         Do you need a new infrastructure to cover a new discipline?
–         Do you want a comprehensive assessment?  Informal/formal?
•          Set goals, develop a plan, implement the plan, assess progress
 
Summary
Organizations that are currently using SW-CMM v1.1 or EIA/IS 731 should be able to smoothly transition
 
http://www.sei.cmu.edu/cmmi/
•          CMMI Model, SCAMPI Method Description
•          IPPD Model (when available)
•          CMMI news, presentations, articles, correspondence
•          FAQs (Frequently Asked Questions)
•          CMMI Plans and Schedules
•          CMMI Transition Plan

'UP! > Software Engineering' 카테고리의 다른 글

공급망관리  (0) 2008.08.21
시스템구현  (0) 2008.08.21
객체지향 분석과 설계  (0) 2008.08.21
문서화  (0) 2008.08.21
CASE  (0) 2008.08.21
Posted by 으랏차
,

티스토리툴바