본문 바로가기

Homo Faber53

SOA Service Benefit Pattern 조직은 많은 상이한 이유로 인해서 서비스를 제공하거나 사용한다. 한편으로 비즈니스 프로세스를 최적화하기 위해서 공급망(supply chain)을 가로지르는 정보 흐름을 향상시키고 자동화하는 서로 다른 구성원을 한데 아우르는 것과 같은 비교적 명백한 비즈니스 요구사항이 될 수도 있다. 다른 한편으로는 서비스가 IT 시스템의 자원에 구조적인 상승효과를 가져다 주는데에 사용될 수 있으며 그러한 서비스 사용은 비즈니스에 꽤 투명해질 수 있다. 문제는 ROI를 정당화시키기 위해서 서비스가 제공하는 이익의 범위를 이해한다는 것이다. 첫번째 경우, 이익은 해당 비즈니스에 대해서 즉시적이며 명확해야 한다. 하지만, 두번째는 해당 비즈니스에 대한 이익은 덜 직접적이며 장기간을 요할 수도 있다. 이상적으로 조직은 SOA를.. 2008. 3. 13.
비즈니스 패턴 비즈니스 패턴은 사용자들과 비즈니스 조직 및 어플리케이션, 접근하는 데이터 사이의 관계를 나타낸다. 다음 표와 같이 네가지 주요 비즈니스 패턴이 있다. 비즈니스 패턴 설명 예 Self-Service (User-to-Business) 사용자가 인터넷이나 인트라넷을 통해 비즈니스와 상호작용하는 어플리케이션 단순한 웹 사이트 어플리케이션 Information Aggregation (User-to-Data) 사용자가 데이터, 텍스트, 이미지 등과 같은 대용량 정보로부터 유용한 정보 추출이 가능한 어플리케이션 비즈니스 인텔리전스, 지식 관리, 웹 수집 (Web crawler) Collaboration (User-to-User) 인터넷이 사용자 간의 협업 작업을 지원하는 어플리케이션 이메일, 커뮤니티, 채팅, 화상.. 2008. 3. 11.
유스케이스 드리븐 방식의 한계 - 유스케이스 드리븐 방식은 식별된 유스케이스로부터 공통된 객체를 식별하는 방법으로 가장 널리 사용되는 방법 중의 하나이다. - 그렇지만, Don Firesmith 는 다음과 같이 유스케이스 드리븐 방식에 대해서 반대입장을 표명했다. [Firesmith1996] “유스케이스는 객체지향 방법이 아니다. 각각의 유스케이스는 객체 기술에서 지양해야 하는 기능 분해 관점에서 수많은 문제점을 야기시킬 수 있는 주요한 기능적인 추상화를 담고 있다... 객체와 클래스가 식별되기 이전에 유스케이스가 먼저 식별되었기 때문에 유스케이스는 객체에 대한 속성과 오퍼레이션을 무시하게 된다.” 계속해서 그는 유스케이스 드리븐 방식이 “전형적인 서브시스템 아키텍처 형태를 띠며... 개개의 유스케이스의 로직을 표현하는 단일 기능 컨.. 2008. 3. 10.
소프트웨어 공학의 진실과 허위 1. 관리 진실 1. 소프트웨어 작업에서 가장 중요한 요소는 프로그래머들이 사용하는 도구나 기술이 아닌 프로그래머들 자신들의 자질(quality)이다. 진실 2. "개인차" 조사에 따르면, 최고의 프로그래머는 최악의 프로그래머보다 28배나 생산성이 높다. 이들의 연봉이 결코 그만큼 받지 못한다는 사실로 미루어봐서 소프트웨어 분야에서 이들은 大 바겐세일용이다. 진실 3. 지연된 프로젝트에 사람을 투입하는 것은 프로젝트를 더 지연되게 만든다. 진실 4. 작업 환경은 생산성과 제품 품질에 깊은 영향을 준다. 진실 5. 과대 선전은 소프트웨어 업계에서 전염병이다. 대부분의 소프트웨어 도구와 기법들은 생산성과 품질에 있어서 약 5내지 35 퍼센트 가량 향상시켜준다. 하지만, 어느 시점이건 대부분의 그러한 향상성은.. 2008. 3. 5.
반응형

티스토리툴바