수아아빠 블로그

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

프로젝트 관리 기술

2009-03-14T11:37:48Z

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

1. 일정 및 시간관리

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

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

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

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

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

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

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

5. 의사 소통 기술

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

6. 협상 기술

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

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

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

8. 예산 책정 및 비용 관리

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

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

tag : 프로젝트 관리 기술

Project 요건 정의시 고려사항

2009-03-14T11:21:22Z

정확한 요건정의가 되지 않으면 프로젝트는 실패를 할 수 밖에 없다.

1. 이해관계자(stakeholder)에 대한 식별

프로젝트와 관련된 이해 관계된 부서나 인력들에 대한 식별이 되어야 하고 이해 관계자 들간의 서로 상충되는 이해 관계를 합리적으로 조정할 수 있어야 한다.

2. 고객이 원하는것과 고객이 예상하는것과 제약사항과 인터페이스

정말고 고객이 원하는것과 예상하는것이 무엇인지 파악해야 하며 프로젝트를 수행하는데 있어서 제한된 시간이나 자원, 기술등의 제약사항을 정확히 전달해 주어야 한다.

3. 고객의 요구사항과 제품의 요구사항 -> 제품 Component 요구사항

4. 인터페이스 요구사항

시스템이 어떻게 다른 시스템이나 사용자와 동작할 것인지에 대한 정의가 필요하다.

5. 요구사항 분석과 검증

고객의 요구사항을 정확히 분석하여야 하며 요구사항에 대한 검증이 필요하다.

6. 기능정의

시스템의 기능에 대한 정의

7. 필요충분조건을 만족하는지 확인

8. 각 이해 관계자간의 요구사항들과 제약사항들을 조율

tag : 요구사항정의

Project란-1week

2009-03-14T11:07:55Z

Project란 무엇인가?

일반적인 업무와 무엇이 다른가?

Project는 일정 기간동안 진행되며 유일성을 갖는다는 점에서 일반적인 운영(Operation)이나 업무의 반대 개념이다.

1. 강의 목적

이 강의에서 배우게 될 내용은..

1. 프로젝트에 대한 이론과 원리

2. 문제해결과 다른사고 방식들에 대한 이해

3. 실제 현장에서의 사실적인 지식

4. 전문적인 지식과 관점을 향상

5. 자신감과 자기수양(self-descipline)을 고취

이 강의를 마치고 나면 할수 있는것들..

1. 프로젝트와 다른유형의 업무들간의 차이점과 유사점을 명확히 구분할수(articulate) 있다.

2. 비지니스 케이스를 확립하여 프로젝트를 정의할 수 있다.

3. 프로젝트 헌장(charter)를 개발할 수 있다.

4. 프로젝트의 WBS(work breakdown structure)를 개발할 수 있다

5. 작업의 소요기간을 추정하고 리소스를 배정할 수 있다

6. 작업들간의 상호 의존성을 설정할 수 있다.

7. 네트웍 다이어그램을 분석하고 작성할 수 있다.

8. 프로젝트 리스크를 식별하고 리스크 완화(mitigation)전략을 수립할 수 있다.

9.프로젝트의 단계적인 확장(escalation) 케이스를 식별하고 문제가 있는 프로젝트들을 감소시키는 방법을 배우게 된다.

=> 배운다고 다 할 수 있는건 아니지만 그래도 모르고 있는것 보다는 훨씬 가치가 있을것 같다.

평균적으로 우리가 기억하게 되는것은

우리가 읽는것의 20%

우리가 듣는것의 30%

우리가 보는것의 40%

우리가 말하는것의 50%

우리가 행가는것의 60%

우리가 보고 듣고 말하고 행동하는것의 90%

=> 더많이 듣고 보고 말하고 행할 수록 배우기는 쉬워진다.

D.R.O.P

Delivery : 실습이 끝날 때 만들어 낼것.

Resource : 실습에 쓰일 자원들.

Objective : 실습을 하는 목적.

Process : 준비시간이나 목적

tag : 프로젝트, Operation

스트러츠와 스프링 연동 샘플..

2009-02-25T11:41:32Z

스트러츠 Action을 Spring과 연동

1. struts.properties파일

struts.objectFactory 주석을 풀어줍니다.

#struts.objectFactory = spring
struts.objectFactory = spring

디폴트로 name으로 되어 있습니다.

그대로 둡니다..

struts.objectFactory.spring.autoWire = name

2. 스트러츠 Action을 생성하고 Action에서 사용할 서비스를

public class StrutsAction implements Action, Preparable, ModelDriven {

List list;

SpringService springService;

    /**
     * springService을/를 설정한다.
     */
    public void setSpringService(SpringService springService) {
        this.springService= springService;
    }

