사용자 삽입 이미지

 

2004년 컴퓨터 월드 기고 현 BEA 류윤상 팀장의 글

 
엔터프라이즈 포탈이란 무엇인가

개념 생성에서 현재까지 발전과정, 최신 EP 트렌드 분석


/재/목/차

1회 : 엔터프라이즈 포탈의 개념(이번호)

2회 : EP의 컴포넌트 및 연관 솔루션(5월호)

3회 : EP의 Critical Success Factors(6월호)

4회 : 글로벌 사례 및 경험 소개(7월호)

 

 류윤상 한국Plumtree수석 컨설턴트


강좌 │ 엔터프라이즈 포탈(1회)

 

EP의 정의

 

EP라는 개념을 처음 듣는 독자들을 위해 간단히 정의를 내린다면 다음이 가장 일반적일 것으로 생각한다.

 

 “개인과 조직이 여러 시스템으로 관리해온 정보를 통합해 하나의 웹 화면에서 제공하는 기업용 포탈. 인터넷 포탈 사이트를 통하여 기업 활동에 필요한 모든 자원을 통합하여 관리·분석하고 제공할 수 있는 시스템이다. 기업의 내적, 외적 자원은 물론 사용자간의 협업체계, 커뮤니케이션 및 제반 온라인을 통한 거래 등이 한꺼번에 제공된다.”(두산 세계대백과사전에서 발췌)

 

위의 정의를 다시 세분화하여 설명하면 다음의 주요 특징을 갖는시스템이 EP라고 할 수 있을 것이다.

 

- 개인과 조직이 여러 시스템으로 관리해온 정보를 통합/기업 활동에 필요한 모든 자원을 통합(EP에는 이 정의처럼 기업 활동에 필요한 정보가 통합된다. 물론 이러한 정보에는 기업이 애플리케이션 형태로 보유하고 있는 비즈니스 로직 뿐만 아니라 비정형적인 문서나 컨텐츠도 포함된다.)

 

- 기업 내적, 외적 자원은 물론 사용자간의 협업체계, 커뮤니케이션 등을 제공(사용자가 함께 일을 할 수 있는 공간을 제공하여 포탈이 정보 제공 뿐만 아니라 업무를 수행할 수 있는 공간이 될수 있도록 한다.)

 

- 위의 통합된 자원들을 웹 화면 (UI)를 통하여 제공 : 웹 브라우저나 다른 휴대용 디바이스를 이용하여 기업 애플리케이션 및 컨텐츠에 언제 어디서나 접속할 수 있게 한다.

 

EP라는 것이 처음부터 이러한 모든 기능을 제공했던 것은 아니며 그 발전과정을 살펴보면 왜 이러한 개념이 생기게 되었고 또 왜 이러한 모습으로 발전되게 되었는지 이해하기가 쉬워진다.

 

 

사용자 삽입 이미지


EP의 발전 과정

 

필자가 EP에 관련된 업무 및 프로젝트를 수행해온 4년이라는 시간이 경과되는 동안 EP라는 개념도 많이 변모해왔고 그에 따라 도입에 따른 효과 및 관련 솔루션의 기능도 많은 변화를 거듭했다. 물론 모든 이야기는 최신 트렌드 및 기술에 맞춰지는 것이 당연하겠지만 현재의 모습을 좀 더 깊이 이해하기 위해 왜 이러한 개념이 생기게 되었는지, 또 그 태동으로부터 현재까지 어떠한 과정을 거쳐 발전하여 왔는지에 대한 검토를 먼저 하고자 한다. 앞으로 이러한 개념이 어떤 방향으로 발전해 나갈 것이며 이것이 국내기업의 IT환경에 어떠한 의미를 부여할 수 있을 지 살펴보자.

 

 

미국 시장조사 및 컨설팅 회사인 가트너(Gartner)는 엔터프라이즈 포탈이 0세대로부터 현재 4세대까지의 변천을 거쳐 왔다고 분석하고 있다.

 

1998년 이전, 즉 가트너가 이야기하는 0세대 포탈은 1990년대말, 인터넷 포탈 서비스를 주도했던 야후!의 개념을 기업내부에 적용하여 기업내부 자원들에 대한 링크를 모아놓은 개념으로 시작했다.

 

왜 이러한 개념을 기업에 적용하는 것이 필요했을까?

 

이는 1990년대 말의 기업 IT환경을 떠올려보면 쉽게 이해가 된다. 인터넷상에 수많은 웹사이트들이 생겨 이 웹사이트들로부터 자신이 원하는 정보를 쉽게 찾을 수 있는 방법을 제시한 것이 야후!와 같은 디렉토리 및 검색 포탈 서비스였다. 1990년대를 거치면서 기업 내부에도 IT를 통한 혁신의 바람이 불어 기업들은 앞 다투어 수많은 기간계 업무 시스템들을 도입하였고 이를 통한 기업경쟁력 강화를 꾀했다.

 

