수아아빠 블로그

스마트폰의 애플리케이션?

2009-11-23T10:12:22Z

현재 스마트폰의 애플리케이션은 주로 개인일정 관리, 게임, 뉴스와 같은 컨텐츠 제공과 같은 PC환경과 비교하여 단순한 애플리케이션들이주를 이루고 있습니다

향후 스마트폰이 기존 인터넷 환경에서 가능했던 다양한 RICH인터넷 컨텐츠와 사용자 생성 컨텐츠, 다양한 분야의 전문적인 어플리케이션의 등장이 가능해 지면서 무선인터넷 환경에서 다양한 분야의 어플리케이션과 서비스에 대한 소비자의 선택범위 확대되고 서비스 수요도 증가하게 될 것으로 보입니다.

그렇다면 향후 스마트폰에서 어떤 애플리케이션과 어떤 서비스들이 많이 사용될 것인지 분석 해보겠습니다.

소셜 네트워킹SNS, 모블로그, Media-Sharing, 광보 서비스, 생산성 어플리케이션 - 그룹웨어, Mobile 데이터베이스, 재고관리, CRM, LBS, 보안 어플리케이션, Telemetry 모바일커머스등..

구글 네비게이터 - 네비게이션의 특징은 사용자에게 무료로 제공을 하고, 음성인식이 되고, 유선과 완전 연동이라 풍부한 데이터와 지도 서비스를 네비게에션에 바로 접목시켰다는 점입니다

서블릿 2.4 RequestDispatcher관련

2009-11-20T18:02:29Z

서블릿 2.4는 RequestDispatcher forward() 호출 동안에 특별한 정보를 제공하도록 다섯가지 새로운 요청 속성(attribute)을 추가하였다. 서블릿으로 forward()하면, 서블릿 컨테이너는 타겟 서블릿이 최초 호출된 것인것 처럼 패스 환경을 바꾼다. getRequestURI()와 getContextPath(), getServletPath(), getPathInfo(), getQueryString()는 모두 getRequestDispatcher() 메소드에 전달된 URI에 기초하여 정보를 리턴한다. 그러나, 어떤 경우에는 forward()된 타겟 서블릿이 원래 호출 URI를 알 수 있어야 한다. 이것을 위해, 서블릿 2.4는 다음의 요청 속성을 추가하였다:

javax.servlet.forward.request_uri
javax.servlet.forward.context_path
javax.servlet.forward.servlet_path
javax.servlet.forward.path_info
javax.servlet.forward.query_string

포워드된 서블릿에서 getRequestURI()는 항상 타겟 서블릿의 패스를 리턴하지만, 원래의 패스를 얻고자 한다면 request.getAttribute("javax.servlet.forward.request_uri") 를 호출할 수 있다. 예외 상황: forward()가 getNamedDispatcher()에 의해 발생한 경우, 원래 패스 속성이 바뀌지 않기 때문에 이 속성들은 세팅되지 않는다.이 속성들은 서블릿 2.2에 다음의 요청 속성들이 추가된 것을 상기시켜준다:

javax.servlet.include.request_uri
javax.servlet.include.context_path
javax.servlet.include.servlet_path
javax.servlet.include.path_info
javax.servlet.include.query_string

그러나 이것들은 forward() 속성과 반대로 동작한다. include()에서는, 패스 속성이 바뀌지 않기 때문에 include 속성들은 타겟 서블릿 패스 속성에 접근할 수 있는 뒷문(backdoor) 역할을 한다. 패스 속성이 바뀌어 forward 속성이 원래 패스 속성으로의 뒷문(backdoor) 역할을 하는 forward()와 비교해 보라. 그렇다, 매우 복잡하다. 서블릿이 내부적인 dispatch 메카니즘으로서 URI를 사용하면, 이러한 복잡성은 해결된다. (역자주 : 기준이 되는 페이지가 어떤 것이냐의 차이점인 것으로 생각된다. forward는 기준 페이지가 변하므로 기존의 페이지의 패스를 알기 위해 위의 상수들이 필요하고, include는 기준 페이지가 변하지 않으므로 include되는 페이지의 실제 패스를 알기 위해 include 상수들이 필요한 것이다)

이러한 복잡성은 RequestDispatcher와 필터사이의 상호작용에서도 존재한다. 필터가 포워드 된 요청을 호출해야 할까? 포함된 요청은? 메카니즘을 통해 호출된 URI의 경우는 어떨까? 서블릿 2.4 이전에는 이러한 의문들이 공개된 이슈로 남겨졌다. 현재 서블릿 2.4는 이런 것들을 개발자의 몫으로 남겨두었다. 배포 지시자에 요소를 새로 추가하여, 그곳에 REQUEST 그리고 FORWARD, INCLUDE, ERROR와 같은 값들을 설정할 수 있다. 또한 에 사항들을, 다음과 같이, 얼마든지 추가할 수 있다:

Logging Filter
/products/*
REQUEST
FORWARD

이것은 필터가 클라이언트로부터의 직접 요청과 포워드 요청에까지 적용되어야 한다는 것을 말한다. INCLUDE와 ERROR 값을 추가하면, 필터가 인클루드 요청과 요청에 대해서도 적용되어야 한다는 것을 말한다. 원하는 바를 섟고 비교해보라. 아무런 요소를 설정하지 않으면, 디폴트는 REQUEST이다. (역자주: 예전에는 포워드된 페이지에 대해서는 필터를 적용시키지 못했는데, 즉 서블릿 2.4의 REQUEST만이 적용가능했지만, 필터마다 이것을 따로따로 설정할 수 있으니 사용할 곳이 참 많을것 같다)

RequestDispatcher 변화의 마지막은 request.getRequestDispatcher() 호출에, 최초로, 상대 패스를 허용한 것이다. 패스는 현재 호출 패스에 상대적으로 해석될 것이다. 큰 변화는 아니지만, 동료(sibling) 서블릿으로 디스패치될 때 유용할 것이다.

By Jason Hunter (번역 : 세브니)

출처 : Tong - exospace님의 JAVA통

오픈 모바일 플랫폼 전략에 대응하는 우리나라 SW업체들의 전략?

2009-11-20T10:07:41Z

구글의 오픈 모바일 플랫폼 전략에 대응하는 우리나라 SW업체들의 전략은 어떤것들이 있을까?

지금까지는 오픈 모바일 플랫폼과 관련해서 주로 정부나 제조업체, 통신서비스업체등에 집중되어 있지만
실제 중요한 애플리케이션들과 이를 개발하기 위한 국내 SW업체들의 전략적인 접근이 별로 소개되고 있지 않고 있습니다.정말 애플의 앱스토어에 애플리케이션을 올려 판매하는 전략외에는 없는 것인지?
다른 접근방법은 없는것인지 SW개발 업체로서 고민을 해보고 싶다.

애플의 앱스토어에 앱을 만들어 올리는것만으로 상당히 많은 기회와 변화가 생기게 되었다.

그런데 거기까지인 것인지?

앱이 무엇인지? 개발자 한두명이 아이디어만 가지고 사업이 되는건 아닐텐데..

좋은 아이템 만들어서 다운로드 많이 되면(잘팔리는 애플리케이션 만드는거..) 그다음은 무엇이 있는가?

애플과 달리 우리가 오픈 플랫폼인 안드로이드에 더 관심을 가져야 하는 이유가 여기에 있지 않을까?

플랫폼에 더 많은 자유가 주어졌다는 것은 더 많은 기회를 제공해주는 것이고

이러한 기회는 90년대 자바라는 플랫폼에서 답을 찾을수 있을 것 같다. 자바라는 언어 자체가 새로운 비지니스를 만들어 낸것이라고 보기에는 힘들겠지만 새로운 비지니스가 조금은 더 쉽게 가능하게 해주는 도구로서 역할을 해왔다고 보여지고 실제 많은 SW개발 업체들은 자바라는 언어를 이용해서 개발을 하고 있다.

이러하 자바라는 언어가 가진 기본 사상과 개념을 안드로이드 역시 그대로 가져가고 있다고 본다. 그 범위가 OS 영역으로 확대되고 단순한 모바일 환경 만이 아닌 다양한 기기에 탑재될 가능성이 있기에 스마트폰의 애플리케이션만의 시장으로 보기에는 너무나 범위가 작다.

앱스토어에 애플리케이션을 올리면 아이폰 말고 다른 기기에서 돌아가게끔 하기에는 상당히 어려울것이고

애플만의 힘으로는 확대해나가기 힘들다고 본다. 안드로이는 이러한 다양한 환경에 적용이 가능하고 점점 많은 기기에 탑재되어 단일기기의 플랫폼이 아닌 환경에서도 동일한 애플리케이션으로 동작이 가능하게 되는 장점이 있다고 본다.

...............

스마트폰 OS

2009-11-12T09:56:40Z

정보통신 전략 수업에 대한 간략 정리..

스마트폰 OS 전략

스마트폰에 대한 정의

최근 모바일 환경에서 가장 중요한 스마트폰에 대한 관심이 급증하고 있습니다.

스마트폰의 정의가 "휴대폰 + 휴대용 컴퓨터"로 기본적인 휴대폰의 기능외에 인터넷이 가능한 컴퓨터 운영체제를 포함한 제품을 의미합니다.

스마트폰의 시장동향과 스마트폰의 가장 중요한 OS에 대한 각사의 전략에 대해 확인해보고자 한다.

휴대폰의 시장 점유율과 노트북의 시장 점유율을 넘어서게 될것이라는 보고서도 있습니다.

각사의 휴대폰 전략

애플 아이폰

구글 안드로이드

노키아 심비안

삼성 바다

각사의 스마트폰 OS에 대한 전략을 비교 분석하고
국내 스마트폰 시장과 스마트폰 애플리케이션에 미치게 될 영향을 분석하고
국내 SW업체들의 대응 전략에 대해 살펴보고자 한다.

국내 업체들 현황

WIPI플랫폼

tag : 스마트폰

SpringSource dm Server

2009-11-10T17:28:23Z

SpringSource 홈페이지 소개

SpringSource dm Server는 완전한 모듈 기반의 자바 애플리케이션 서버로 엔터프라이즈 자바 애플리케이션들과 스프링 기반 애플리케이션들을 상당한 수준의 유연성과 신뢰성을 가지고 동작될수 있도록 디자인 되었다. 간단하지만 포괄적인 플렛폼을 제공하여 자바 애플리케이션들을 개발하고 배치하고 서비스할수 있도록 해준다.

음 2.0.0 M 은 jdk1.6이 기본이라...

시스템이 점차 복잡해져 가면서 다양한 애플리케이션들이 추가되어야 할 필요가 있는데 간단한 경우는 기존 애플리케이션을 확장하는 경우가 있고..아니면 동일하게 환경을 구성해서 독립적으로 추가하는 경우가 있다..문제는 이 두 애플리케이션들이 통합되어야 할 경우 기존 애플리케이션 수정하기에는 너무 복잡하다면..아예 새로 개발하는게 낫다.

OSGi라는 것에 대해서 공부해보자...

tag : osgi, dm Server

스마트폰과 에디터

2009-11-10T16:18:19Z

스마트폰에 에디터를 붙일수 있을까?

바로 지금쓰고 있는 에디터를...

못할건 없겠네...스마트폰에 브라우저가 있으니..머..그냥 써도 되겠네..

스마트폰을 사서 써바야...알겠당.

tag : 스마트폰

Action상속 관련

2009-11-09T11:23:08Z

상속 개념을 제대로 알고 쓰자.

게시판에서 다양한 유형의 기능을 가진 형태가 존재한다.

일반적인 공지형

답글이 있는 Q&A형

자료파일이 있는 자료실형

이미지를 대표하는 앨범형

블로그처럼 내용이 함께 표시되는 블로그형

이처럼 다양한 형태가 존재하지만 게시판이라면 공통적인 속성과 기능을 추상클래스로 정의가 가능할텐데..

그렇다면 AbstractList와 같은 게시판 목록의 추상 클래스하나 만들고

각각을 자식 클래스로 구현하면..유형이 많아질수록 클래스가 많아지고..

하나의 클래스로 처리하자니 계속 복잡해지고..

관리가 편한것은? 확장이 편한것은?

정답은 어디에 있을까?

tag : 상속, 객체지향

The Attention Question in Social Business

2009-10-09T10:16:40Z

Socialwrite.com

The story goes like this: In 1865 Coal was a big deal. A lot of R&D work was being done on how to make better use of coal. Make it burn hotter, make steam faster, make it burn more quickly, etc.

This guy, James Watt, had a big breakthrough. He created a steam engine that was far more efficient than the old models. It was more powerful, smaller and used less coal. This was great news and it got a lot of attention, and the orders for his engines came flowing in. Before long Watt’s engine was being used all over the place. In fact, because it was so efficient coal was now being used in more places and for more things than ever before.

And so this guy named William Jevons started to study the use of Coal. Think of him as the fringe peak-oil alarmist of his time (who was, well, right…). He wrote a book called “The Coal Question” and in it he surmized that there is a paradoxical effect when you increase the efficiency with which a resource is used:

increases the efficiency with which a resource is used, tends to increase (rather than decrease) the rate of consumption of that resource.

This was extremely counter-intuitive to people at the time, and I believe it remains so today. In fact, just yesterday Paul Kedrosky noticed it in terms of electricity consumption and the increasing energy efficiency of batteries. We strive for increased fuel efficiency, but it is possible that we would simply accelerate the consumption of Oil if we were to do so. It is likely in fact that driving is bound, by some degree, to economic affordability and that more people would drive further if it were more cost effective.

Attention as resource

I was proudly recounting Jevons’ Paradox to my colleague Pete the other day. I was actually surmising that if Kate had a more powerful computer, she would simply run more programs all at once and it would eat up any gain in processing power that she would get through buying a faster computer. I was feeling good about the genius of the whole thing and mentioned that I was curious how this paradox could be applied to Enterprise 2.0 when Pete quipped “well, attention is the resource.”

A lot of thinking has gone on around the idea of Attention as a resource that should not be abused or depleted and it is certainly a productive way to think about it, but on the other hand we are constantly looking for more and more efficient ways to utilize that attention. Twitter is a more efficient use of attention through its smaller and faster messages, instant messaging increases the efficiency of many interactions, wikis make more efficient use of the attention paid to long form content, etc.

We may be falling for the fallacy that enables Jevons’ Paradox, and by doing so we may be pushing people to the limit of their capability, even though we intend the opposite.

The implications for Social Business

Enterprise 2.0 (and Web 2.0 in general) is a great example of technology increasing the efficiency of the consumption of a resource. By being social we are creating more efficient and useful filters and information sharing capabilities. Whether it is expertise location on an internal social network or the ease with which we can share family photos, we have more efficient ways than ever to interact with large groups of people.

And so there is a challenge for one of the fundamental assumptions of Enterprise 2.0: that increasing the efficiency with which people connect and collaborate will allow for emergent or unexpected outcomes.

Helping create emergent outcomes is core to what we do at Dachis Group, so we have been thinking about it a lot.

The challenge is this: by simply increasing the efficiency through which people connect and collaborate, we may paradoxically consume even more of their attention because it is now easier for them to connect with people. This can lead to a depletion of their ability to do useful things with their new connections because they will be too busy monitoring, maintaining and developing their networks.

Design with intent

To me this is a question of design and intent, and to some degree it brings up the question of whether much of what has been going on in Enterprise 2.0 is in fact a crock.

We need to stop designing tools and platforms which are simply meant to allow people to connect, share and collaborate more. In doing this we are being incredibly irresponsible with the resource we value most. Instead we need to design for business intent and utilize our efficiencies as tools to help solve real business problems.

It is only by creating more efficient ways for workers to do the job they are expected to do that we can create the space and time they need in order to create emergent outcomes. This applies not only to software, but strategy as well. As people become more efficient through the use of Social Business tools, the surplus attention that they create needs to be protected through policy.

It is only through the application of both technological and strategic efforts that you can do both, and that we can avoid falling victim to Jevons’ Paradox.

quartz..에서 헤매다..

2009-08-13T18:21:26Z

스프링을 2.5로 업그레이드 하고 quartz를 예전 방식대로 그대로 썼다..

            xxxx.xxxJob

            0 52 14 * * ?

그런데 알수 없는 오류가..TT

Caused by: org.quartz.SchedulerConfigException: Failure occured during job recovery. [See nested exception: org.quartz.impl.jdbcjobstore.LockException: Failure obtaining db row lock: ORA-00942: 테이블 또는 뷰가 존재하지 않습니다
[See nested exception: java.sql.SQLException: ORA-00942: 테이블 또는 뷰가 존재하지 않습니다
]]
at org.quartz.impl.jdbcjobstore.JobStoreSupport.initialize(JobStoreSupport.java:493)
at org.quartz.impl.jdbcjobstore.JobStoreCMT.initialize(JobStoreCMT.java:144)
at org.springframework.scheduling.quartz.LocalDataSourceJobStore.initialize(LocalDataSourceJobStore.java:133)
at org.quartz.impl.StdSchedulerFactory.instantiate(StdSchedulerFactory.java:1010)
at org.quartz.impl.StdSchedulerFactory.getScheduler(StdSchedulerFactory.java:1152)
at org.springframework.scheduling.quartz.SchedulerFactoryBean.createScheduler(SchedulerFactoryBean.java:575)

웬 테이블을 못찾는다는 건지..이것 저것 찾아보니..quartz에서 job을 메모리가 아닌 db로도 관리할 수 있고...

데이타베이스별로 스크립트를 제공하는것을 알게 되었다..

그런데.. quartz.jar에서 quartz.properties파일을 보면.. 디폴트로 아래와 같이 되어 있다.

(이번에 이파일이 있다는걸 처음 알았다)

org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

이건또 머지..한참을 헤매다가.. autowire="no"를 해주니..정상으로 도네요..

이런 삽질을 하게된건 제대로 알고 쓰지 못해서 생긴문제겠죠..

    autowire="no">

tag : quartz, autowire

BPM이란

2009-04-14T19:29:47Z

출처 : 싱글PPM추진본부- 품질혁신 e-Mail 교육 자료

BPM(Business Process Management)은 업무에 대한 중복을 제거하고 업무의 자동화를 통한 대내외 비즈니스 프로세스의 효율화 추진, 프로세스 설계 및 실행을 위한 시스템을 만드는 수단이 필요, 시스템, 사람, 정보, 장치를 포함하는 프로세스의 통합적 지원, 프로세스들이 어디에서 만들어지건 또 서로 다른 기술적 하부구조가 상호 배타적이건 간에 관계없이 프로세스들이 자연스럽게 통합되고, 협업하고, 결합하고 분해하도록 지원하는 것이다.

1. 기업 환경

(1) 21세기 기업 경영의 과제

□ 21세기 기업경영의 과제

- 피터 드러커교수는 그의 저서 “21세기 기업경영의 과제”에서 미래기업의 추구해야 할 바람직한 목표 제시하고 비즈니스 프로세스 경영을 강조

□ 미래기업의 바람직한 2가지 목표

- 비즈니스와 관련된 경제 환경, 시장, 경쟁사에 대한 정보 획득에 필요한 체계화되고 시스템화된 방법

- 여러 가지 별개로 이루어지던 일들, 즉 가치분석, 프로세스 분석, 품질관리, 그리고 원가관리를 하나의 분석체계로 통합화

(2) 비즈니스 프로세스 경영 : 제3의 물결

□ 기업의 경영혁신 패러다임이 실제화 되고 있음

- 부문 최적화에서 전체 최적화

- 경영전략과 연계된 혁신활동 전개

- 기능적 개별 혁신활동에서 통합적 혁신활동

- IT는 기술적 도구라는 제한성에서 혁신활동과 IT의 연계

- 기능적 조직관리에서 프로세스 지향적 조직 운영

□ 프로세스 경영의 요구사항

- 업무에 대한 중복을 제거하고 업무의 자동화를 통한 대내외 비즈니스 프로세스의 효율화 추진

- 프로세스 설계 및 실행을 위한 시스템을 만드는 수단이 필요함

- 시스템, 사람, 정보, 장치를 포함하는 프로세스의 통합적 지원

- 프로세스들이 어디에서 만들어지건 또 서로 다른 기술적 하부구조가 상호 배타적이건 간에 관계없이 프로세스들이 자연스럽게 통합되고, 협업하고, 결합하고 분해하도록 지원

- 고질적으로 비즈니스와 IT분리현상에서 발생하는 비효율을 제거

- 활동기준원가(ABC)와 같은 핵심 비즈니스 지표들을 비즈니스 프로세스의 실행으로부터 직접적 도출

- 프로세스에 대한 책임을 명확히 하고 투명성과 지속성을 가짐

- 가치사슬(Value Chain)과 같은 복잡한 프로세스의 실행을 매우 단순화시킴

- 기업간 협업이 물 흐르듯이 처리되고 관리되고 모니터링 될 수 있도록 지원

- 과거의 기술과는 달리 비즈니스 운영이 자연스럽게 이루어지는 가운데 비즈니스 프로세스가 자동으로 도출될 수 있는 가능성 제공

- 가상 조직을 위한 프로세스의 가치관리 분석의 제공 등

(3) 제3의 물결 “BPM”의 등장

□ 최근 기업의 환경

- 기업 활동 영역의 글로벌 화

- 경쟁의 심화, 기업 활동의 복잡성 증가

- 핵심역량의 강화 및 다양한 파트너십 필요성 증대

- 비즈니스 환경의 변화에 보다 신속하고 유연한 대응 필요

□ 기업의 당면과제

- 환경의 변화에 적절히 대응하지 못하는 많은 기업

- 유연하지 못한 프로세스. 정보시스템, 신속하지 못한 대응

- 데이터의 중복?손실 ,업무의 중복?오류?지연 및 파악되지 않는 문제점

- 높은 운영 원가 및 낮은 업무 생산성

□ 리엔지니어링 실패의 이유와 제3의 물결 관점

리엔지니어링 실패 이유	제3의 물결 관점
프로세스를 재창조하기보다 고치려고 한다.	매끄럽고 분명히 정의된 경로와 관리 라이프사이클을 통해 점진적 개선에서 급진적 변화로의 연결을 이끌어야 한다.
프로세스에 초점을 두지 않는다.	프로세스는 비즈니스를 바라보는 유일한 관점이다. 관리자들은 그들에게 편리한 시스템과 메타포를 이용해서 프로세스를 관리할 수 있어야 하고, 프로세스 경영 시스템은 사용자의 역할과 요구에 적합한 관점을 제공해 줄 수 있어야 한다.
프로세스 설계 외의 혼란이 존재한다.	프로세스 관리는 모든 구성원들 업무의 일부분이며, 그들에게 필요한 프로세스 관리도구가 제공되어야 한다.
작은 성과에 안주하려고 한다.	점진적인 개선이 모여 의미 있는 성과달성이 이루어진다. 특히 경기불황인 상황에서는 급진적이고 불연속적인 변화는 바람직하지 않다
리엔지니어링에 필요한 자원을 아낀다.	프로세스 관리를 위해 추가인력이 필요해서는 안 된다
문제 정의와 재설계 범위를 미리 제한한다.	프로세스를 관리하기 위해 임원들이 부여하고자 하는 모든 제약 요소들을 고려해야 한다. 왜냐하면 그들은 담당하고 있는 시장의 모든 내용을 다른 누구보다도 잘 이해하고 있기 때문이다
엔지니어링을 시도조차 할 수 없는 기업문화와 경영풍토가 존재한다.	프로세스 관리는 직원들에게 두려움을 불러일으키는 것이 아니라 비즈니스의 자연스러운 부분이어야 하며, 그 결과는 측정될 수 있고 예측가능해야 한다.
상향식(bottom-up)으로 추진한다.	개선은 종종 내부에서 일어나며, 유fork 어디든 상관없이 베스트 프랙티스를 만들어서 확산시켜야 한다. 또한 다른 조직에게 맞게 프로세스를 수정해서 재현할 수 있어야 한다.
리엔지니어링을 이해하지 못하는 사람을 팀 리더로 한다.	프로세스 관리도구와 방법들은 마치 오늘날의 스프레드시트(spreadsheet)와 마찬가지로 비즈니스를 수행하는 사람들이 직관적으로 이해할 수 있어야 한다.
대규모의 많은 리엔지니어링 프로젝트로 인해 조직의 에너지를 분산시킨다.	프로세스 경영 시스템은 수많은 프로세스를 동시에 관리할 수 있는 환경을 제공해야 한다.
퇴직을 2년 앞둔 CEO가 리엔지니어링을 시도한다.	프로세스 경영의 성공은 핵심적인 몇몇 개인에 달려 있지 않고, 과학적이고 시스템적인 사고에 달려 있다.
다른 비즈니스 개선 프로그램들과는 상이한 리엔지니어링의 독특한 속성을 인식하지 못한다.	프로세스 경영은 새로이 채택해야 하는 또 하나의 경영이론이 아니다. 이것은 현재의 전략을 실행하도록 돕는 실용적인 도구이다.
세부 프로세스 설계에 지나치게 집중한다.	세부 프로세스 설계는 유용하다. 프로세스 맵핑도구를 이용하여 더욱 쉽게 다양한 프로세스 모델을 생성할 수 있으며, 이것은 변화가 필요한 영역을 명확하게 한다.
프로세스 변화에 사람들이 저항할 때 이를 포기한다.	협업적 프로세스 경영은 모든 사람들을 프로세스 설계와 프로세스 전개 프로세스에 참여시키는 방법을 제공한다.
노력을 질질 끈다.	프로세스 경영은 프로젝트가 아니며, 실시간 업무 활동이다.
리엔지니어링이 기업의 의제들(Agenda)속에 묻혀 버린다.	프로세스 경영은 기업 의제들 가운데 별도의 의제가 되어서는 안 되며, 의제들을 구현해야 하는 것이다.
너무 일찍 포기한다.	라이프사이클 경영에서 주기적인 프로세스 개선은 비즈니스 측면에서 수용하지 못할 정도로 오랜 시간이 소요되어서는 안 된다.
모든 사람의 기분을 맞추면서 리엔지니어링을 시도한다.	변화는 본질적으로 고통스러운 것이며 이간은 변화를 좋아하지 않는다. 그러나 BMP은 구성원들이 업무를 보다 효율적이고 좀 더 쉽게 수행할 수 있도록 도와주는 유용한 도구이다.

2. 경영 혁신 Trend

(1) 경영혁신의 Trend

□ 경영이라는 단어가 생긴 이래 모든 기업에서는 생산성을 향상시키기 위해 많은 노력을 기울여 왔으며, 이 노력의 중심에는 언제나 비즈니스 프로세스에 대한 효율적 관리가 있었음

(2) 프로세스 경영의 중요성 대두

① 프로세스 경영의 Wave

□ 기업의 DNA인 프로세스를 개선하기 위한 프로세스 경영은 이미 3차례의 Wave를 겪어오고 있음

Reengineering Management : 프로세스 자체의 관리를 통한 개선과 유연한 프로세스 변경을 추구

2nd Wave(1990년대 중반) : 프로세스를 잘 설계하고 자동화하여 고착시킴

1st Wave(1990년 초반) : 프로세스의 근본적이고 급격한 개선 추구와 프로세스에 대한 관심 증가

[프로세스 경영의 3차례 Wave]

② 1st Wave - BPR

□ BPR은 회사의 업무 프로세스를 근본적으로 개혁하여 기업의 생산성을 높였지만, 프로세스개선을 지속화하지는 못함

□ 조직(기능)중심의 성과 관리 구조와 이해상충 발생

□ 일회적이며 간헐적인 프로세스 개선 노력

□ 구현과정보다는 설계과정이 길고 경영진의 관심이 집중되어 실현된 효과에 대해서는 무관심

□ 프로세스 개선 효과의 퇴색

□ 표준 프로세스로부터의 이탈(Process Deviation) : 개선된 프로세스의 변형이 생김

③ 2nd Wave - ERP

□ ERP는 개선된 프로세스를 고정화하여 프로세스의 변형과 회귀를 막았지만, 개선범위와 경쟁우위지속, 프로세스 변경의 유연성에 대한 한계를 가짐

□ ERP내에 내장된 선진 프로세스와 타 사의 벤치마킹 내용을 반영하여 ERP를 구현하여 경쟁력 있는 프로세스를 고착시킴

□ 개발 시스템보다는 시스템간의 통합성을 보장함

- 주로 빅뱅(Big- Bang) 또는 모 아니면 도(All-or-Nothing)접근방법을 취하여 구현함

□ 개선 범위의 한계 : 주로 경영관리 영역에 치중함

□ 경쟁우위 지속이 어려움 : 타 사도 비슷하거나 동일한 내용의 프로세스를 구현하여 경쟁우위가 쉽사리 무너짐

□ 프로세스 변경이 어려움 : 시스템의 통합성 때문에 ERP에 내재된 프로세스를 쉽게 변경하기가 어려움

[경영혁신 도입 이유]

④ 3rd Wave - Reengineering Mgt

□ 보다 개선 프로세스의 효과를 장기화하고 개선을 지속하기 위해서 프로세스 개선을 관리화함

□ 프로세스의 관리 : 정적인 정보 관리에서 동적인 프로세스 관리로 중심적 이동

tag : BPM

CMMI(Capability Maturity Model Integration) 소개

2009-04-14T11:20:55Z

출처 - http://spic.kaist.ac.kr/part_cmmi.html

CMMI(Capability Maturity Model Integration) 소개

● SEI의 CMMI 공식 홈페이지 (http://www.sei.cmu.edu/cmmi)

● 등장배경

CMM들이 1991년 이래로 수많은 분야들을 위해 개발되었는데, 대표적인 CMM으로 SW-CMM, SE-CMM,
SA-CMM, P-CMM, IPD-CMM이 있다. 이러한 모델들이 많은 조직들에서 유용하다는 것이 증명되었음에도 불구 하고 다중 모델들의 사용은 여러 문제점들을 야기시킬 수 있다. 많은 조직체들이 여러 모델들에 있는 경험들을 공유하여 자신의 프로세스를 개선시키길 원하고 있다. 그러나 이러한 분야 중심의 모델들 간의 차이, 즉 구조, 내용, 접근 방식의 차이들이 조직의 프로세스 개선 노력에 제약을 가할 수 있다. 게다가 다중 모델의 적용은 교육 비용, 평가비용, 개선활동의 비용을 높일 수 밖에 없다. 따라서 CMMI 프로젝트가 여러 CMM들을 사용했을 때의 문제들을 정리하기 위해 발족되었고, 이 프로젝트 팀은 다음과 같은 여러 CMM 모델의 통합을 목적으로 삼게 되 었다.

● 모델 표현(Representation)

CMMI의 모체가 되었던 CMM 모델들 모두가 능력도-성숙도 모델이지만 이들은 서로 다른 접근방식을 가지고
있다. 이러한 형태의 접근방식을 프로세스 개선 커뮤니티에서는 “표현(representation)”이라고 지칭한다.

표현은 모델 내의 조직, 사용, 구성요소를 반영한다. 모든 CMM은 레벨에 의해 정의된 프로세스 영역을 가지고 있다. 그리고 CMMI 모델 표현에는 단계적(staged)과 연속적(continuous)의 2가지 형태가 있다.

단계적 표현(staged representation)

단계적 표현은 SW-CMM에서 사용된 접근 방식으로 조직의 프로세스 개선을 위한 방향을 결정하기 위해 프로세스 영역들의 미리 정의된 집합들을 사용하는 방법이다. 개선을 위한 방향은 성숙도 레벨이라고 불리는 모델 구성요소에 의해 기술된다. 성숙도 레벨은 개선된 조직의 프로세스들을 향해 잘 정의된 계층을 의미한다. 그림 1는 CMMI의 단계적 표현에 대해 설명하고 있으며, 5단계의 성숙도 레벨로 구성되어 있음을 보이고 있다.

[그림 1 : CMMI의 단계적 표현]

연속적 표현(continuous representation)

연속적 표현은 SECM과 IPD-CMM에서 사용된 접근 방식으로 세부적인 프로세스 영역을 선택하고 그것과 관련된 것들을 개선할 수 있도록 한다. 이 표현은 개개의 프로세스 영역과 관련된 개선을 할 수 있도록 하기 위해 능력도 레벨을 사용한다. CMMI의 연속적 표현에서는 프로세스 영역들을 4개의 범주로 그룹화하여 사용하는데 4개의 범주는 다음과 같다.

(1) 프로세스 관리(Process Management)
프로세스의 정의, 계획, 배치, 구현, 감시, 제어, 평가, 측정, 개선과 관련된 여러 프로젝트에 걸쳐진 활동들을 포함하는 프로세스 영역들로 구성되어 있다.

(2) 프로젝트 관리(Project Management)
프로젝트의 계획, 감시, 그리고 제어와 관련된 프로젝트 관리 행위들을 다루는 프로세스 영역들로 구성되어 있다.

(3) 공학(Engineering)
여러 공학분야에 걸쳐서 공유되는 개발과 유지보수와 관련된 활동들을 다루는 프로세스 영역들로 구성되어 있다.

(4) 지원(Support)
제품 개발과 유지보수를 지원하는 활동들을 다루는 내용으로, 프로젝트를 목적으로 한 프로세스 영역과 조직에 적용하는 것을 목적으로 하는 프로세스 영역들로 구성되어 있다.

그림 2는 CMMI의 연속적 표현에 대해 설명하고 있다.

여기서 PA(Process Area)는 프로세스 영역을 나타낸다.

[그림 2 : CMMI의 연속적 표현]

● 두 가지 표현과 PA들

위에서 살펴본 두 가지 표현들을 CMMI에서 제공하는 25가지 PA(프로세스 영역)들을 그림 3과 같이 나타낼 수 있다.

[그림 3 : CMMI의 두 가지 표현]

그림 3에서 왼편에는 단계적 표현이 나타나 있고, 각 레벨 별로 관련된 PA들이 구성되어 있음을 볼 수 있다.

또한 오른편에는 연속적 표현이 나타나있고 4가지 범주에 따라 관련된 PA들이 구성되어 있음을 볼 수 있다.

표1은 단계적 표현, 즉 성숙도 수준별로 포함되는 PA들을 설명하고 있다.

[표1: CMMI의 성숙도 레벨별 PA 구성]

Level	Focus	Process Areas
5 Optimizing	지속적인 프로세스 개선 (Continuous process improvement)	조직적 혁신과 배치 (Organizational Innovation and Deployment) 분석과 해결 (Casual Analysis and Resolution)
4 Quantitatively managed	정략적인 관리 (Quantitative management)	조직 프로세스의 성과 (Organizational Process Performance) 정량적인 프로젝트 관리 (Quantitative Project Management)
3 Defined	프로세스 표준화 (Process standardization)	요구사항 개발 (Requirement Development) 기술적 해결 (Technical Solution) 제품 통합 (Product Integration) 검증 (Verification) 확증 (Validation) 조직의 프로세스 초점 (Organizational Process Focus) 조직의 프로세스 정의 (Organizational Process Definition) 조직 훈련 (Organizational Training) 통합 프로젝트 관리 (Integrated Project Management) 통합 외주 업체 관리 (Integrated Supplier Management) 위험 관리 (Risk Management) 의사결정 분석 및 해결방안 (Decision Analysis and Resolution) 통합을 위한 조직적 환경 (Organizational Environment for Integration) 통합팀 구성 (Integrated Teaming)
2 Repeatable	기본적인 프로젝트 관리 (Basic project management)	요구사항 관리 (Requirement Management) 프로젝트 계획 (Project Planning) 프로젝트 모니터링 및 통제 (Project Monitoring and Control) 외주 계약 관리 (Supplier Agreement Management) 측정과 분석 (Measurement and Analysis) 프로세스 및 제품 품질 보증 (Process and Product Quality Assurance) 형상관리 (Configuration Management)
1 Initial

표 2는 연속적 표현, 즉 능력도 수준별로 포함되는 PA들을 설명하고 있다.

[표2: CMMI의 4가지 범주별 PA 구성]

Category	Process Areas
Process Management	조직의 프로세스 초점 (Organizational Process Focus) 조직의 프로세스 정의 (Organizational Process Definition) 조직 훈련 (Organizational Training) 조직의 프로세스 성과 (Organizational Process Performance) 조직적 혁신과 배치 (Organizational Innovation and Deployment)
Project Management	프로젝트 계획 (Project Planning) 프로젝트 모니터링 및 통제 (Project Monitoring and Control) 외주 계약 관리 (Supplier Agreement Management) 통합 프로젝트 관리 (Integrated Project Management) 위험 관리 (Risk Management) 통합팀 구성 (Integrated Teaming) 통합 외주 업체 관리 (Integrated Supplier Management) 정량적인 프로젝트 관리 (Quantitative Project Management)
Engineering	요구사항 개발 (Requirement Development) 요구사항 관리 (Requirements Management) 기술적 해결 (Technical Solution) 제품 통합 (Product Integration) 검증 (Verification) 확증 (Validation)
Support	형상관리 (Configuration Management) 프로세스 및 제품 품질 보증 (Process and Product Quality Assurance) 측정과 분석 (Measurement and Analysis) 통합을 위한 조직 환경 (Organizational Environment for Integration) 의사결정 분석 및 해결방안 (Decision Analysis and Resolution) 분석과 해결 (Casual Analysis and Resolution)

● 프로세스 영역 구성요소
이 절에서는 각 프로세스 영역을 구성하는 구성요소들에 대해 설명하고자 한다. 프로세스 영역 구성요소는 3가지 범주로 그룹화되는데 그 내용은 다음과 같다.

필수 구성요소(Required Components)
조직이 프로세스 영역을 만족시키기 위해 무엇을 성취해야 하는지를 기술하는 구성요소이다. 세부 목표(specific goal)와 일반목표(generic goal)가 이에 해당한다. 목표를 만족시키는 것은 프로세스 영역이 만족되었는지를 결정하기 위한 기반으로 평가 시 사용된다.

예상 구성요소(Expected Components)
조직이 필수 구성요소를 성취하기 위해 전형적으로 무엇을 구현해야 하는지를 기술하는 구성요소이다. 이 구성요소들은 누가 평가를 수행하고 개선을 구현하는지를 가이드한다. 세부 지침(specific practice)과 일반 지침(generic practice)들이 이에 해당한다.

정보 제공 구성요소(Informative Components)
어떻게 필수 구성요소와 예상 구성요소들을 접근하는지에 대해 시작할 수 있도록 돕는 세부 내용들을 제공한다. 하위지침(subpractice), 산출물(typical work products), 적용분야 공지(discipline amplification), 일반 지침의 세부설명(generic practice elaboration), 목표와 지침 제목(goal and practice titles), 목표와 지침의 노트(goal and practice notes), 참조(reference)가 이에 해당한다.

그림 4는 프로세스 영역의 구조를 도식화 한 것이다.

[그림 4: 프로세스 영역의 구조]

● CMMI 적용 현황

CMMI는 현재 국방, 우주항공, 일반 산업체와 기관 등 다양한 분야에 적용되고 있다. 2002년 4월에 SCAMPI class A에 의한 심사가 실시된 이후 SEI의 2005년 1월 발표에 따르면 총 567개의 조직에 630번의 심사가 이루어 졌고 그 중의 약 절반이 미국에 있는 조직들에 의해 실시되었다. 2004년 3월 발표에 따르면 당시 심사를 실시한 조직이 148개였으므로 불과 1년 사이에 CMMI가 빠르게 보급되고 있다고 볼 수 있고 이러한 추세는 계속 될 것으로 전망된다. 각 조직들을 분류해 보면 그림 5과 같다.

[그림 5 : 조직별 분류 ]

그림 6에서 심사를 실시한 전체 조직 중 1/3이 level 2에 머무르고 level 4 이상인 조직은 약 1/4 정도 이다.

[그림 6 : 전체 조직의 Maturity profile ]

조직 크기별로 보면 인원이 100 이하인 조직이 38.5%, 101~200 인 조직이 17.7%, 200이상인 조직이 43.8%이다. 2003년 2월 발표에 따르면 약 50개의 조직에서 심사를 실시하였는데 그 중에서 100이하인 조직 20%를 조금 넘었다. 이러한 경향을 봤을 때 점차로 작은 규모의 조직들에서도 CMMI를 적용하려는 움직임을 알 수 있다.
국가별로 살펴보면 앞서 언급한 것처럼 절반에 조금 못 미치는 280번의 심사를 실시하였고 그 다음으로 일본이 77번, 인도가 70번, 중국이 34번의 심사를 실시하였다. 특히 한국은 1년 전인 2004년 7월의 통계에 의하면 10개 이하의 심사를 실시하였으나 2005년에는 23번의 심사를 실시하여 6번째로 심사를 많이 실시한 국가가 되었다. 국가별 심사 상황은 그림 7에 나타난다.

[그림 7 : 국가별 심사 현황 ]

위의 통계들을 종합해 보면 2002년 CMMI가 처음 출시된 이후 미국을 비롯한 아시아권을 중심으로 빠르게 적용되고 있고 작은 규모의 조직들에서도 또한 CMMI를 적용하기 위한 시도들을 하고 있음을 알 수 있다.

tag : CMMI

세션 공유시 서블릿 컨텍스트 참조 문제

2009-04-14T10:51:34Z

두 웹애플리케이션에서 세션을 공유할때 세션을 통해 서블릿 컨텍스트를 참조할때

어떤 서블릿 컨텍스트를 참조할까?

Root WebApp - xxx.co.kr

WebApp1 - xxx.co.kr/app1

두 애플리케이션은 서로 세션공유가 가능하도록 설정되어 있다

이때 xxx.co.kr로 접근하고 xxx.co.kr/app1으로 접근할때 두 애플리케이션간에

세션은 공유되어 있다.

문제는 WebApp1에서 session.getServletContext()를 호출할때 어떤 서블릿 컨텍스트가 반환될까?

애플리케이션의 접근 순서에 따라 다른데 xxx.co.kr을 접근하고 xxx.co.kr로 접근하게되면

xxx.co.kr에서 세션이 생성되고 Root WebApp의 서블릿 컨텍스트를 참조하게 되어서

WebApp1에서 session.getServletContext()는 xxx.co.kr의 서블릿 컨텍스트를 참조한다.

WebApp1에서 자신의 서블릿 컨텍스트를 참조하기 위해서는 session.getServletContext().getContext("/app1")으로 참조해야 한다.

Tomcat의 경우 context에 crossContext 속성을 true로 설정해야 가능하다고 합니다.

tag : 서블릿컨텍스트, 세션공유, crossContext

Week4 WCMS에 대해서

2009-04-01T01:31:19Z

Web 컨텐츠의 특징.

기존 CMS와 차이점은 디지털화된 컨텐츠를 서비스를 하기위해 html또는 xml과 같은 markup으로 변환해서 웹에 올려놓는것이 다르다.

WCM

웹에 특화된 CMS의 형태로 Web Agency의 역할과 같이
웹컨텐츠에 특화된 WCM에 초점을 맞추게 되며 SM(Site Management)기술의 접목으로
통합사이트 관리 환경을 제공한다.

웹2.0

1. 최종 사용자에게 웹 애플리케이션을 제공하는 플랫폼
2. 블로그,검색,지도,태깅등 다양한 기능을 제공하고 고객이 직접이를 활용하는 사용자지향 웹플랫폼
3. 웹사이트에 접근하는 방식을 말하기도함

기업입장에서 WCMS
CMS도입 : 컨텐츠 관리 기능을 하나의 솔루션으로 통합 연계시켜 활용.
CMS에서 언급하는 컨텐츠는 고객에게 서비스되는 모든것을 의미한다.
따라서 택스트,문서,미디어 정보드으이 데이타와 디자인, 프로그램을 포함한다.
기존의 정보관리 제품들은 데이타 자체에 대한 관리만을 고려했으나
컨텐츠를 실제로 서비스하고 관리하기 위한 디자인 및 프로그램을 관리단위로 설정하지 않은 반면
CMS에서는 템플릿 개념을 도입하여 컨텐츠와 프리젠테이션을 분리하는 매커니즘을 사용한다.

1.시스템 구축 및운영

2. 컨텐츠 생성.관리

3. 시장환경 변화대응 측면

iPTV에 대해서....
SVC - Scalable Video Codec
SBC - Server Based Computing

WCM 기술

템플릿을 이용하여 컨텐츠와 프리젠테이션의 분리.

WCM의 가장 핵심적인 기술이 템플릿 및 객체지향적인 콘텐츠 관리 방법으로 콘텐츠와 프리젠테이션을 분리하는것이다. 템플릿의 사용으로 코딩을 전혀 모르는 일반 관리자가 몇가지 규칙을 수정하여 서비스 화면을 재구성할 수 있으며 다자이너가 프로그램이나 콘텐츠에 제약없이 디자인을 변경하더라도 서비스화면에 문제가 발생하지 않는다.

콘텐츠 생성과 유입, 출력시 표준 포맷 사용.

Management(관리란?) - PDCA

PLAN 목표와 필요한 프로세스를 설정

DO 프로세스를 실행.

CHECK 프로세스와 결과를 평가

ACT 평가에 따른 개선 및 프로세스 수정

Homework - 4월말 까지 자료 요약 - 개별적 요약하여 토론

프로젝트 관리 기술

2009-03-14T11:37:48Z

프로젝트 매니저가 갖추어야 할 프로젝트 관리 기술

1. 일정 및 시간관리

=> 프로젝트는 기간이 중요하니 일정, 시간관리 없이는 안되겠지..

2. 기술적 역량(업무 범위내)

=> 업무 범위내 기본적인 기술적 역량이 없으면 의사 소통이나 정확한 판단을 하기 어려움

3.리더쉽(목표 설정 및 성과 측정)

=> 구성원들에게 명확한 목표 제시해 주어야 하며 목표 달성에 대한 성과를 측정하여야 한다.

4. 자원관리, 인간 관계 기술

=> 한정된 자원으로 프로젝트가 진행되므로 자원관리가 반드시 필요

5. 의사 소통 기술

=> 프로젝트 팀은 다양한 조직이나 구성원들이 협업이 필수적이므로 서로 원활한 의사 소통이 되어야 한다.

6. 협상 기술

=> 이해 관계자들간의 상호 배타적인 문제들에 대한 협상이 필요하다.

7. 영업, 계약, 고객 및 관계 관리 기술

=> 프로젝트의 계약관계 및 영업과 고객 관계에 대한 명확한 파악이 필요하다.

8. 예산 책정 및 비용 관리

=> 예산이 제한되어 있기 때문에 프로젝트 수행하는데 소요되는 예산을 책정하고 비용에 대한 관리를 해야 한다.

프로젝트 관리자는 수퍼맨!!

tag : 프로젝트 관리 기술