    public String execute() throws Exception {
        list= springService.getList();
        return SUCCESS;

}

    public void prepare() throws Exception {
        list= new ArrayList();
    }

    public Object getModel() {
        return list;
    }

}

3.스츠러츠 Action을 스프링 설정파일에 등록합니다.

autowire=name으로 등록되어 있기 때문에 action만 등록해주어도 Action에 사용하려면 bean이

지정됩니다.

이렇게 하면 스트러츠 Action을 spring에서 쉽게 관리가 가능해지기 때문에

여러모로 편리한 장점이 있을것으로 생각됩니다.

스프링 2.x 이상에서는 scope를 prototype으로 해주어서 요청마다 strutsAction이 생성되게 해야 하고

이전버전에서는 sigleton="flase"를 지정해주어야 합니다.

tag : spring, 스트러츠2

Struts2 action을 sitemesh에서 호출할때

2009-02-25T11:00:12Z

decorator에서 특정 영역을 다른 action으로 호출해서 다른 decorator를 적용할때

아래와 같이 해주면 됨...

            flush="false"/>

반드시 strtus2 ActionContextCleanUp 필터를 다른 필터들보다 먼저 적용되도록

web.xml에 선언해서 applyDecorator의 daction수행시 필요한 정보가 없어지지 않도록 해야

제대로 처리가 된다.

ActionContextCleanUp 필터 : 필터 기반의 타 프레임워크 혹은 단위 필터 모듈의 작동을 지원하기 위한 선택적인 필터 입니다. 기본적으로 FilterDispatcher 필터는 액션 요청의 처리가 끝났을 때, 요청 자체에 설정된 정보들을 삭제 합니다. 이때 타 필터에서 필요로 하는 정보들까지 삭제 될수 있으므로 이러한 정리 작업을 FiterDispatcher가 직접하지 않고, ActionContextCleanUp에게 위임 하면서 다른 필터들이 FilterDispatcher 필터와 ActionContextCleanUp 필터 사이에 실행되도록 함으로서, 필요한 정보의 손실을 막을 수 있습니다

        struts2-cleanup
        org.apache.struts2.dispatcher.ActionContextCleanUp

다만 flush를 false로 해주지 않으면..

다음 경고가 발생합니다.

[WARN ] 09/02/25 10:24:14.404 [com.opensymphony.xwork2.util.logging.commons.CommonsLogger] (CommonsLogger.java:49)
- error while trying to flush writer
java.io.IOException: Illegal to flush within a custom tag
at javax.servlet.jsp.tagext.BodyContent.flush(BodyContent.java:80)
at org.apache.struts2.components.ActionComponent.end(ActionComponent.java:167)
at org.apache.struts2.views.jsp.ComponentTagSupport.doEndTag(ComponentTagSupport.java:42)

tag : 스트러츠2, sitemesh

이클립스 XML Schema Validation 에러

2009-01-06T09:52:20Z

새로 프로젝트를 다운받았 프로젝트 속성의 Validation속성을 변경했는데..

다른 프로젝트와 달리 한놈이 에러가 남..

The validator XML Schema Validator is a delegating validator but no delegate can found for it

원인이 뭘까 생각하면서 Project Facets를 바꿔바도 마찬가지..

XML Schema Validation옵션을 끌까 하다가..

구글에서 검색해보니..음..어라..XML Schema Validation옆에 버튼이 있네..

tag : 이클립스, XML Schema Validation

상품기획시..고려사항(퍼옴)

2008-12-09T13:59:56Z

정말 맘에 드는 방식이네요..이런식으로 생각을 해보긴 했을텐데..

실제로 적용하는건 쉽지가 않을것 같네요.

출처 : http://www.zdnet.co.kr/itbiz/column/opinion/0,39033676,39174058,00.htm

상품 기획시...

1)필수기능(기대수준 고, 만족도 저)
-경쟁 제품과 동일한 기능으로 차별화가 안 되는 기능이다.
-과거에 없던 기능이 새로이 추가된다 하더라도 매출 성장비율은 변화 없다(매출 레버리지 효과 1.0로 정함)

2)부가기능(기대수준 고, 만족도 고)
-경쟁 제품이 가지고 있지 않은 기능으로 구매 유도력을 가진 기능이다.
-새로운 기능이 추가되면 매출 성장비율이 증대할 것으로 예상한다. (매출 레버리지 효과 1.5배로 정함)

3)혁신기능(기대수준 저, 만족도 고)
-구매자가 인지하지 못하였던 탁월한 기능으로 조만간 강력한 구매 유도력을 발휘할 기능이다. 일단 알고 사용한 이후에는 맛들여 경쟁사로 변경할 수 없는 매력적인 기능을 말한다. 경쟁사가 동일한 기능을 갖추기 위해서 상당한 노력이 필요하다.
-판매와 함께 매출 성장비율의 획기적 향상을 예상한다.(매출 레버리지 효과 2.0배로 정함)