사용자 삽입 이미지
 

이 러한 이유로 수많은 전산 시스템들이 도입되자 기업내부에도 인터넷에서 그랬던 것처럼 임직원이 원하는 자료를 제대로 찾는 것이 힘들어졌고 이 문제를 완화하기위한 방편으로 여러 시스템에 대한 링크와 업무에 필요한 문서들에 대한 링크를 한곳에 모아 논리적으로 구분한 사이트 맵 성격의 포탈이 처음 등장했다. 물론 EP 라고 부르기에는 그 기능상 부족한 점이 많았던 시절이었으나 나만의 야후! 서비스를 원했던 적은 수의 선진기업들이 자체 개발을 통하여 구현한 사이트 맵을 기업의 내부에 구축하고자 했던 시도는 현재의 발전된 EP개념의 효시라고 할 수 있다.

 

사용자 삽입 이미지
 

1 세대의 포탈은 0세대에 주로 수작업으로 수행했던 컨텐츠 수집(Content Aggregation) 및 관리, 인덱싱/검색 등을 자동화 시켜주는 기능을 주로 제공했다고 볼 수 있다. 웹 로보트가 자동으로 기업에 산재한 문서 및 컨텐츠를 인덱싱 및 분류하고 이에 대한 검색 서비스를 제공한다. 이러한 과정은 모두 일련의 설정을 통해 자동화되어 수행되며 0세대 때와는 달리 관리자의 노력이 최소화되었다. 이러한 기능은 현재는 솔루션에 따라 포탈 솔루션에 아예 통합이 되어 하나의 제품으로 제공되거나 전문 검색엔진 솔루션을 OEM형태로 제공하는 두가지의 형태로 제공된다.

 

2 세대 포탈로부터 흔히 포탈하면 떠올리게 되는 포틀릿이라고 하는 웹 브라우저 내의 작은 창을 통해 뒷단의 타 애플리케이션을 통합하는 개념이 소개된다. 1세대 때의 문서나 웹 페이지 등의 단순 컨텐츠에서 이제는 비즈니스 로직을 포탈에 통합하는 기능을 제공하게 되고 현재 우리가 흔히 보는 여러 개의 작은 창이 모여진 포탈의 외관을 갖게 된 것도 이 때부터이다. 기업들이 흔히 EP 도입을 생각할 때 떠올리는 것이 이 정도의 그림이다. 즉 기업이 현재 가지고 있는 업무 애플리케이션 및 컨텐츠들을 포틀릿이나 링크의형태로 포탈에 통합하고 이를 개인화하여 사용자에게 제공함으로서 업무효율을 증대한다는 것이다.

 

3 세대 포탈로부터 새롭게 대두되었던 것들은 기존의 데이터나 로직에 대한 통합뿐 아니라 컨텐츠 매니지먼트(Content Management), 콜레보레이션(Collaboration), 프로세스 통합(Process Integration) 등의 기능을 포탈 단에서 제공함으로써 포탈을 혼자 일하는 공간에서 여럿이 함께 일하는 가상 워크스페이스로 발전시키게 된다.

 

현재의 포탈의 메이저 트랜드로 각광받고 있는 4세대 포탈에서는 이러한 모든 기능들을 재사용하여 그때그때 비즈니스의 요구에 따라 조합형 애플리케이션(Composite Application)을 손쉽고 빠르게 만들어내고 이를 비용효율적으로 관리할 수 있는 방법을 제공해준다.

 

이렇게 4세대까지의 발전을 거치면서 기업들이 0~3세대의 제품을 사용하여 EP 구축시 필요했지만 지원하지 않았던 기능들이 지속적으로 제품의 기본기능으로 확장되어 왔다. 그러나 솔루션 별로 그 기능 수준에 차이가 많아 4세대에 속하는 기능들을 충실히 지원하는 솔루션을 잘 선택해야만 예전에 많은 비용을 들여 개발해야 했던 많은 것들을 적은 비용으로 구현할 수 있어 프로젝트 수행 및 총 소유 비용을 최소화할 수 있다.


EP의 도입 목적

 

도입부에 소개된 EP의 정의에는 중요한 것이 하나 빠져있다. 바로‘왜?’라고 하는 시스템의 도입 목적이다. 다시 한번 EP 정의를 하나하나 살펴보기로 하자.

 

- 개인과 조직이 여러 시스템으로 관리해온 정보를 통합/기업활동에 필요한 모든 자원을 통합

 

- 기업 내적, 외적 자원은 물론 사용자간의 협업체계, 커뮤니케이션 등을 제공

 

- 위의 통합된 자원들을 웹 화면 (UI)를 통하여 제공

 

지금까지 업무에 필요한 애플리케이션이나 컨텐츠를 한 화면에 통합하는 방법이 없었을까? 협업이나 사용자들의 공동 작업 공간을 제공하는 솔루션들이 지금까지는 없었을까? 이러한 기능들을 웹 브라우저를 통해 제공하는 제품은 없었을까?

 

대답은‘아니다’이다.

 

위의 나열된 목적을 위한 솔루션은 EP 말고도 너무나도 많은 솔루션들이 있어 왔다. 예를 들어, 3부에서 자세히 다루어질 내용이지만 EAI 솔루션들을 생각해보자. EAI를 간단히 설명하면 기업 내외부의 산재한 애플리케이션, 데이터, 프로세스, 프로토콜을 통합하는 데 사용되는 시스템이다. 많은 EAI 솔루션들에는 웹으로의 인터페이스도 제공된다. 그렇다면 EAI와 EP는 같은 목적으로 사용되는 것인가?

 

두 번째로 국내기업들에 많이 일반화되어 있는 그룹웨어를 예로 들어보자. 그룹웨어 내에는 사용자들이 함께 일을 하기 위한 다양한 기능이 제공된다. 또 대부분의 경우 웹 인터페이스를 제공할 뿐만 아니라 포탈과 비슷하게 포틀릿이 여러 개 모여 있는 것과 유사한 UI를 제공하기도 한다. 그렇다면 그룹웨어와 EP는 같은 것인가?

 

대답은 물론‘아니다’이며, 그 이유는 EP를 기업에서 도입하는 주된 목적이 이들과는 완전히 다르기 때문이다.

(이러한 유관 솔루션들과 EP와의 비교는 2부에서 더 자세히 다루기로 한다.)

 


사용자 삽입 이미지

EP의 실제 도입 효과

 

일반적으로 EP를 도입함으로써 거둘 수 있는 효과로 개인화된 작업 공간(Workspace) 제공에 의한 업무효율성 증대를 거론한다.

하지만 EP를 효과적으로 구축하여 많은 ROI를 거두고 있는 세계 유수의 기업들의 사례를 검토해 보면 EP를 도입하여 거둔 가장 큰 성과는 미국의 IT 시장조사 및 컨설팅 회사인 가트너가 Composite Application이라는 이름으로 내놓은 보고서에서 잘 드러난다. 이 보고서에 따르면 EP의 도입 효과는 차세대 애플리케이션 제공 플랫폼으로의 활용을 통한 애플리케이션 구축비용 절감, 기업이 필요로 하는 애플리케이션을 보다 빠르고 신속하게 제공함으로써 비즈니스 기회비용 절감 등이다.

(이러한 사례들은 4부에서 더 자세히다루기로 한다.)

 

가트너가 기업 애플리케이션의 향후 방향으로 제시하고 있는 조합형 애플리케이션(Composite Application)은 포탈 단에서 협업, 컨텐츠 관리, 프로세스 통합, 검색, 보안 등 애플리케이션을 작성할때 꼭 필요한 기능들을 쉽게 재사용이 가능한 형태로 제공한다. 그리고 나머지 특정 비즈니스 목적을 위한 애플리케이션 로직이나

 

데이터만 기존의 IT환경에 맞춰 포탈에 통합하여 이러한 기능들이 조합된 애플리케이션을 작성함으로써 적은 비용으로 보다 신속하게 기업이 필요로 하는 다양한 애플리케이션의 제공을 추구하는 방법이다.

 

오른쪽< 그림>에서 보는 바와 같이 포탈 플랫폼에서 제공되는 검색, 보안, 협업, 컨텐츠 퍼블리싱 등의 기능을 간단한 설정을 통해 재사용하고 각 Composite Application 별로 필요한 기존 업무 데이터와 비즈니스 로직을 기업의 기존 IT 자원으로부터 웹 서비스와 같은 표준을 이용하여 통합하여 신속하고 비용 효율적으로 기업 업무에 필요한 애플리케이션을 다양하게 만들어내고 이를 손쉽게 관리할 수 있는 플랫폼이 EP의 진정한 정의이며 도입 목적인 것이다.

 

가트너는 지금까지 개발되어온 기업의 애플리케이션을 크게 두가지 형태로 분류하고 있다.

 

- 전술적 애플리케이션(Traditional Tactical Application) : 부서 정도 규모의 업무를 보조하기 위한 애리케이션으로서 1~6명의 프로젝트 팀이 1개월에서 6개월 정도의 기간을 거쳐 비교적 빠른 시간 내에 개발하여 그때그때의 긴급한 비즈니스 요구를 신속하게 해결하기 위한 애플리케이션

 