webtob 가상 호스트 설정...삽질기..

2008-11-27T21:23:47Z

내가 개인적으로 제일 싫어하는 제우스와 웹투비...

싫어할만한 이유는 사실 없는데..많이 사용해보지 않았다는거랑..예전에 포팅시 제일 문제가 많았던..

이번에도 웹투비와 제우스....당연히 티맥스에서 지원이 있을줄 알았다

그런데..솔루션 포팅하는데..웹투비와 제우스에 설치 메뉴얼을 달란다..

패키지형태는 아니어서..포팅이 바로 되는것도 아니고 웹애플리케이션이라는게 한방에 설치되는것도 아니고 설정도 여기저기 손봐야 하는것이고 테스트 서버에 포팅하고 작성해주기로 했다.

그런데 문제는 하나의 제우스 서버에 블로그와 카페를 설치하는데 도메인을 blog.xxx.com과 cafe.xxx.com으로 접속할 수 있게 해달라고 했다. 서버 관리하시는 분과 저희쪽과 커뮤니케이션이 처음에 안되서 고생을 했다.

웹투비 가상호스트 설정예

vhostClub   HostName = "cafe.xxxxx.com",
   Port      = "80",
                       IndexName = "index.html",
   DOCROOT   = "/web/cafe",
   NodeName = "webtbo_node",
   ServiceOrder = "ext,uri",

..........

vhostBlog   HostName = "blog.xxxx.com",
   Port      = "80",
                        IndexName = "index.html",
   DOCROOT   = "/web/blog",
   NodeName = "webtbo_node",
   ServiceOrder = "ext,uri",
   ........

그다음 문제는 club.xxx.com/servlet/AAA와 blog.xxx.com/servlet/BBB를 어떻게 구분하게 할수 있을까하는 고민이 생겼다.. 그런데 이부분은 URI 설정을 통해 해결이 되었다.

uriCafe Uri = "/", Svrtype = JSV, vHostName = vhostCafe

uriBlog Uri = "/", Svrtype = JSV, vHostName = vhostBlog

이렇게 하면 cafe.xxx.com/servlet 으로 오는 요청은 vhostCafe에서 처리되어지고..

vhostBlog의 ServiceOder에 정의된되로 확장자 규칙에 맞지 않는 요청들은 제우스로 처리를 해준다는..

아파치에서는 쉽게 잘 썼었는데.. 제우스는 메뉴얼을 봐도 설명이 없고..

샘플 설정도 없고.. 하지만..결국은 너무나 쉽게 된다는 허무함을 느끼게 되었습니다..

tag : 제우스, 웹투비, 가상호스트

용산 노트북 가격 조사...

2008-11-12T16:29:10Z

근 5년만에 용산 전자상가에 가보게 되었다..

회사에서 노트북 구매건으로 사양이나 가격에 대해 검토하기 위해서 였다.

크게 변한건 없었는데 이제 데스크탑 매장은 별로 안보인다는거..

노트북, 넷북이 대세인듯..

예전에 데스크탑은 내가 원하는 사양에 맞추기가 상당히 편했던거 같은데..물론 조립pc가 아닌건...별로 사용해보지 않았지만.. 노트북은 원하는 사양의 모델이 별로 없거나..고가인 경우가 대부분이라니..

환율로 인한 노트북 가격의 상승 효과를 바로 확인해볼수 있었다.

담당자가 환율때문에 더이상 할인이 불가능하다느니..마진이 1%라느니..역쉬 바뀐건 별로 없었다..

이왕이면 15인치에..SWXGA인가..1680*..가 지원되는 와이드로 구매하려고 알아보니..

단순히 1280에서 1680으로 모니터만 사양을 변경할 방법이 없다고 하네요..

1680이 지원되는건 최소 180~200이상이고 1280은 110에서 시작한다고 하네요..

물론 해상도만 높아지는건 아니고 CPU나 HardDisk나 기타 전체적인 사양이 고상양이라 비쌀수 밖에 없다는데..

노트북 시장이 일반화 되어 사용자에 의해 원하는 스펙이 가능하게 구입이 가능한줄 알았는데..아직도 노트북 시장은 대기업과 대리점에 고객이 끌려다닐수 밖에 없는가 봅니다.

다리도 아프고 짜증이 나서 처음 봤던곳에서 하기로 걍 결정을 하려고 합니다.

정말 이젠 용산 오기 싫어지네요..

tag : 노트북, 용산