- 전략적 어플리케이션(Traditional Strategic Application) : 전사규모의 애플리케이션으로서 6~60명 이상의 프로젝트 팀이 6개월에서 6년 정도의 기간을 거쳐 완성해내는 애플리케이션. 지금까지의 많은 전사 대상 애플리케이션이 이에 해당된다.

 

기업은 비즈니스 환경의 변화에 따라 다양한 전술/전략적 애플리케이션을 짧은 기간의 개발 기간을 거쳐 신속하게 제공받아 사업의 기회비용을 최소화하고 싶은 필연적인 욕구를 가지고 있다.

하지만 지금까지 전통적인 방법의 애플리케이션 개발과정은 이러한 요구를 반영하기에는 현실적으로 불가능한 것이었다. 따라서 많은 경우, 현업들은 항상 자신들의 업무에 필요한 시스템의 부재를 호소하고 IT부서는 항상 바뀌는 현업들의 요구사항을 따라가는 것을 힘들어하며 많은 경우 이를 비현실적인 요구라며 묵살해 버린다.

 

이 때문에 부서나 부문의 자율적인 IT투자가 가능한 몇몇 산업에서는 각 부문이나 부서들이 자신들이 필요한 시스템 구축을 위해 각자 부문별 또는 부서별 IT투자를 하고 있는 것이 현실이며 이는 불필요한 시스템의 중복 투자 및 정보의 산재로 이어지고 있다.

 

Composite Application이란 이렇게 기업이 신속히 필요로 하는 전사(Strategic, 전략) 또는 부서(Tactical, 전술) 규모의 애플리케이션을 포탈이라는 단일한 전사적 플랫폼을 이용하여 1~6주 정도의 Tactical한 스피드로 작성/제공되는 것을 의미한다. 포탈의 주된 ROI는 기업이 느꼈던 느끼지 못했던 이를 통한 비용절감과 기회비용 감소에 기인하는 경우가 대부분이다.

 

미국의 에너지 공급, 에너지 관련기기 제작 및 건설회사인 Halliburton을 예로 들어보자.

 

이 회사는 5000군데가 넘는 그들의 원유 및 가스 산업고객들을 대상으로 myHalliburton.com이라는 Customer Support Composite Application을 제공하고 있다. 5000군데의 각 Halliburton의 고객사들이 이 애플리케이션에 접속하면 그들이 Halliburton과 거래함에 있어 필요로 하는 모든 서비스 및 데이터를 제공받을 수 있으며 이 안에서 자신을 담당하는 Halliburton의 담당자와 협업을 할 수 있다. 애플리케이션에 구현된 일부 기능들을 예로 들면, 각 고객들은 이 애플리케이션으로부터 새로운 제품의 정보를 얻을 수 있으며, SAP R/3로부터 자신의 고객 데이터를 조회할 수 있고, 지식 데이터 베이스 등을 검색할 수 있다.

 

Halliburton은 시시때때로 변하는 고객의 요구를 이러한 포탈 플랫폼을 이용하여 유연하고 비용 효율적으로 대처함으로써 myHalliburton.com 도입 첫해에 1억5천만 달러에 달하는 새로운 매출 증대를 달성한바 있다.

 

Halliburton은 아래의 과정을 거쳐 이 새로운 형태의 애플리케이션을 작성, 제공하였다.

 

- 지식데이터베이스의 검색은 포탈에서 재사용이 가능한 형태로 제공하는 검색기능을 활용하여 구현했으며,

 

- 새로운 제품에 대한 정보는 포탈에서 재사용이 가능한 형태로 제공하는 웹 컨텐츠 퍼블리싱 기능을 사용하여 구현하였으며,

 

- 고객들과 Halliburton 담당자와의 협업도 포탈에서 재사용이 가능한 형태로 제공되는 협업기능을 사용하였고,

 

- 기존 업무 데이터가 필요한 부분인 Invoice Tracking 기능만을 회사의 기존 시스템인 SAP R/3와 포탈을 통합하여 제공하였다.

 

사용자 삽입 이미지
 

이같은 Strategic 애플리케이션을 Tactical한 스피드로 만들어 내고 운영함으로써 Halliburton은 기존의 다른 어떤 시스템을 도입하더라도 불가능했던 것을 이루어낸 것이며 이러한 것이 EP를 도입함에 있어 기업이 추구해야 할 진정한 도입 효과라고 볼 수 있다.

 

왼쪽의 <표>는 전통적인 애플리케이션 구현 방법과 Composite Application과의 비교로서 포탈의 도입효과가 잘 정리돼 있다.

 

이번 회에서는 EP의 개념을 정리하고 그 도입 목적에 대하여 간단히 정리해 보았다. 다음 회부터는 EP도입을 검토하는 담당자들 이 흔히 겪는 다음 3가지 고민에 대하여 함께 해결책을 찾아보는 기회를 갖도록 하겠다.

 

- 너무나 다양한 포탈 솔루션 : 기업용 소프트웨어를 만드는 거의 모든 회사들은 전부 다 엔터프라이즈 포탈이라고 불리는 제품을 보유하고 있어 이들의 차이점을 잘 모르겠고 다 그게 그거 같아 나에게 맞는 솔루션이 어떤 것인지를 모르겠다.

(2부 - EP솔루션의 선택 편에서 알아보기로 하자.)

 

- 새로운 형식의 프로젝트 기획 : 솔루션을 선택한 후에도 EP 프로젝트를 해본 경험이 없어 그 기획을 어떻게 해야 할지 모르겠다. 어떤점을 조심해야 하는지, 보통 SI 프로젝트와는 어떤 점이 틀린지 등을 잘 알 수가 없어 그 기안 및 수행에 위험이 따른다.

(3부 - EP 프로젝트 기획 편에서 알아보기로 하자.)

 

- Cost Justification : 요즘 같은 불경기에는 눈에 보이는 효과나 ROI를 제시하지 못하면 경영층의 허락을 얻기가 어렵기 때문에 솔루션 벤더들이나 컨설팅 회사에 이러한 ROI 자료나 자사와 같은 산업 군의 해외사례 등의 자료를 요청해보지만 선뜻 이런 효과를 누릴 수 있다고 자신있게 대답해주는 업체도 없고 해외사례를 보더라도 자신의 기업의 현실에는 잘 맞지 않는 같다.

(4부 - 왜 지금 선진기업들은 EP를 도입하는가?에서 그 답을 찾아보기로 하자.)


EP 도입시 고려요소와 해결방안 제시

 

엔터프라이즈 포탈(Enterprise Portal, 이하 EP)은 요즘 웬만한 기업의 IT 기획/전

략 부서에서는 한번쯤 도입을 검토해 보았거나, 적어도 유관 솔루션 업체 영업

사원의 프리젠테이션 정도는 한번쯤 들어본 경험이 있을 정도로 기업들의 도입

최우선순위로 떠오르고 있는 새로운 업무 애플리케이션 플랫폼이다.

실제로 국내에서도 산업별 선두 기업들이 EP 도입을 검토해 왔으며 그들 중 상

당수가 2002, 2003년에 실제로 구현을 마치고 그 효과에 대한 체험을 주변에

설파하면서, 요즘 별로 뉴스거리가 없는 IT업계에 지대한 관심의 대상이 되고

있는 것이 사실이다.

필자는 2000년도 초부터 지금까지 다양한 국내외의 EP 프로젝트에 참여하면

서 경험한 것들을 바탕으로 국내 기업들이 EP 도입을 고려하면서 주로 민하

는 문제들에 대한 해결방안을 제시하고자 한다. 이 시리즈는 앞으로 4회에 걸쳐

구성될 예정이다.

포탈의 구성-2

1부 엔터프라이즈 포탈의 개념 - EP란 무엇인가?

(개념 생성에서 현재까지의 발전 과정 및 트렌드 분석)

EP라는 개념이 대두된 배경과 현재까지의 발전 과정을 요약하고 최근 들어 세

계 유수의 선두 기업들이 EP를 도입하고 있는 원인을 분석 및 해설. 야후!의 개

념을 기업 내부에 접목시켰던 초기의 방식에서 현재 기업의 업무 애플리케이션

을 생성·제공하는 기업의 애플리케이션 플랫폼이 되기까지의 발전 과정과 현

EP가 한국 기업의 IT환경에서 어떤 의미를 부여할 수 있는 지 설명한다.

2부 EP의 컴포넌트 및 연관 솔루션-EP 솔루션 선택, 우리 회사에 적합한

솔루션은?

포탈과 유관 소프트웨어 제품들인 Portal & SSO(Single Sign-On), Portal &

EAI(Enterprise Application Integration), Portal & KMS(Knowledge Management

System), Portal & Search, Portal & Content Management, Portal &

Collaboration, Portal & BPM(Business Process Management) 등 현재 시장에서

복잡하게 얽혀있는 솔루션들의 상호 관련성, 보완성 및 차이점을 설명하여 기

업이 자신의 비즈니스적 문제를 해결하려 할 때 솔루션 선택의 가이드라인을

제시 한다.

3부 EP의 Critical Success Factors-EP 프로젝트 기획, 이런 것들을 유의해

야 한다!

Governance Model 수립, ROI 측정 등 기업들이 포탈이라는 프레임웍을 기획/

도입함에 있어 간과할 수 있는 중요한 사항들을 경험에 입각하여 설명함으로써

현재 또는 앞으로 포탈 프로젝트를 추진할 계획을 가지고 있는 기업들이 사업

추진 시 고려해야 할 사항을 설명한다.

4부 글로벌 사례 및 경험 소개-왜 지금 선진기업들은 EP를 도입하는가?

Good-to-Have 정도의 의미로 받아들여졌던 EP를 최근 들어 갑자기 선진기업

들에서 도입하고 있는 이유와 그들이 EP를 도입함으로써 얻으려고 하는 기대

효과는 무엇인지를 분석하고 이를 사례중심으로 설명한다

2부 ,3부, 4부를 게속 올릴지는 고민중입니다. 혹시 필요하시면 연락 주세요.


Posted By Brainchaos

728x90
반응형

WRITTEN BY
bca (brainchaos)
언저리 - 블로그 = f UN + b LOG #BigData, #GrapDB, #Ani, #Game, #Movie, #Camping, 보드, 술먹고 떠들기, 멍때리기, 화장실에서 책읽기, 키스, 귀차니즘, 운동싫어, 버럭질 최고, 주경야독, May The Force be With You

,
WBS
WBS(작업분해도)는 일련의 액티비티를 계층으로 정리한 것이다. 계층을 하향식으로 내려가, 하나의 액티비티를 계속 보다 작은 액티비티로 쪼갠다. WBS는 4가지 구성요소를 갖고 있다:  프로젝트(또는 프로세스): 실행할 전체를 포함함  스테이지: 대략 2~4개월. 각 스테이지 끝에는 프로젝트를 재평가하는 평가가 있다.  스텝: 주요 프로덕트의 완료에 상응함  태스크: 보다 작은 프로덕트의 완료에 상응하며, 기간이 10일 혹은 그 미만이다.

Work Breakdown Structure(WBS)
프로젝트를 완료하기 위해 수행되어야 할 모든 작업 혹은 활동을 기술하는 기초 프로젝트 다이어그램/수직구조를 말한다. WBS에서 각 화위 수준은 프로젝트 목적에 대해 상세화된 정의를 점층적으로 보여준다. 이는 프로젝트를 의미있는 작업 패키지, 컴포넌트로 나누고, 또한 범위/비용/일정에 대한 의사소통, 책임, 모니터링, 관리의 할당에 대한 일반적인 프레임을 제공하는 구성요소로 나눈다.

4가지 구성요소
1) 프로젝트(또는 프로세스) : 실행할 전체를 포함한다.
2) 스테이지 : 대략 2~4개월. 각 스테이지 끝에는 프로젝트를 재평가하는 평가가 있다.
3) 스텝 : 주요 프로덕트의 완료에 상응한다.
4) 태스크 : 보다 작은 프로덕트의 완료에 상응하며, 기간이 10일 혹은 그 미만이다.


By LGCNS 용어사전
728x90
반응형

WRITTEN BY
bca (brainchaos)
언저리 - 블로그 = f UN + b LOG #BigData, #GrapDB, #Ani, #Game, #Movie, #Camping, 보드, 술먹고 떠들기, 멍때리기, 화장실에서 책읽기, 키스, 귀차니즘, 운동싫어, 버럭질 최고, 주경야독, May The Force be With You

,

프로젝트 생존 관련 테스트입니다.

우리도 이와 비슷한 방법으로 사전에 또는 프로젝트 진행 중에 테스트를 해보는 것이 도움이 되리라 생각 하여 장문의 테스트를 올립니다.

프로젝트를 결정하기전에 확인해보는 것도 좋은 방안이라고 생각합니다.

과연 이프로젝트가 성공가능한것인가> 아닌가를... 'ㅡ'

소프트웨어 프로젝트 생존 테스트


점수

@ 그렇다 3점

@ 대체로 그렇다 2점

@ 그렇지 않다 1점


프로젝트 초반에 테스트시 프로젝트 수행 계획서(SOW) 및 WBS를 근거로 테스트하고,

진행중일 시는 실제 일어난 결과를 바탕으로 테스트 한다.


생존 테스트


요구사항 (Requirement)


1. 프로젝트에 대한 명확한 비전이나 임무(Mission)이 있는가?

2. 팀구성원 모두가 제시된 비전을 현실적이라고 생각하는가?

3. 고객쪽 입장에서 얻게되는비즈니스적 이점과 그 이점에 대한 측정방법이 상세하게 제시되어 있는 사업계획서 (Business case)가 있는가?

4. 실제 시스템이 갖는 기능을 실질적으로 명확하게 보여줄 사용자 인터페이스 프로토타입(user interface prototype)이 있는가?

5. 소프트웨어 명세(specification)는 상세하게 문서화 되어 있는가?

6. 팀원들은 소프트웨어의 실제 사용자 (End user)와 프로젝트 초기에 면담을 했는가? 또 이들은 프로젝트 전반에 걸쳐 지속적으로 참여하는가?


계획 (Planning)


7. 소프트웨어 개발 계획이 상세하게 문서화 되어 있는가?

8. 작업(task) 목록에 설치용 프로그램 개발, 이전 버전에서 신버전으로 데이터 변환(conversion), 제3자 소프트웨어와 통합, 고객과 회의, 기타 사소한 일까지 모두 포함되어 있는가?

9. 일정과 예산 추정치를 가장 최근에 완료한 단게에 공식적으로 업데이트(Update) 했는가?

10. 프로젝트의 아키텍쳐와 설계를 상세하게 문서로 만들었는가?

11. 시스템 테스트는 물론이며, 설계 및 리뷰(review)까지 요구하는 상세한 품질보증게획(QAP:Quality Assurance Paln)이 문서화 되어 있는가?

12. 각 단계(Stage)별로 어떤소프트웨어가 구현되고 납품될지 상세히 설명한 단계별 납품 계획이 있는가?

13. 프로젝트 계획에 휴일, 휴가, 병가(sick days), 교육등의 기간을 포함시켰는가? 자원의 할당은 100%가 안되도록 하였는가?

14. 일정을 포함한 프로젝트 계획은 개발팀, 품질보증팀, 기술 문서화팀(technical writing team) 같이 관련된 모든 사람들의 승인을 얻었는가?


프로젝트 통제 (Project Control)


15. 의사결정 권한을 가진 임원 1명이 프로젝트를 책임지는가? 또 그임원은 프로젝트에 적극 지원하는가?

16. PM이 프로젝트에 열중할 여건이 조성되어 있는가?

17. 일의 완성 (100%)여부를 파악하기 위한 명확하고도 상세한 마일스톤(binary milestone)이 정의되어 있는가?

18. 프로젝트 이해관계자들(stakeholders)이 마일스톤 완성여부를 쉽게 파악할수 있는가?

19. 팀원들이 무기명으로 직속상상나 상급 관리자에게 문제점을 보고하고, 그결과를 피드백(feedback) 받을수 있게 되어 있는가?

20. 소프트웨어 명세서 변경을 통제하는 게획이 문서화 되어 있는가?

21. 변경 요청사항을 수용하거나 거부할수 있는 최종 권한을 가진 변경통제위원회(CCB: Change Control Board)가 있는가?

22. 작업량(efoort)과 예상일정, 업무 분장(task assignment), 계획대비 진도 등 프로젝트 현황을 팀원들이 알수 있는가?

23. 소스코드의 개정통제(revision control)는 자동화되어 있는가?

24. 오류 추적(defect tracking) 소프트웨어, 소스코드 통제(control), 프로젝트 관리 소프트웨어등 프로젝트 수행환경(Project environment)에 대한 기초적인 자동화 도구가 준비되어 있는가?


리스크 관리 (Risk Management)


25. 계획서에 리스크 목로기 명확하게 제시되어 있으며, 최신상태로 업데이트 되고 있는가?

26. 리스크 식별 책임이 있는 리스크 관리 책임자가 있는가?

27. 하도급이 필요한 경우 협력업체 고나리 계획과 담당자가 있는가? (협력업체가 없다면 만점을 준다.)


인력 (Personnel)


28. 프로젝트를 완료하는데 필요한 모든 기술력(technical expertise)을 보유하고 있는가?

29. 팀원들은 소프트웽어가 운영될 업무 환경에 대한 전문지싯을 보유하고 있는가?

30. 프로젝트를 성공적으로 이끌 기술 리더가 있는가?

31. 요구된 모든 과업을 수행할 인력이 충분한가?

32. 팀워크는 좋은가?

33. 팀원들이 프로젝트에 전념하고 있는가?


총점(Total)


----- 예비점수: 각 항목별 점수를 합산한다.

----- 규모 가중치(size multiplier) : 프로젝트 팀에 개발 책임자, 품질보증 담당자, 최종(first-level) 책임자를 포함한 전담인원이 3명 또는 그이하로 구성된경우에는 1.5를 4~6명의 전담자가 있는 경우에는 1.25를 그외경우에는 1.0을 준다.

----- 최종점수 : 예비점수 와 규모 가중치를 곱한다.



생존 테스트 점수

---------------------------------------------------------------------------
점수                              해석

---------------------------------------------------------------------------

90점이상(최우수)            이수준의 프로젝트는 프로젝트 일정, 에산, 품질목표등 모든 방면에서

                                    성공이 보장된 프로젝트다.

                                    이같은 프로젝틑 완전한 프로젝트 자아실현(Self-actualized)을 이룬것

                                    으로 볼수 있다.

---------------------------------------------------------------------------

80-89점 (우수)               이수준의 프로젝트는 평균보다 훨씬 좋게 수행되고 있음을 보여준다.

                                   이러한 프로젝트는 일정, 예산,
                                   품질 목표에 근접하게 소프트웨어를 납품할 확율이 매우 높다.

---------------------------------------------------------------------------

60-79점 (좋음)               이수준의 프로젝트는 평균보다 조금 나은 정도로 수행되고 있음을

                                   보여준다.

                                   이러한 경우 일정이나 예산을 충족시킬 확률이 어느정도 있으나 두가지

                                   를 모두 충족시키기는 어렵다.

---------------------------------------------------------------------------

40-59점 (적당)               일반적인 수준이다. 이 프로젝트는 상당한 수준의 스트레스와 불안한

                                   팀워크를 경험할 확률이 높으며,

                                   결국 비용 초과와 일정 지연으로 초기에 기대했던 것보다 품질이

                                   떨어지는 소프트웨어를 납품하게 될것이다.

                                   이런 프로젝트는 전반적인 계획을 수정하여 효과를 증대시켜야 한다.

---------------------------------------------------------------------------

40 미만 (위험)               이런 프로젝트는 요구사항, 계획, 프로젝트 통계, 리스크 관리, 인력등

                                  주요부분이 많이 취약하다.

                                   이런 범주의 프로젝트는 "프로젝트를 끝낼수있을까?가 최대 현안이다.

---------------------------------------------------------------------------


발취 - 스티브 맥코넬의 소프트웨어 프로젝트 생존 전략 (Software Project Survival Guide)

Powered By Brainchaos™

728x90
반응형

WRITTEN BY
bca (brainchaos)
언저리 - 블로그 = f UN + b LOG #BigData, #GrapDB, #Ani, #Game, #Movie, #Camping, 보드, 술먹고 떠들기, 멍때리기, 화장실에서 책읽기, 키스, 귀차니즘, 운동싫어, 버럭질 최고, 주경야독, May The Force be With You

,

현재 프로젝트 생존 전략을 다시 읽고 있습니다.


금번 대주보 프로젝트에서 생존하기 위해서 !!


마치 처음보는 책같다는 생각이 듭니다. (이전에 읽을때는 못느낀 많은 점이 다가 옵니다.)


먼저 생존권에 대한 권리 장전 입니다.


도움이 되셧으면 합니다.



고객 권리 장전

--------------------------------

나는 다음과 같은 권리가 있다.

--------------------------------

1. 프로젝트에 대한 목표을 세우고 이를 따르게 할 권리

2. 소프트웨어 프로젝트에 소요되는 기간과 비용을 알 권리

3. 소프트웨어가 가져야 할 기능을 결정할 권리

4. 프로젝트가 수행되는 동안 요구사항을 합리적으로 변경할 권리 와 이같은 변경작업에 드는 비용을 알 권리

5. 프로젝트 현황을 명확하고 확실하게 알 권리

6. 비용,일정,품질에 영향을 줄수 있는 리스크(RISK)를 정기적으로 평가하고, 이 같은 문제에 대처할수 있는 방안을 제공 받을 권리

7. 프로젝트 수행기간 동안 프로젝트 산출물을 열람(Access)할 권리

--------------------------------


프로젝트팀 권리 장전

--------------------------------

나는다음과 같은 권리가 있다.

--------------------------------

1. 프로젝트의 목표를 알고 우선순위를 명확히 할 권리

2. 어떤 제품을 만들어야 하는지 숙지한 후 제품의 정의를 명확히 할 권리

3. 소프트웨어 기능과 관련된 결정 권한을 가진 고객,관리자,마케터,기타 사람들을 자유롭게 만날 권리

4. 프로젝트의 각 단계(Phase)를 기술적으로 책임있게 수행하며, 특히 프로젝트 초기에 조기 코딩을 강요당하지 않을 권리

5. 할당된 작업령(effort)과 일정을 승락할 권리

   프로젝트 각 단계 (Stage)에서 이론적인 방식으로 비용과 일정을 추정할 수 있으며, 이같은 추정치를 내기 위한 시간을 충분히 가질 

   수 있다. 요구사항이 변경될때마다 추정치를 수정하고 검토할수 있다.

6. 프로젝트 현황을 고객과 상위 관리자에게 정확하게 보고할 권리

7. 생산적인 환경에서 일하기 위해 업무 (특히, 프로젝트의 아주 중요한 부분) 수행 시 잦은 간섭으로 산만해지지 않을 권리

--------------------------------


발취 - 스티브 맥코넬의 소프트웨어 프로젝트 생존 전략 (Software Project Survival Guide)

Posted By Brainchaos™
728x90
반응형

WRITTEN BY
bca (brainchaos)
언저리 - 블로그 = f UN + b LOG #BigData, #GrapDB, #Ani, #Game, #Movie, #Camping, 보드, 술먹고 떠들기, 멍때리기, 화장실에서 책읽기, 키스, 귀차니즘, 운동싫어, 버럭질 최고, 주경야독, May The Force be With You

,