AdminID.kr (어드민아이디) - 정보화 전략(IS) : MIS/ISP/BSP/CSF/EA

프로세스 BRR, PI, BPM, PS 등 개념부터 명확히

JAESOO — Tue, 24 May 2016 17:03:00 +0000

기업의 모든 활동은 프로세스가 아닌 것이 없다.
결과를 만들어 내는 과정, 즉 프로세스의 중요성은 더할 나위 없이 강조되고 있다. 프로세스가 강조되는 만큼 프로세스의 관리나 혁신에 관련한 개념이 혼용되거나 오용되고 있는 것이 현실이다.

산업계에서 혼재되고 있는 프로세스 관리와 관련한 용어는 개념적 차이가 있지만, 연계성을 가지고 있다. 원조격인 BPR(Business Process Reengineering)과 PI(Process Innovation), 가장 최근에 등장한 개념인 BPM(Business Process Management), 그리고 업무매뉴얼로 연상되는 프로세스 표준화 PS(Process Standardization) 등이 바로 그것이다.

• BPR

1990년 7월 마이클 해머가 하버드비즈니스리뷰에 발표한 ‘자동화하지 말라, 모든 것을 폐기하라(Reengineering Work : Don’t automate, Obliterate)’라는 논문에 처음 리엔지니어링(Reengineering)이라는 개념을 소개했다.

그는 ‘경쟁우위 확보를 위해 기업의 핵심부문에서 비용, 품질, 서비스, 스피드와 같은 요인의 획기적 향상을 이룰 수 있도록 프로세스를 근간으로 비즈니스 시스템을 근본적으로 재설계해 극적인 성과를 추구하는 것’이라고 BPR을 정의했다. 모든 것을 폐기하라는 선동적 주장처럼 BPR은 신기술이 도입될 때 백지상태에서 일하는 방식, 업무 지원 시스템, 수행 조직 등의 전면적 리엔지니어링을 주장한다.

이 개념은 1990년대 중반까지 많은 호응을 얻으며 기업의 물리적 구조조정 근거가 되기도 했지만, 현재는 호응도가 현저히 낮아졌다. 이에 대해 전문가들은 결국 업무를 추진하고 있는 사람(Human ware)이 리엔지니어링의 결과로 제시된 전면적 변화를 수용하는데 한계가 있음이 지적된다. BPR를 통한 새로운 업무 프로세스를 설계할 때 개선된 프로세스가 기존 프로세스 보다 확실히 나은 성과를 도출할 수 있다는 객관적 증거를 제시하기 힘들어 이에 대한 조직원의 반발, 그리고 급진적 변화(Big Bang)에 의해 새롭게 제시된 시스템과 업무절차에 대한 조직원의 부적응 등을 들 수 있다.

• PI

PI의 주창자인 토마스 데이븐포트는 마이클 해머와 거의 같은 시기인 1990년 프로세스 지향에 관한 논문과 1993년 저서인 ‘Process Innovation’에서 PI라는 용어를 사용하기 시작했다.

BPR와 PI는 급진적 변화를 주장한 만큼 개념간 큰 차이가 있지는 않다. 하지만 광의의 PI, 즉 문자 그대로 프로세스 혁신의 개념으로 이해한다면 BPR의 Zero based thinking 뿐만 아니라 기존 프로세스를 인정하고 그 위에 점진적 변화를 추구하는 일련의 프로세스 개선활동까지 포함하는 개념에서 차이가 있다고 할 수 있다.

국내 산업에 PI가 널리 퍼진 것은 2000년 초 포스코의 ‘ERP based PI’가 큰 반향을 일으키게 되면서부터이고, 철강뿐 아니라 조선, 전자, 금융 등 다양한 산업분야에서 ERP based PI가 추진됐다.

이로 인해 국내에서는 PI하면 ERP Based PI를 떠올리는 경향이 있다. 이는 ERP 패키지내 선진 프로세스를 그 기업의 추구하는 To-Be Process 인정하고 PI를 추진하는 하나의 방법론에 불과한 것이며, 그 기업에 대한 최적의 프로세스를 설계하고 이를 독자적인 전사업무관리시스템을 구축하는 방법을 택하는 기업들도 있다.
BPR이든 PI든 급진적 변화에 대한 위험성이 강조되면서 기존 업무 프로세스의 자산적 가치를 일정 부분 인정하는 분위기로 변화되는 되고 있는 추세다.

• BPM

BPM은 현재까지 그 개념 정의가 진행중이라 할 수 있다. 일반적으로 BPM은 ‘프로세스를 발견, 설계, 적용, 실행, 상호작용, 운영, 최적화 및 분석하는 종합적인 역량’을 의미한다.

하지만 BPM이 ERP의 비유연성을 극복하기 위해 주목받기 시작했기 때문에 ‘프로세스 자동화를 구현하는 BPMS라는 Application을 통해 기업의 프로세스를 관리하는 활동’이라는 지극히 IT적 관점에서 정의된다. 실질적으로 국내 기업들에게 전달되는 BPM은 IT관점에서 내린 후자의 정의에 더 가깝다.

개념상에서 BPM이 BPR이나 PI와 가장 큰 차이점은 이미 소유하고 있는 비즈니스 자산과 기술자산의 가치를 인식하고 이들의 활용을 추구하며 점진적 변화를 추구한다는 점이다.

ERP based BPR을 추진한 기업은 환경변화에 따라 민첩하게 프로세스를 변경하고 적용시킬 수 있는 시스템 지원도 부족했고 새로운 프로세스에 따른 새로운 Application의 추가 개발도 제한적이었다. 또 새로운 환경변화에 따른 전략의 변화와 프로세스의 변경·추가에 의한 성과지표 관리도 어려웠고 급격히 변화된 작업환경에 적응하기 위한 조직원들의 많은 반발과 저항도 극복해야 했다.

이같은 문제점들을 극복하기 위한 대안으로서 Workflow(프로세스에 따른 업무 처리), EAI(기업내 서로 다른 IT Application 통합을 통한 호환성 확보), BAM(Business Activity Monitoring, 프로세스 관련 성과지표관리) 등의 기능이 통합된 BPMS 구축을 통해 프로세스의 상시적 관리와 분석, 그리고 점진적 개선을 추구하게 된 것이다. 하지만 현재까지의 BPMS는 업무 성격에 따라 부문적용되고 있으며 시스템과의 연동과 프로세스 변경에 대한 유연성 측면에서 기술적 문제를 드러내고 있는 측면이 있다.

• 프로세스 표준화

기업의 최종 아웃풋인 상품·서비스의 문제는 산출물까지의 프로세스 문제로 인해 발생되는 하자가 90% 이상임을 주목하고 프로세스 관리(Process Management)의 중요성이 부각되기 시작했다. 이를 위해 기업이 프로세스 관리를 시작하고자 한다면 그 기업의 프로세스가 어떻게 생겼는지 알아야 하고(프로세스 가시화), 이의 관리를 용이하게 하기 위한 표준 버전이 필요하게 된다. 이것이 프로세스 표준화(PS)가 탄생한 배경이다.

프로세스 표준화는 ‘전사의 각 프로세스들에 대한 기준을 정하고 해당 프로세스들의 다양한 버전에 대해 어떤 것을 기준으로 삼을지 결정하는 것으로 각 사업부별 다른 프로세스들중 비슷한 프로세스들은 통합하고, 통합된 몇 개의 프로세스를 표준 프로세스로 지정해서 관리하는 것’이라고 정의할 수 있다.

BPR 및 PI와 중요한 개념 차이는 프로세스의 혁신을 위한 표준화가 아닌 프로세스의 관리를 위한 자산화라는 점이다. 표준화 이후 6시그마, Lean, Work-Out 등 일련의 사내 개선활동을 통해 점진적 개선을 추구하게 되며 이 개선결과를 표준프로세스에 반영해 장기적으로 기업에 가장 적합한 프로세스 체계를 구축해 나가는 것이다.

이 프로세스 표준화는 BPM의 점진적 개선의 철학과 함께 하며 실질적으로 BPM의 첫단계인 프로세스 가시화 및 자산화와 같은 개념이라 할 수 있다.

프로세스에 대한 이 4가지 개념은 서로 다른 것 같지만 다르지 않다.
기업의 전략적 판단 아래 급진적 변화를 도모할 수도 있고 점진적 변화를 도모할 수도 있기 때문이며, 또 급진적 변화를 택했다고 해도 이후에 지속적으로 점진적 개선을 포함한 프로세스의 상시 관리가 요구되기 때문이다.
이에 KMAC는 프로세스 성과관리, 프로세스 성숙도 진단 등의 프로그램을 통해 한국산업의 프로세스 혁신을 선도하고자 한다.

[문의]
KMAC 경영전략BU 경영전략3팀 황현철 팀장
☎ 02-3786-0660

형상관리에 들어 보셨나요?

JAESOO — Mon, 31 Aug 2015 10:07:59 +0000

1. 형상관리에 대해

오늘은 소프트웨어 개발에서 기본이 되는 형상관리에 대해서 알려 드리겠습니다. 형상관리(CM : configuration management)라고 들어보셨나요? 소프트웨어 공학을 배우신 분들에게는 익숙하겠지만, 그렇지 않으신 분들에게는 매우 생소한 단어라 생각 됩니다. 이미 배우신 분들은 형상관리가 범위도 다양하고 복잡하다는 걸 알고 있을 텐데, 오늘은 그 중에 개발자들에게 익숙한 소프트웨어 형상관리, 다른 말로 하면 소스 버전 관리에 대해 알아 보도록 하겠습니다.

소프트웨어 형상관리는 Software Configuration Management, 줄여서 SCM라는 단어를 쓰기도 하는데, SW개발 및 유지보수 과정에서 발생하는 소스코드, 문서, 인터페이스 등 각종 결과물에 대해 형상을 만들고, 이들 형상에 대한 변경을 체계적으로 관리, 제어하기 위한 활동입니다. 단순히 말하자면 프로젝트를 진행하면서 생성하는 소스코드를 CVS나 SVN, 또는 GIT와 같은 버전 관리 시스템을 이용하는 것을 말합니다.

다수의 개발자가 프로젝트에서 동일한 기능을 동시에 개발한다고 할 때, 작성된 소스 코드와 변경사항을 확인하고, 수정하는 협업을 도와주는 시스템이라고 할 수 있습니다.

참고로 공급망 관리를 지칭하는 Supply Chain Management(SCM)과 동일한 약어를 사용하니, 누가 SCM에 대해 물어본다면, 어떤 SCM을 말하는 것인지 확인을 하고 대답해 주세요. ^^

그럼 오늘은 소프트웨어 형상관리에서 버전 관리 시스템을 왜 사용해야 하는지, 어떤 개념들이 있는지, 그리고 어떠한 시스템들이 있는지 알아보도록 하겠습니다.

2. 왜 버전 관리 시스템이 필요한가?

프로그램을 만들다 보면, 잘못 만들어서 다시 소스코드를 이전 상태로 되돌릴 필요도 있고, 변경된 이력을 확인할 필요가 있습니다. 그리고 여러 명의 개발자들이 동시에 같은 소스코드를 개발하면서 발생하는 충돌에 대한 처리도 필요합니다. 이러한 것을 하기 위해 무엇이 필요할까요? 바로 버전 관리 시스템입니다.

과거와 달리 현재의 소프트웨어는 더 복잡해지고, 더 쉽게 변경됩니다. 만약 소프트웨어 버전관리 시스템을 사용하지 않는다면, 다른 개발자가 무엇을 했는지 알 길이 없으며, 실수를 쉽게 되돌릴 수도 없습니다.

버전 관리 시스템이 없던 과거에는, 다음과 같이 누구 책임인지 싸우느라 시간을 허비 했을지도 모릅니다.

버전 관리가 필요한 이유를 정리하면 다음과 같습니다.

개발 하는 동안 소스 코드의 변경 사항을 보존하기 위해

- 버그 및 문제점이 발생했을 때 추적에 유용
- 과거 특정 시점의 소스 파일 및 디렉토리의 내용을 손쉽게 확인 가능
- 과거 특정 시점의 소스 파일로 손쉽게 되돌릴 수 있음

협동 작업을 가능하게 하기 위해
- 대부분의 프로젝트는 팀 단위이기 때문에 전체 팀원이 하나의 소스를 가지고 효율적으로 작업할 수 있는 도구가 필요함
- 인터넷을 이용한 전세계 개발자들이 협업을 하여 개발하는 오픈 소스 프로젝트에 필수

3. 버전 관리 시스템의 기본 개념

문제 #1: 협업하기

두 명 이상의 사람들이 똑같은 소스코드를 같은 시간에 편집해야 한다면 어떻게 해야 할까요?

대안 1

누가 수정을 할지 순서를 정한다.

한 번에 한 사람만 작업을 할 수 있다.

규칙을 어떻게 지킬 수 있도록 할 수 있을까?

대안 2

작업을 각자 한 후 차이점을 찾아 수정한다.

차이점을 찾고 수정하기 위해 수많은 재 작업이 필요하다.

재 작업 시 소스코드가 손실 될 수 있다.

해결책

버전 관리 시스템은 개발자들이 동일한 소스 코드를 동시에 수정하거나 수정된 내용을 쉽게 공유할 수 있는 기능을 제공합니다.

중앙 저장소(Repository)에 메인 소스 코드를 저장해 놓습니다.
여러 명의 개발자들은 각자 로컬 PC에 중앙 저장소에 저장되어 있는 소스 코드를 작업 디렉토리(Working Copy)에 사본을 복사해 소스 코드를 수정합니다.
개발자들이 소스 코드 수정을 끝낸 후, 소스 코드를 공유하기 위해서 중앙 저장소로 소스코드를 커밋(Commit) 합니다.
다른 개발자는 변경된 내용을 확인 하기 위해서 중앙 저장소의 소스를 작업 디렉토리로 갱신(Update) 되도록 명령을 수행합니다.

문제 #2: 수정 사항 되돌리기

간혹 수정하던 소스 코드를 다음과 같은 이유로 이전 상태로 돌아갈 필요가 생깁니다.

개발을 시작한 후 시간이 지나, 잘못된 구현을 하고 있다는 것을 알게 되었을 때
이전 상태로 되돌리면서 모든 파일에 대한 변경 이력(History)를 유지하고 싶을 때
소스 코드가 언제, 무엇을, 그리고 누가 수정했는지 알고 싶을 때
->누군가 작성한 소스 코드를 이해하는 가장 좋은 방법은 작성한 사람에게 물어보는 것입니다.

해결책

버전 관리 시스템은 개발자들이 수정한 소스 코드에 대한 리비전(Revision)을 관리합니다. 리비전은 수정 시간, 수정한 사람, 수정한 내용들을 포함하고 있어, 개발자들에게 편리한 정보를 제공하고 있습니다.

또한 되돌리기(Roll back) 기능이 있어 특정 리비전 또는 특정 시간으로 소스코드를 되돌릴 수 있습니다.

위 두 가지 문제를 보면서 버전 관리 시스템의 기본적인 개념을 설명 드렸습니다. 그리고 위에서 나온 용어들을 정리하면 다음과 같습니다.

용어	설명
중앙 저장소(Repository)	원본 소스를 저장하고 있는 저장소를 의미합니다.
작업 디렉토리(Working Copy)	원본 저장소로부터 체크아웃을 통해 내려 받은 내 로컬 PC에 있는 작업 사본 디렉토리를 의미합니다.
커밋(Commit)	작업 디렉토리에서 변경, 추가 및 삭제된 파일을 원본 저장소인 서버에 적용하는 것을 말합니다.
갱신(Update)	체크아웃을 받은 작업 디렉토리를 원본 저장소의 가장 최신 커밋된 버전까지 업데이트하는 명령어입니다.
리비전(Revision)	소스 파일을 수정하여 커밋하게 되면 일정한 규칙에 의해 숫자가 증가합니다. 저장소에 저장된 각각의 파일 버전이라 할 수 있습니다.
되돌리기(Roll Back)	작업 디렉토리에 저장되어 있는 사본을 특정 리비전 또는 특정 시간으로 복원할 수 있도록 하는 명령어입니다.

위 용어들은 다양한 버전 관리 시스템에서 다양한 용어로 대체되어 사용됩니다. 예를 들면 작업 디렉토리(working Copy)는 작업 공간(Workspace)라는 단어로, 커밋(Commit)은 체크인(Check-In)이라는 단어가 사용되기도 하니 버전 관리 시스템을 사용하기 전에 어떤 단어가 위의 기능들과 매핑 되는지 확인해야 합니다.

4. 버전 관리 시스템의 종류

버전 관리 시스템은 상용과 비상용(오픈소스)로 구분 할 수 있습니다.

상용
- IBM Rational ClearCase
- Perforce
- PTC Integrity
비상용(오픈소스)
- Subversion(SVN)
- CVS
- Git

위에 나열한 시스템 외에도 수많은 버전 관리 시스템이 있습니다. 버전 관리라는 동일한 목표를 가지고 있지만, 각각의 시스템들은 특색을 가지고 있어, 그 특색에 따라 툴을 사용하는 방법들이 상이합니다. 그리고 상용 프로그램들은 가격이 정말 비쌉니다. 프로그램 라이선스가 1년에 1명 사용하는데 수백만원을 넘기니 말이죠. 그리고 최근 오픈 소스 프로젝트의 대부분은 Git를 사용하고 있습니다. 참고로 예전에는 SVN을 주로 사용했습니다. 여러분이 오픈 소스에 관심 있으시면 Git-Hub(http://git-hub.com/) 사이트를 둘러 보시면 도움이 될 것 입니다.

5. 글을 마치며

버전 관리 시스템은 아마추어 개발자와 전문 개발자를 구분하는 것 중에 하나라고 합니다. 프로젝트를 혼자서 하는 경우도 있고, 몇 명이 나누어서 진행하는 경우도 있습니다. 늘 일정에 쫓기다 보니 '바빠 죽겠는데 버전 관리까지 어떻게 해?'라고 생각하시는 분들도 있을 것입니다. 하지만 일주일 동안 온 힘을 다한 소스 코드를 실수로 날려 버린 경험을 가지신 분들은 버전 관리 및 소스 코드 백업의 필요성을 느끼실 것 입니다.

소스 코드 버전 관리는 정말 유용합니다. 처음 익숙해 질 때 어려움은 있지만, 시간이 조금 더 지나면 버전 관리에 대한 보상을 금방 얻으실 수 있습니다. 요즘 사람들이 많이 쓰는 Git로 버전 관리를 시작해 보시겠어요?

출처 : http://bsnippet.tistory.com/57

형상관리 표준 사례

JAESOO — Mon, 31 Aug 2015 10:05:26 +0000

프로젝트를 수행하다 보면, 프로세스의 표준가이드를 작성하는 것이 쉽지 않다는 것을 느낄 것이다.

그 이유는 프로젝트 특성인 유일성 때문에 주변의 다른 프로젝트와 다른 것이다. 따라서 상이한 것을 재활용하기가 쉽지 않고, 적당한 참고자료를 찾느라 많은 시간을 보내게 된다. 인터넷 덕분에 많은 자료를 찾을 수 있지만 상당수가 영어로 되어 있고, 외국 문화에 근접하여 기술되어 있어 한국적인 현실에 적응하는 것이 쉽지 않은 것이 또 단점이다.

그래서 수행하면서 만들어 두었던 표준 레퍼지토리들 중 형상관리 부문을 공개하여 여러분들과 공유하고자 한다.

수행한 프로젝트는 정부프로젝트로 비교적 사업규모(약 60억)가 큰 프로젝트였고, 신기술을 많이 도입하여 수행한 것이었다. 당시에 EDMS도 도입하였고, Clearcase를 이용한 형상관리를 시도한 점이 인상적이었다.

문서양식 자체가 형상관리의 표준적인 양식이 되기에 문서 전체를 첨부하기엔 부담이 있으니 아래 목차를 참고하시고, 필요하신 분들은 댓글을 이메일과 함께 남겨주시면 보내드리도록 하겠습니다.

해당 자료는 형상관리를 수행하려나 잘 감이 오지 않는 분이나, 구체적인 프로세스가 궁금하셨던 분들은 참고하여 주세요.

출처 : http://gmood.tistory.com/374

형상관리 정의, 도구의 필요성, 개념과 활용, 용어, 베이스라인 개념, 과정, 도입 고려사항, 도구

JAESOO — Mon, 31 Aug 2015 10:01:38 +0000

이야기를 시작하며...

오래전부터 관심이 있던 부분인데, 프로젝트의 작업환경과 관리자의 마인드가 여건이 되지 않아 이부분만 현장에 적용한 것들이 많다. 형상관리를 좀더 잘 활용하면 기존 생성부분을 재활용함으로써 소프트웨어 개발단가를 낮출 수 있음에도 불구하고 기술적/비용적인 문제로 시도가 되지 않고 있는 것이 현실이다. 아직도 많은 프로젝트가 재활용없이 신규로 작성되는 부분이 많다. 비교적, 웹시스템 구축은 재활용이 많으나 이 경우도 관리가 제대로 되지 않아서 중복관리되는 경우가 많이 있다.

개인적으로 미국의 형상관리시스템을 프로젝트 관계로 10여년 전에 접했는데 당시로는 대단한 충격이었다. 재활용 차원이 아닌 모든 자료(문서포함)를 관리하며, 효율적으로 관리 소프트웨어를 운영하는 것을 보고 CMM을 형식적으로 운영하는 것이 아닌 활용하고 있다는 생각에 참 부럽다는 생각이 많았다.

아시다시피 CMM이나 SPICE에도 형상관리 항목은 있으나 매우 작은 부분이라 형식적으로만 수행하면 통과되는 것이기에 당시 많은 한국회사들이 CMM 심사통과 목적으로 형식적인 형상관리를 수행하였고, 형상관리의 정확한 개념을 이해하는 분드로 그리 많지 않았다. 기술적으로도 개발된 소스를 관리해 보았자 이를 시스템에 재활용되는 경우는 극히 저조했기에 재활용은 문서만을 대상으로 하는 경우가 많았다. 그러나, 기술의 발달로 오늘날 대부분의 소스는 Object로 재활용 가능하며, 문서 또한 호환되는 포맷을 ㅗ저장 관리되고 있다.

그러면 마인드는 어떨까?
이 글을 읽으시는 분들은 형상관리가 필요하다고 생각하는가? 귀찮은 추가 작업이니 프로젝트에서 제일 일이 적은 사람에게 할당하거나 마지막 단계에 한꺼번에 수행하자고 생각하지는 않는가? 즉, 프로젝트 관리의 마인드에서 형상관리가 품질보다도 우선순위에서 밀리는 것이 안타까운 현실이다. 애초부터 마인드가 문제지 기술이 문제가 아니었다.

그러나 마냥 여건이 성숙되기를 기다릴 수 없으니 마인드를 바꾸고 여건을 만들고자 이렇게 형상관리 이야기를 시작한다. 여러 회로 연재될 형상관리 시리즈를 통해 많은 분들이 지식을 쌓고, 특히 현업 PM들이 사안의 중요성을 인식하는 계기가 되기를 바란다.

시스템공학자들은 '구성관리'라고도 하고, 소프트웨어 공학자들은 '형상관리'라고 하는데, 호칭은 형상관리가 대중화되어 있다. 영어로는 'Configuration Management'이다.

1. 형상관리란

가. 형상이란

S/W를 개발하는데 있어 하나의 파일만 가지고 모든 실행 모듈이 생성되는 경우는 없다. C언어로 개발되는 경우만 보더라도 그와 관련되는 헤더파일, 라이브러리 파일, 각종 문서들이 있기 마련이다. 이 중에서 우리가 원하는 어떠한 기능을 추가하게 되면 거기에 맞춰서 소프트웨어는 변화를 하게 된다.

예를 들어, A라는 기능을 하게 되는 각 소스들의 버전과 B라는 기능을 하게 되는 소스들의 버전을 달라지게 마련인데, 이때 각 기능을 하기 위한 소스 버전들의 집합을 '형상'이라는 말로 표현하면 이해가 쉬울 것이다. 즉, A라는 기능을 수행하기 위한 각 소스들의 버전의 형태를 '형상'이라고 표현한다.

나. 형상관리 활동의 4가지

시스템을 구성하는 각 부품들, 즉 형상관리의 대상으로 삼을 수 있는 것들을 통칭하여 '형상 항목(Configuration Item)'이라 지칭한다. 이들의 기능적/물리적 특성을 파악함으로써 각 형상 항목을 인식하고 구조화하게 되는데, 이를 '형상식별'이라고 한다.
각 형상 항목들은 시간에 따라 진화를 하게 되는데 이를 제어하고 기록하는 것이 필요하다. 이를 '형상제어'라 한다.
현재의 형상상태 및 형상관리의 진행상태 즉, 현재 각 형상 항목들의 관계나 구현 상태 및 변화 절차를 보고하는 활동이 필요하다. 이를 '형상보고'라 한다.
마지막으로 이러한 변경들이 미리 정해진 요구사항과 일치하는가를 점검해야 하는데, 이를 '형상감사'라 한다.

2. 형상관리 도구의 필요성 (형상관리 도구의 기능)

가. 자원의 중앙 집중적 통합관리

형상관리를 하게 되면 가장 먼저 하는 일이 대상 자원들을 구분하고 구조화하는 작업을 하게 된다. 그리고 나서 대상 자원들을 특정한 저장소에 모아두게 된다. 이렇게 하여 자원의 분산 및 중복 보관을 막게 된다.

나. 자원들의 효율적인 버전 및 이력관리

형상관리의 시작이 버전 및 이력관리에서 출발했듯이 가장 기본적인 것이라 할 수 있다. 자원들이 변화가 일어날 때만다 변화에 관련되는 정보, 즉 누가, 언제, 왜, 어떻게 등의 정보를 관리하는 기능이다. 많이 보급되고 있는 문서관리/이력관리 툴들이 형상관리의 일부인 것이다.

다. 작업 공간의 효율적 사용

형상관리 도구들은 고유한 형태의 자원저장소(Repository)를 보유하고 있으며, 사용자 별 또는 작업그룹 별로 리포지토리를 접근하거나 볼 수 있는 권한을 제어할 수 있도록 해 준다. 최근에 떠들썩한 고가의 설계도 유출사건도 이러한 도구를 사용한다면 방지할 수 있는데 안타까운 일이다.

라. 작업의 진행상태 파악 및 효율적 분배

대부분의 형상관리 도구들이 트래킹 기능을 가지고 있어 각 작업 단위 별 작업의 진행상태 및 경과정도 등을 파악할 수 있다. 뿐만 아니라 개발자, 개인 별로 작업의 상태 등을 파악할 수 있어서 관리자들은 작업을 분배하기가 쉬워진다.

마. 다양한 리포트

개발 및 유지보수 동안에 발생하는 다양한 정보들을 기록하고 관리하여 다양한 리포트 형태로 제공한다.

바. 작업 프로세스 지원

형상관리 도구를 통해 각 작업 단계 별로 필요한 작업들을 미리 정의하고, 거기에 준하여 작업할 수 있도록 지원한다는 의미이다.

사. 효율적이고 정형화된 의사소통 수단 제공

현재 나와 있는 형상관리 도구들은 자체적으로 정형화된 형태의 다양한 변경 요청서를 제공한다. 이를 이용하여 사용자들은 자신의 변경 사유를 기술하게 되고, 이것이 형상관리 도구 내에서 각 개인 사용자들에게 할당되게 되는 것이다.

3. 형상관리의 개념과 활용

현재 대부분의 많은 조직들에서 형상관리를 하려고 하고 형상관리 도구의 도입을 적극 검토하고 있다. 하지만 이것은 단순한 필요성에서 기인한 것에 불구하다. 대부분의 조직들이 형상관리 도구를 도입함으로써 자신의 조직들은 완벽한 형상관리를 할 수 있을 것이라 생각을 하기 때문에 형상관리 도구 도입에 실패하게 되는 것이다. 즉, 형상관리를 하기 위해서는 사전에 더 많은 준비를 필요로 하는 것이다.

가. 자유로운 개발을 하는 조직

이와 관련해 개발자들이 중심이 되어 작업을 하는 조직의 형상관리 도구 적용 사례를 살펴본다. 기본적으로 모든 형상관리 환경은 개발자들을 중심으로 구성되기는 하지만 형상관리의 절차를 간과해서는 안된다. 즉, 기본적으로 형상관리를 하는데 있어서의 절차를 무시할 수 없다는 것이다.

개발자 중심의 이 조직은 H/W를 제어하는 S/W를 만드는 조직으로 모든 작업을 개발자들이 담당 업무 별로 하도록 되어 있으며, 조직원들은 각자 업무에 맞는 프로그램을 개발하고 관리하는 일을 자신이 알아서 하도록 규정하고 있다.

이 조직은 한 마디로 모든 개발을 개발자들이 알아서 하는 조직이었다. Unix 환경에서 모든 사용자들이 개발을 하게 되는데 C를 사용하여 개발을 하게 된다. 물론 개발자들은 자신의 워크스테이션을 사용해 서버에 접속하여 개발을 하게 된다. 하지만 이 조직은 S/W를 개발하는 조직이 아니라 H/W에 들어가는 S/W를 개발하는 조직이다. 모든 개발자들은 자신이 담당하는 분야가 따로 있고, S/W를 개발하고 나서는 개발된 S/W는 자신이 담당하는 테스트용 H/W에 옮겨서 테스트를 하게 된다. 이 과정에서 문제가 발생하지 않으면 바로 실제 H/W로 만들어 내게 되는 것이다. 이렇게 작업을 하다 보니 모든 작업자들이 알아서 작업을 하게 되는 것이다.

다만, 개발에 들어가기 전에 변경요청서를 작성하고, 개발과 테스트 과정이 끝난 후 실제 H/W에 적용하기 전에 변경완료보고서를 작성하여 제출을 하도록 규정을 하고 있기는 하지만 실제로 전혀 지켜지고 있지는 않았다. 구두상으로 개발자들이 개발팀장에게 보고하는 형태를 취할 뿐이었다.

나. 적용 전 문제점

가장 큰 문제는 작업의 통제가 안된다는 것이다. 각자가 알아서 개발하고 자신만의 고유한 영역을 확보하고 있고, 모든 관리 역시 개인이 알아서 하는 형태를 취하다 보니 관리가 제대로 되지 않았다. 자신이 만들어 낸 프로그램을 H/W에 이식하여 실행 모듈로 만들어 다른 H/W와 운영에 들어갔을 때 문제가 발생하면 정확한 원인을 파악하는데 많은 시간이 소요가 됐다.

공통되는 모듈의 경우 개인 별로 자신의 작업 영역에 보유하고 있어서 변경이 발생했을 때 다른 사람이 소유하고 있는 것에 반영을 하기 위해서는 많은 시간이 소요가 될 뿐 아니라, 즉시 변경된 내용이 반영될 수 없다는 단점 또한 가지고 있다.

내부적으로 형상관리 절차를 규정하고는 있으나 전혀 지켜지지 않는 상태이고, 전체 개발과정과 관련하여 다른 외부 인증기관으로부터 인증 심사 준비를 하고 있는 상태여서 형상관리와 관련해서도 절차를 명확히 규정하고 조직원들이 이 절차를 정확히 따르는 것 또한 중대한 문제점이었다. 하지만 조직의 특성상 기존 형상관리 도입을 통해 업무 자체가 너무 많은 변화를 일으킨다면 일의 능률이 저하될 수 있으며, 조직원들의 심한 반발을 초래할 소지가 많아서 아주 신중한 적용이 요구되고 있었다.

다.적용 후 운용 환경

일단 가장 중요한 두 가지 작업은 형상관리 절차를 명확히 하는 일이었다. 다음으로는 여기 저기에 보관되고 있는 개발 소스를 한 곳으로 모으는 일이었다.

형상관리 절차는 기존에 사내 규정으로 있던 형상관리 절차를 그대로 이용하는 것을 원칙으로 하였다. 다만 개발자드리 불편을 느끼지 않도록 최소한의 절차로 줄이고 개발자들의 역할 또한 최소한으로 그리고 꼭 필요한 것으로 제한하여 형상관리 도구의 도입으로 인하여 많은 부분에 대해 준비하고 공부해야 하는 시간을 줄이는데 중점을 두었다. 형상관리 절차는 다음과 같다.

개발자들은 개발에 들어가기 전에 변경계획서를 작성하여 개발 팀장에게 승인을 요청하게 된다. 물론 이 과정에서 변경계획서 같은 경우 여러 가지 기본적인 내용 이외에 추가적인 그림 또는 다른 자료들이 있는 경우가 있으므로 파일을 다른 프로그램을 이용하여 만들고, 그 내용을 형상관리 도구로 불러 들여서 사용하도록 정의했다. 이렇게 하면 변경계획서가 개발팀장에게 전달이 되게 되고, 개발팀장이 이 내용을 검토 후 승인을 하게 되면 개발자들이 개발에 들어가게 되는 것이다. 개발자들은 형상관리 도구를 이용해 자신들이 필요한 소스들을 Check Out 하고 변경을 하게 된다.

변경이 끝나게 되면 테스트 과정을 거치게 되고 문제가 없다고 판단되면 변경된 소스를 형상관리 도구로 Check In하게 된다. Check In을 하는 과정에서 개발자들은 변경 완료보고를 작성하여 형상관리 도구에 붙여 넣게 된다. 변경 완료보고서를 작성 후 변경 완료 승인 요청을 개발팀장에게 하게 되고, 이렇게 되면 개발팀장은 전체 사항을 검토 후 승인을 하게 되면 그 내용이 형상관리 담당자에게 전달되게 된다. 형상관리 담당자는 이 단계에서 변경된 소스들을 이용하여 H/W를 만들 수 있도록 개발자들에게 허락해 주는 것이다.

다음 문제는 소스들을 한 곳으로 집중하는 일이었다. 많은 개발자들이 자신의 고유 영역에 개인적으로 소스들을 보관하고 있어 형상관리 도구를 이용하여 관리하기 위헤서는 한곳으로 소스를 모아 놓고 형상관리 도구를 통해서만 모든 소스들에 접근할 수 있도록 하는 일이 아주 중요한 일이었다. 그래서 하나의 서버를 형상관리 서버로 지정하고, 모든 소스들을 이 곳에 모아 리포지토리를 생성했다. 개발자들은 형상관리 클라이언트 모듈을 사용해 서버에 접속하여 작업을 하게 된다.

라. 적용 후 이점

이 조직에서의 형상관리 도입은 처음이나 다름없다. 즉, 미리 준비되어 있는 극본은 있으나 한 번도 무대에 올려지지 않은 연극과 같은 상태였다.

형상관리 적용으로 일단은 기존에 존재하던 형상관리 절차를 강제적으로 적용할 수 있게 된 것읻. 이 절차를 통하지 않고는 개발자들이 개발을 할 수 없도록 막아버림으로 형상관리 절차를 철저히 지키게 됐다. 이로 인해 외부 인증 심사를 아주 좋은 성적으로 통과할 수 있었다. 즉, 형상관리를 통해 기본적인 내부 절차가 정착화 됐다는 것이 가장 좋은 결과라 할 수 있다.

다음은 자원관리 부분이다. 여기 저기 흩어져 있던 자원을 한 곳에 모을 수 있는 기회를 만들었을 뿐 아니라 체계적으로 관리할 수 있는 기반을 마련한 것이다.

개발자들의 고유 작업 영역에는 전혀 변화가 없었다. 다만 개발자들은 변경을 하기 전에 변경을 원하는 파일들을 먼저 형상관리 서버에서 자신의 작업영역으로 Check Out 하는 것 이외에는 특별한 변화는 전혀 없었다. 기존의 작업 디렉토리 구조 및 영역을 유지할 수 있기 때문이다.

형상관리 담당자 입장에서는 전체 개발 주기를 제어할 수 있을 뿐 아니라 형상관리 도구에서 제공하는 다양한 로그를 통해 문제점 발생 시 추적할 수 있는 기반을 구축했다.

다양한 리포트를 통해 작업의 진행 상태를 출력할 수 있게 됐다. 뿐만 아니라 중요한 리포트의 경우는 HTML 문서 형식으로 만들어 기존에 운영하는 인트라넷을 통해 주기적으로 리포팅해 줌으로써 일일이 리포팅을 해야 하는 불편함을 최소화했고, 업무를 좀더 자동화 했다.

마. 도구 선택 시 중요한 원칙

형상관리 도구를 적용하는데 있어서 그리고 형상관리 도구를 선택하는데 있어서 몇 가지 중요한 원칙을 다시 한 번 짚어보도록 하겠다.

먼저 형상관리를 적용하기 위해서는 가장 먼저 환경을 만드는 것이다.

첫째, 형상관리 절차를 만들어야 한다. 여러 차례에 걸쳐 얘기했듯이 형상관리에는 절차도 중요한 요소이다. 단순히 형상관리 도구를 도입해 버전 및 이력관리만을 생각하고 있는 조직이라면 형상관리를 좀더 나중에 도입하라고 말하고 싰다. 비싼 대가를 지불해야만 형상관리 도구를 도입할 수 있는데 이러한 문제는 기본적으로 고려를 해야 할 뿐 아니라 꼭 필요한 요소이다.

또한 모든 표준화 기구 및 인증기관들에서도 단순히 형상관리가 아닌 버전관리만을 하는 것을 지양하고, 일정한 절차에 따라 형상관리를 할 것을 표준으로 제시하고 있다. 또한 단순한 버전관리만을 목적으로 형상관리 도구를 도입하는 경우 대부분의 경우 실패를 하기 마련이다. 이것은 대부분의 개발자들은 형상관리라는 것을 귀찮게 생각하기 마련이고 이렇기 때문에 절차를 만들어 절차에 따라 하지 않으면 개발을 할 수 없도록 만들어야만 개발자들이 형상관리에 적극 참여하도록 해야 한다. 그러므로 형상관리 절차를 만들고 거기에 준하여 작업할 수 있도록 하는 것이 아주 중요한 요소이다.

둘째, 형상관리 환경 구성을 어떻게 할 것인지 설정해 두어야 한다. 절차를 아무리 잘 만들었다 해도 복잡하고 까다롭다면 별 의미가 없다. 또한 형상관리 환경이 절차를 따르지 않고도 개발을 할 수 있는 환경이라면 의미가 없어진다. 그러므로 절차는 간단하고 단순하게 꼭 필요한 부분만을 수용해야 하며, 환경 자체도 절차를 따르지 않고는 변경관리를 할 수 없도록 정의되어 있어야 한다. 예를 들어, 개발 영역과 운영 영역이 동일하다 하면 개발자들은 얼마든지 운영 영역에서 직접 모든 작업을 하는 것을 막을 수는 없을 것이다. 그러므로 일단 운영 영역과 개발 영역을 분리해야 한다. 즉, 개발 영역에서 변경된 내용들이 형상관리 서버를 통하지 않고는 운영 영역에 전달될 수 없도록 해야 하며, 개발자들이 운영 영역에 접근할 수 없도록 해야 한다는 것이다.

셋째, 사용자들의 권한 및 조직원 구성을 어떻게 할지를 설정해야 한다. 사용자들은 어떠한 권한을 가지고 작업을 할 수 있는지 작업할 수 있는 내용과 작업할 수 있는 내용은 무엇인지 미리 정의해야 한다. 이렇게 함으로써 권한이 없는 사람이 실수로 작업해서 발생하는 문제점도 사전에 대비할 수 있으며 또한 각 사용자들 입장에서도 자신에게 불필요한 형상관리 도구의 기능까지 습득할 필요가 없어서 편리성을 갖게 되는 것이다.

바. 도구 선택 시 고려사항

첫째, 일단 우리 환경에 얼마나 적합한지를 살펴보아야 한다. 형상관리라는 것이 단순히 도구의 도입만으로 이뤄지지 않는다. 도구의 도입 시 현재 우리 호나경에 대해 많은 고민을 해야 한다. 그래서 현재 우리가 개발하고 있는 환경에서 최소한의 변화로 적용을 할 수 있어야 하며, 비용 등도 고려해야 할 것이다.

둘째, 많은 기능이 제공되는 툴 보다는 꼭 필요한 기능이 제공되는 도구를 선택해야 한다. 형상관리 도구의 적용에 있어서 많은 기능에 제공된다는 것은 의미가 없다. 집에서 TV를 한 번 생각해 보도록 하자. 많은 기능들이 있지만 채널과 볼륨이외에 얼마나 많은 기능들을 활용하고 있는지에 대해 형상관리 도구도 동일하다. 도구마다 수많은 기능들이 제공된다고 해도 실제 사용자들이 사용하게 되는 기능들은 5%도 되지 않는 경우가 허다하다. 비싼 비용을 들어 많은 기능을 제공하는 도구를 선택하기보다는 우리에게 꼭 필요한 기능을 제공하는 도구를 선택해야 한다. 형상관리 도구들은 대부분 대동 소이한 기능을 제공하고 있는 것이 사실이다. 사용자들 입장에서는 이러한 것을 구분해 내는 것이 그리 쉬운 일은 아닐 것이다. 우리가 꼭 필요로 하는 기능들에 대해 사전에 정리하고 가중치를 두어 도구를 검토할 때 평가 요소로 삼아야 할 것이다.

셋째, 기술 지원 능력 및 사후 관리에 대한 요소들도 점검해야 한다. 마지막으로 기술 지원 및 사후 관리에 대한 요소를 점검해야 한다. 일반적으로 형상관리를 도입 적용하기 위해서는 많은 시간을 필요로 하게 된다. 또한 경험이 전혀없는 조직의 경우는 더 많은 시간과 기술을 필요로 하게 된다. 이 과정에서 형상관리 도구를 지원하는 인력의 기술력과 경험은 아주 중요한 요소가 될 수 밖에 없다. 또한 얼마나 많이 많은 내용을 지원해 줄 것인가도 중요한 평가 요인인다. 현재 국내에는 형상관리와 관련해 많은 기술 지원 인력을 확보하고 있는 상태가 아니다. 따라서 기술 지원을 받기 위해서는 적지 않은 비용이 들게 된다. 형상관리 도구의 도입보다 더 큰 비용이 추가로 지불될 수 있으므로 도입 이후 형상관리 관련 기술 지원에 대한 비용 문제도 확실하게 계획을 세워야 한다.

4. 형상관리 용어

형상관리에서 많이 쓰이는 용어를 나열하였고, 기타사항을 파일로 첨부한다. 용어가 다수 기존의 방법론에서 설명한 것과 중복되는데 그것은 형상관리도 방법론을 지원하는 한 부분이기 때문이다.

가. 설계형상(As-Designed)

제품이 설계된 형상을 말한다. 이의 부품표를 '설계향상 As-Designed) BOM' 혹은 '설계(Engineering) BOM'이라고 한다. 이는 제품 형상의 기초가 되는 것으로 설계자나 고객의 입장에서 만들어진 것이며, 설계변경(Engineering Change)이 여기서부터 시작된다.

나. 생산형상(As-Planned)

설계된 제품을 생산하기 위해 계획한 형상을 말한다. 이의 부품표를 생산형상(As-Planned) BOM 혹은 제조(Manufacturing) BOM이라 하며, 생산 절차를 기술한 문서를 공정설계(Operation Planning)라 한다. 설계형상(As-Planned) BOM이 설계자의 입장에서 만들어진 것인데 비해 생산형상(As-Planned) BOM은 생산기술자에 의해 생산의 용이성이 감안되어 다시 만들어진 것이다. 따라서 생산형상 BOM은 설계형상 BOM과의 차이가 없음이 증명될 수 있어야 하며, 설계변경 사항이 적시에 반영되어야 한다. 특히 생산형상(As-Planned) BOM은 MRP의 가장 중요한 Input이므로 공정설계와 제품구조의 일치성이 보장되어야 한다.

다. 완성형상(As-Built)

완성된 형상을 말하는 것으로 최초 계획에서 설계변경 등 이력을 포함하여 생산 과정에서의 개선사항, 품질검사 결과 및 사후처리, 대체품을 포함한 실제 사용된 부품에 관한 제반사항 등의 광범위한 정보가 포함되어 있다. 이는 사양을 준수하여 제조하였다는 증명임과 동시에 고객에 인도되는 제품의 최종 형상으로 향후 운영 시 유지보수의 기반이 된다.

라. 운영형상(As-Maintained)

고객에 의해 운영되고 있는 형상을 말한다. 항공기, 선박, 첨단장비, 무기류 등은 제품 수명주기가 길거나 안전과 관련된 제품, 프로그램이나 첨단기술이 계속 보강되는 제품들은 현재 상태의 형상이 관리되어야 정확한 부품교환 및 수리가 가능하다. 그러므로 제품과 함께 운영형상(As-Maintained BOM)이 관리되어야 하며, 고객과 정비업체간 상호 운용성을 제공해야 한다.

마. Physical Configuration Audit

형상관리 활동의 하나로서 기능적 형상검토(FCA: Functional Configuration Audit) 이후에 개발 완료된 제품이 생산(또는 출하)에 필요한 요건을 갖추었는지를 검토해야 한다.

5. 형상관리 베이스라인(Baseline)의 개념

시스템의 생명주기의 일정 시점마다 그간의 제품상태(산출물)를 검토하고, 그 결과를 반영하여 다음 개발단계로 이전하는 방법을 사용한다. 이러한 시점이 곧 베이스라인(Baseline)이다.

즉, 베이스라인이란 생명주기 내에서 공학적, 관리적, 획득적 측면을 고려하여 정한 하나의 분기점 혹은 관리점과 그 때의 산출물을 의미하는 것으로써 개발 주기의 각 단계에서 산출되는 산출물에 대해 사용자의 요구조건을 만족시키는지 여부를 공식적인 검증과 확인을 거쳐, 한 단계를 동결하고 다음의 단계를 시작하는 기준점이 된다.

이러한 개발기점(Baseline)은 요구분석, 디자인, 코딩, 테스팅, 변경요청 등을 통제 관리하기 위해 설정하는 것으로 개발활동에 따른 시간의 순차에 의해 설정된다.

일반적으로 개발기점은 다음과 같이 5단계로 구분된다.

시스템 기능분류 기점 (FB: Functional Baseline)
- 시스템명세서(SS)의 검토 후 승인되는 시점에서 통제되는 라이브러리로 관리
소프트웨어 기능분류 기점 (AB: Allocated Baseline)
- 소프트웨어 요구분석(SRS)의 검토 후 승인되는 시점에서 통제되는 라이브러리로 관리
디자인 기점 (DB: Design Baseline)
- 기초(기본)설계 명세서 검토(PDR)와 상세설계 명세서의 검토(CDR) 검토 후 승인되는 시점에서 통제관리
최종 산출물 생성 기점 (PB: Product Baseline)
- 프로그램, 통합시험과 시스템 시험규격서/보고서가 검토 후 승인되는 시점에서 통제관리
운영개발 기점 (OB: Operational Baseline)
- 최종 산출물인 소프트웨어를 사용자에게 인도하기 위한 인증시험의 종료 후 승인되는 시점을 말하며, 운영의 시작시점인 동시에 유지보수를 위한 기준이 된다. 관리대상인 형상 항목에는 운영자 매뉴얼, 사용자 매뉴얼, 설치 매뉴얼, 목적/실행 코드 등이 있다.

미국방성의 MIL-STD-2167에서는 시스템에 대하여 3단계의 개발기점을 적용하고 있다.

기능분류 기점 (FB: Functional Baseline)
기능배분 기점 (AB: Allocated Baseline)
최종 산출물 생성 기점 (PB: Product Baseline)

이는 주로 제품(산출물) 중심의 단계적개발 접근방법(Phased Development Approach)으로

개념정립단계 (Concept Development Phase)
체계개발단계 (Development Phase)
운용 및 유지보수 단계 (Operation And Maintenance Phase)

로 베이스라인을 중심으로 형상관리 방법론을 적용하고 있다.

예를 들면, 기능배분 기점(AB)에서의 소프트웨어 요구사항 명세서(SRS)와 인터페이스 요구사항 명세서(IRS)를 바탕으로 실제적인 개발이 이루어지는데, 이 과정 중의 시스템 형상을 개발형상(Development Configuration)이라 한다.

이러한 개발 형상을 이루는 문서들을 개발기점(Baseline)의 검토 별로 나열해 보면, 아래 그림과 같다. 그림에서 보는 바와 같이 각 개발단계와 베이스라인은 밀접하게 연관되어 있어 베이스라인을 기준으로 개발단계의 진척을 평가하기도 한다.

예전 군사정보 사이트에서 참조한 자료입니다. 영어로 기술된 베이스라인의 상세 설명입니다. 참조바랍니다.

6. 형상관리 과정

가. 형상 식별

형상관리 대상 즉, 형상항목의 기능적/물리적 특성을 파악함으로써 형상항목을 식별하고 구조화
관리번호 부여
소프트웨어 형상의 구조 변경이 요구될 때 추적이 용이하도록 명확하게 정의
통제가 용이하도록 누가, 언제, 무엇을, 왜 정의하였는가 하는 정보를 생성
기준선 설정

아래와 같은 문서들이 베이스라인의 설정기준이 될 수 있다. 즉, 아래의 산출물들이 승인되는 시점들을 각각의 베이스라인으로 설정할 수 있다. 베이스라인의 특성에 따라 복수의 산출물들이 한 베이스라인에서 승인될 수 있다.

System Specification
Software Project Plan
Software Requirements Specification
Preliminary Use Manual
Design Specification (e.g. Datadesign description, Module design description)
Source Code Listings
Test Specification (e.g. Test plan and procedure, Test cases and recorded results)
Operation and Installation Manuals
Excutable Program
Database Description (e.g. Schema and file structure, Intial content)
As-built User Manual
Maintenance Documents (e.g. Software problem report, Maintenance requests)
Standards and Procedures for Software Engineening

나. 형상 통제

식별된 형상항목의 변경요구를 검토 및 승인하여 기준선에 변경사항을 반영되도록 통제
변경요청자 및 작업수행자가 참여하는 형상통제위원회의 구성
형상통제위원회는 기준선 및 변경을 승인하고, 소프트웨어의 형상에 영향을 주는 변경에 ㅐ하여 검토하고 승인
Access Control, Change Control, Version Control

변경요청 및 처리에 기술되는 문서에는 다음의 항목이 포함되어야 한다.

변경사항
변경식별번호
변경과 관련된 사항
변경의 범위와 미치는 영향
비용 및 일정에 미치는 영향
아래 도시된 문서화 된 변경절차가 존재해야 함

다. 형상 감사

기준선에 대한 변경이 미리 정해진 요구사항과 일치하는지 점검
기준선의 무결성을 평가하여 공식적으로 승인
소프트웨어에 대한 이해도가 높은 그룹(정보시스템 감사, 품질보증조직)에 의하여 수행
객관적인 확인 및 검증을 거침으로써 새로운 형상의 무결성을 확보
① 검증(Verification)
- 기준선의 형상항목이 전 단계 기준선으로부터 논리적으로 진화되었는가를 검토
- 사용자 관점에서 요구사항의 이행을 중점적으로 확인
- 소프트웨어 제품을 확인하기 위하여 수행
② 확인(Validation)
- 이전 단계에서 요구한 사항이 현 단계에서 진행했는가 확인
- 기준선 내 형상항목의 논리적인 진행과정을 검토

아래는 감사 시 수행하는 질문의 한 예이다.

형상감사위원회가 변경을 검토하였는가? 추가적인 변경사항이 수행되지 않았는가?
공식적인 기술검토회를 거쳐서 수정사항을 검토하였는가?
공학표준을 준수하여 수행하였는가?
변경대상, 날짜, 작성자 및 변경에 대한 상세한 내용이 기술되었는가?
정의된 프로세스에 따라 변경, 기록, 보고되었는가?
관련된 변경대상이 정확히 수행되었는가?

라. 형상기록

소프트웨어 형상 및 변경관리의 식별, 통제 및 감사의 결과를 기록
보고서 작성
- 이전 베이스라인의 승인시점
- 현 베이스라인의 시작시점
- 각 형상항목의 요약된 정보
- 변경문서의 상태(거부/승인/대기 등)
- 각 변경문서의 내용
- 변경대상의 상태
- 변경대상의 정보(버전 등)
- 베이스라인 변경에 대한 기술적/관리적인 상태 기록
- 형상감사 기록

7. 형상관리 도입 시 고려해야 할 사항

가. 경영진의 의지

A. 변화에 대한 개발자의 저항을 해소하기 위해서는 경영진의 의지가 확고해야 함

'형상관리를 도입한다'함은 기존 문서처리절차에 추가적인 처리단계가 생기며, 추가작업에 대한 기존 숙련자의 반발은 효과적인 홍보와 대안을 제시하여 저항을 최소화 해야 성공적으로 도입할 수 있다. 예를 들면, 형상관리절차에 따라 문서 등을 배포 전 처리하느데 소요되는 시간과 결정사항이 있는데, 시간이 급하니 생략하거나 시간을 할당하지 않고 기존대로 계획을 세운다면 이것은 작업자의 추가적인 희생만을 강요하게 되므로 형식적으로 수행하는 실패 사례가 된다.

기업조직에서 결정의 최종권한자인 경영진에서 이와 같은 변화를 고려해야 할 형상관리 도입이 성공적으로 정착할 수 있다.

B. 작업자들의 모든 내용을 기록하도록 하고 이를 감시하기 위해서는 경영진의 시간과 비용이 투입 요청됨

최근에 조선소의 설계본이 유출되거나 반도체 설계도가 유출되는 사건이 발생하였고, 기업체에서는 내부자의 보안관리를 철저히 하기 위해 EDMS르 도입한다느니 내부자 보안에 역점을 두는 추세이다. 보안사고는 대부분이 기업 내부자에 의해 발생하게 되며, 사고유형은 대부분이 정보유출과 방치 등이다.

다음 장에 형상관리도구에도 소개하겠지만 형상관리도 도구를 사용하면 효과적인 운영과 작업시간을 절약할 수 있다. 그러나, 이를 도입하게 되면 비용, 교육 및 적응시간에 따른 작업손실 등 시간과 비용이 요구된다. 더구나 일부가 아닌 일부가 아닌 전 부서, 전 프로세스에 적용한다면 경영진은 이에 따른 비용(전문관리부서 신설 등)을 고려해야 한다.

C. 가시성과 추적성의 결핍으로 인한 의사결정의 한계를 극복해야 함

형상관리는 도구를 사용한다고 하더라도 즉각적으로 효과를 측정하기 어렵다. 그 이유는 형상관리는 산출물을 생산하는 도구가 아닌 생산을 지원하는 도구이며, 주 입력물은 산출물과 그에 따른 이력정보이기 때문이다. 이력정보는 산출물이 갱신되면서 생성되므로 산출물이 갱신되어감에 따라 이력정보를 이용하여 추적이 가능하므로 이력정보는 도입 후 즉시 이용 가능한 정보가 아니다.

또한, 이력정보의 입력 시 출처 및 작성자, 날짜 등을 입력하게 되는데 최초 입력 시 충분한 정보를 입력할 수 없는 상태일 수 있다. 이에 대한 공감대를 형성해야 도입 및 활용이 조직에 정착하게 된다. 일례로 제가 수행한 프로젝트에서는 창고에 있는 물건이 언제 제조되었고, 상태가 어떤지도 관리되지 않는 것도 있었다. 물론 관련 문서도 없었으나 관련 담당자도 적절히 할당되어 있지 않았기에 이력이 손실된 것이다.

즉, 이력정보는 산출물의 생성/배포 후 추적과 재활용 시점에 빛을 발하는 것이다.

나. 관리조직의 확립

A. 형상관리를 효율적으로 수행하기 위해서는 품질보증조직과 같은 별도의 조직을 운영함이 바람직함

흔히, 형상관리는 품질조직이 같이 겸임해도 될 것으로 생각하게 된다. 그러나, 이것은 불가능한 궁합이다. 형상관리의 활동 중 형상감사는 형상관리자가 수행하는 활동이 아닌 품질관리 조직이 담당하고 체크하는 것이다. 즉, 품질보증조직이 형상관리를 감시하는 것이기에 같은 조직이 활동을 수행한다면 고양이에게 생선을 주는 형태가 된다.

또한 형상관리는 베이스라인에 따라 운영되며 산출물의 배포/변경을 담당하므로 테스트 및 프로세스의 적적한 수행을 점검하는 품질조직과는 업무성격도 다르다. 분리해서 운영함이 바람직하며, 형상관리 규모에 따라 별도 부서가 담당하는 것도 좋은 방안이다. 보통 프로젝트 레벨에서 별도의 관리자를 부여하기도 하지만 개발자들이 형상관리도구 교육을 잘 받는다면 형상관리는 PM이 할 수 있을 정도로 도구가 잘 되어 있다.

자료의 형태와 량에 따라 다르지만 중앙에서 형상자료를 관리하는 형태인 경우에는 형상 데이터의 정리와 추세를 감시하는 조직이 필요하나 조직 별로 분산하여 관리하는 형태인 경우에는 각 조직의 관리자가 수행하면 충분하다.

B. 사용자와 개발자가 공동으로 형상통제위원회를 구성

형상변경은 베이스라인과 밀접한 관계가 있다. 개발자는 베이스라인 범위 내에서 사전에 정의된 스팩 하에 별도의 의사결정없이 자유롭게 변경할 수 있으나 베이스라인을 초과하거나 스팩을 변경해야 하는 변경인 경우는 사용자와 반드시 합의하여 수행해야 한다. 이를 협의하는 기구를 형상통제위원회(CCB)라고 부르며, 프로젝트에서는 고객측/개발자측이 연합하여 구성하고 기업 내에서는 조직간 대표가 차출되어 구성된다. CCB는 상설조직이 아닌 임시회의기구 성격이므로 필요 시 소직하나 의사결정사항은 반드시 형상관리자가 기록해야 한다.

C. 소프트웨어의 버전 또는 기준선을 승인하고 이엥 대한 변경을 허가해 주는 공식적인 조직이 필수적임

이것은 CCB의 역할이다. 프로젝트의 PM이 임의의 산출물을 납품하고자 하는 것은 개발자의 의지이며, 이를 승인하는 것은 사용자의 의지이다. 따라서, 행위를 CCB에서 처리한다면 1:1에 의한 승인으로 인해 오류를 정정하는 Rework이 매우 줄어들게 된다. 또한, 복수에 의한 결정이므로 안정적인 의사결정을 수행하게 되어 프로젝트 리스크를 완화시키는 효과가 있다. 실제로 CCB는 위험을 완화시키는 역할도 한다.

다. 형상관리도구와 작업절차

A. 소프트웨어 형상항목의 특성 상 정보시스템으로 관리가 가능하므로 자동화 도구가 필요

과거에는 형상항목의 관리대상이 문서인 경우가 많아 단순 폴더 관리하는 툴들이 많았으나 기술이 발전하고 시스템이 복잡해짐에 따라, 관리대상은 일정한 형태가 아닌 Object로 바뀌고, 보안 및 프라이버시보호 등의 기능이 추가되었다.

또한, 다양한 플랫폼을 지원하므로 개발 중에 언제든지 편리하게 저장관리할 수 있어 백업의 효과를 볼 수 있다. 저장된 자료에 대한 효과적인 검색도 지원하여 타 프로젝트 또한 타 부서의 자료를 쉽게 재활용할 수 있는 등 비용절감 효과를 지원한다.

단순관리에서 개발도구와 연동하여 운영되는 도구까지 다양하므로 해당 기업 또는 프로젝트에 맞는 도구를 사용하기 바란다.

B. 도구의 활용에 앞서 소프트웨어 형상관리 작업절차가 확립되어야 함

형상관리 툴은 형상관리의 수단이지 핵심을 아니다. 도구 도입 전에 형상관리대상이 무엇인지 선정하고, 이에 적합한 프로세스를 정립한 후 이에 적합한 도구를 탐색하여 선정해야 되겠다. 대부분의 도구들이 표준프로세스들을 지원하지만 개발도구와 연동성이 약한 도구도 있기에 이 경우에는 개발자의 추가 기록작업이 수행되어야 한다. Visual SourceSafe는 개발도구인 Visual Studio와 연동되는 것이기에 수정 후에는 자동으로 기록되므로 작업자는 기존작업과 다를 바가 없게 되나, Microsoft에서 많이 사용하는 Source Depot의 경우는 별도의 Checkin & out 절차를 수행해야 하는 번거로움이 있다. 그러나 Source Depot의 경우는 세부적인 변경절차에 따른 기록이 가능하고 버그 관리도 수반하는 다양한 목적의 툴이다.

8. 형상관리 도구

가. 형상관리 도구의 특징

형상관리 도구는 복잡한 형상 항목의 인식과 형상관리활동을 지원하는 자동화 도구로서 다음과 같은 역할을 수행해야 한다.

A. 자원의 집중적 통합관리

형상관리의 모든 요소는 통합적인 관점에서 통제되어야 한다. 즉, 프로젝트의 사항이 회사 규칙에 반한다면 이를 자동으로 제제해야 하는 것이다. 보안 규정 등을 전사적으로 적용하는 것이 한 예가 될 수 있겠다.

B. 자원의 효율적인 버전 및 이려관리

모든 자료의 버전과 수정자, 사유 등 수정 이력은 저장되고 필요 시 추적 가능해야 한다. 이력이 추적되지 않는다면 부당한 수정이나 자료파손에 따른 손실을 감수해야 한다. 즉, 백업도 자동으로 되는 셈이다.

C. 작업 진행상태 파악 및 효율적인 작업 분배

각종 자료가 수정검토/승인을 거치고 수행하는지에 대한 상태정보 이력이 추적 가능해야 하며, 수정작업에 따른 서버의 부하가 적절히 분배되어야 한다. 경우에 따라서는 일부 자원이 수정이 집중될 수 있는데, 이에 따른 수정 오류를 방지하기 위해서는 수정상태의 제공 및 오류정정(Resolve) 등이 지원되어야 한다.

D. 다양한 보고서 작성

수록자료의 변경이력, 배포이력, 수정횟수, 버전, 차이분석 등 다양한 보고자료가 사용자에게 제공되어야 수정패턴 및 통제규칙 설정에 도움을 줄 수 있으며, 생성자료의 재활용을 위한 검색자료로도 활용된다.

E. 작업 프로세스 지원

형상 변경 시 변경요청/검토/승인 등 일련의 세부 프로세스를 도구가 지원한다면 작업자는 매우 편리함을 느낄 것이며, 프로세스의 수행 누락이 없는 생산성 향상에 기여하게 된다.

F. 효율적이고 정형화된 의사소통수단 제공

형상이 변경되거나 완료되거나 하였을 경우, 적절한 주변 Stakeholder에게 자동으로 통보하는 수단이 있다면 더욱 편리할 것이다. 또한, 부당한 사용에 대한 경고가 있다면 더욱 보안유지자에 도움이 되겠다. 이력기록에 일정한 양식을 지정하여 사용한다면 사용자간의 의사소통이 간결하게 될 것이다.

G. 통합개발환경과의 연동

형상관리의 핵심은 개발시스템을 지원하는 것이며, 재활용 및 버전관리를 통한 생산성향상에 기여하는 것이다. 이때, 개발툴과 밀접하게 연동된다면 수정사항이 이력과 함께 별도의 추가 작업없이 개발시스템에 반영되는 것과 동시에 형상 데이터에도 기록할 수 있다는 것을 의미하는 것이기에 매우 효과적일 것이다. MS의 SourceSafe가 그 예이다.

나. 형상관리도구의 선택

형상관리도구를 선택하는 것은 쉬운 부분이 아니다. 그 이유는 의외로 형상관리에 대한 사용자의 요구가 매우 구체적이기 때문이다. 형상관리에 대해 잘 모르는 사람이라도 평소에 이런 것이 되었으면 좋겠다던가 이것이 낭비다라고 생각하는 것이 있으며, 이것은 본인도 모르게 구체적인 형상관리 도구의 요구사항이 된다. 그만큼 형상관리 도구의 대상은 다양하고 방대한 것이다. 즉, 대형조선소의 설계도에서부터 소프트웨어 요구사항까지 모든 표현자료는 형상관리 대상이 되기에 컴퓨터를 모르는 분들이 생성한 자료도 모두 대상이 되는 것이다.

이러한 사용자의 생각이 잘 조사된 것이 1995년 'Improving Your Process for the Evaluation and Selection of Tools and Environments'라는 보고서에서 10가지 절감규칙으로 소개되었다. Westinghouse에서 선정한 10가지는 다음과 같다.

The Westinghouse common 'Cents' Rules

'Haste Makes Waste (성급은 금물)'

도구를 선정하는 시에는 무엇이 필요하고 요구사항은 무엇인지, 제약사항은 없는지 등을 꼼꼼히 따져 보고 해야 하며, 수많은 기능 중 어떤 기능에 중점을 두고 도구를 선정할 것인지 사전에 계획하는 것이 현명한 접근이다. 형상관리의 전 과정 및 데이터의 다양성 등이 이러한 고려요소가 될 수 있다.

다섯개의 도구가 각각 장점을 가지고 있다고 해서 다섯개의 도구를 모두 선택하지 않을 것이다. 예를 들어, F22개발 프로그램 개발 시 다양한 업체가 다양한 개발환경에서 다양한 프로그래밍언어로 개발되는 시스템을 관리해야 된다. 형상관리팀은 도구 선정 시 통합관리가 되는 것을 우선적으로 고려하였다.

'Practitioners Are Prime Evaluator (경험이 최고)'

형상관리 선정 이것은 경험한 사람이 하는 것이 최적이다. 그 이유는 다양한 툴의 다양한 기능들은 무경험자에게는 선택기준이 아닌 단순한 특징에 불과하기 때문이다.

'Evaluate Against User's Needs (사용자 요구사항에 근거한 평가)'

1989년에 Westinghouse는 SEI의 140개의 평가항목을 요약하여 25개 항목을 만들었으나, 1994년 54개로 늘어나다가 1995년에는 67개로 증가하였다. 이러한 항목의 증가는 형상관리 도구의 발전도 있었지만 사용자 요구사항이 변경되었고, 초보 평가자를 위해 상세한 평가항목을 추가한 것이 원인이기도 한다.

아래표는 형상관리 기능의 간략한 요약과 도구간의 비교표이다. 상세내역은 이후에 설명한다. 아래 형상도구는 이 보고서의 발표당시인 1996년 기준의 도표이다. 요즘 국내에 유행하는 PDM, EDMS 도구 등과 비교해 보시길 바란다. PDM/EDMS도 모두 형상관리 도구의 일종이다.

Taxonomy Five SCM Tools

'Don't Believe It Unless You See It (백문이 불여일견)'

앞서 표에서 제시된 다양한 기능에 많은 사람들이 현혹되기 쉬우나 이에 대한 냉철한 분석이 필요하다. 표에서 표현한 것은 전체 기능 중에 일부인 간단한 기능일 수 있다. 실제 프로젝트에서 사용가능한 시나리오를 생각하고 직접 이를 운용하는 테스트를 하면서 선정하는 것도 현명한 접근이다.

'Don't Buy It Until You've Tried It (사용해보고 구매하자)'

많은 사용자가 단지 자신들의 기준을 만족하였다고 하여 툴을 구매하는 것을 볼 수 있다. 그러나 상당수의 툴들이 기준을 다른 시각으로 해석하여 답을 다는 경우가 많으므로 구매를 최종적으로 결정하기 전에 직접 사용해 볼 것을 권한다. 툴 선정기준은 1차적으로 구매제품의 후보선정기준이며, 직접 테스트 후에는 결정기준이 되는 것이다. 후보를 무조건 최종결정하는 오류를 범하지 말길 바란다.

아래 표는 툴을 선정하는 기준을 수립하는데 도움이 될 기초 질문사항들이다. 예를 들면, 만약 툴이 요구사항을 추적하는 기능이 있어야 한다면, 툴은 반드시 변경관리기능(추적관리 및 추적보고서 기능)이 지원되어야 한다. (CM28이 이에 해당되는데, ADC와 ClearCase가 지원되지 않는군요)

'Pay Now or Pay Later (우왕좌왕하지 말자)'

위의 질문에 단순히 Yes/No로만 단정하지 않는다. 각 질문에 대해 중요도를 할당하고 Yes/No에 대해서도 점수를 할당하여 종합점수로 최종적인 평가를 수행한다. 이러한 평가시간은 오래 걸리지 않게 된다.

'Everything is Negotiable (모든 것을 고려하자)'

제품의 성능/기능에 대해 살펴보았다면, 제품의 구매방법에 대해서도 살펴보자. 일부 공급업체는 1 Copy는 팔지 않는 경우도 있고, 어떤 업체는 할인율을 구매처에 따라 다르게 적용하기도 한다. 모든 요소를 고려하여 구매해야 한다.

'Acquire Only What is Needed (필요분만 구매하라)'

업체의 판매전략과 연관되는 부분인데 업체의 할인공세에 호응하여 개발자 숫자대로 소프트웨어를 구매하였을 경우, "개발자가 동시에 모두 체크인을 하는 경우가 발생할 수 있겠는가?"를 생각해 보아야 한다. 1주일에 2번 일부 PC를 이용하여 체크인하는 경우 구매분량은 매우 적게 결정된다. 따라서, 작업방식의 결정만으르ㅗ 필요분량이 다르게 결정되는 것이다.

'Create a Champlion (툴을 숙지하자)'

툴을 잘 사용하는 사용자는 툴의 특성을 잘 파악하여 최대 효과를 거두기도 하지만 때로는 새로운 요구사항을 툴에 도입하도록 만듭니다. 예를 들면, F22 생산 시, PCMS가 흩어져 있는 사이트에 저장된 자료의 형상관리를 해야 하는 경우가 발생하였고, 이것은 PCMS의 다음 버전에서 지원하게 되었다.

'Be Constructive Not Destructive (개선점을 찾자)'

평가자는 툴이 사용중단될 때까지 지속적으로 툴을 평가하여 기능 중 무엇을 사용하고 있고 무엇을 하지 않고 있는지 파악한다. 이를 통해 문제가 무엇이고 어떻게 해결해야 하는지 알게 된다면 이를 제작자에게 피드백하여 전체적으로 툴의 성능향상에 기여할 수있다. 기존의 상용툴들은 이러한 과정을 거쳐서 개선된 경우가 많다. 제작사의 개선지원여부도 툴 선정의 주요요소가 될 수 있다.

10. 결론

모든 현실이 예측할 수 없게 바뀌듯이 고객의 요구사항은 끊임없이 바뀌고, 분석/설계자는 기술발전으로 시스템의 구조를 바꾸며, 개발자는 코드를 바꾸고 PM은 개발방법론을 변경하게 된다. 모든 변경에는 그에 따른 비용이 발생하며, 이것은 프로젝트의 중요요소가 된다. 따라서 소프트웨어의 변경관리는 프로젝트의 핵심활동 중의 하나이며, 이러한 활동을 지원하는 도구의 사용은 필연적인 것이 되어 가고 있다. 적절한 툴을 선정하여 프로젝트를 성공적으로 수행해야 하겠다.

출처 : http://gmood.tistory.com/tag/형상관리

형상관리란 무엇인가? 소프트웨어 형상관리(SCM)은 무엇인가?

JAESOO — Mon, 31 Aug 2015 09:49:32 +0000

형상관리만큼 한국에서 잘못 이해되는 개념도 없으며, 외국에서도 형상관리의 정의는 다양하고 복잡한 개념으로 알려지고 있다. 그리고 개념적으로 간단한 것인데 우리에게 아주 어렵게 소개되는 개념이기도 하다. 항상 정의는 어렵고, 이것을 소화하려면 정말 많은 노력과 지식과 경험이 필요하다. 이제 좀 더 우리의 일상에서 형상관리를 생각해 보려고 한다. 일반적인 형상관리의 정의는 시스템 형상 요소의 기능적 특성이나 물리적 특성을 문서화하고 그들 특성의 변경을 관리하며, 변경의 과정이나 실현 상황을 기록·보고하여 지정된 요건이 충족되었다는 사실을 검증하는 기능이나 과정이다.

체계공학(systems Engineering)에서 보면 형상관리는 사양(Specification), ICD (Interface Control Document), 도면, 설계변경 같은 변경관리, 그리고 납품 후 형상관리 등을 통한 제품과 프로세스의 식별하는 기능이다. 초기는 단순하였지만 점점 진화하면서 개념이 너무 다양해지고 있지만 처음시작은 1960대 방위산업 관련 사업관리의 한 방법으로 시작하였다. 초기의 형상관리는 처음 시 제작으로 만든 무기체계(Weapon System)가 두 번째 만들 때와 다르기 때문에 이것을 극복하기 위해서 사용하는 통합관리방법론이었다. 예를 들어서 첫 번째 시스템을 수 년 정도 개발을 하여서 완성하여서 두 번째 시스템을 만들려고 하니 처음에 시작하였던 계약자, 사업관리자, 엔지니어, 관리자, 고객 등 이해당사자(Stakeholder)들 모두 다른 일을 하거나, 은퇴하거나, 기억이 나지 않는 것이다. 그래서 두 번째 작품(시스템)이 보관하고 있는 도면, 문서 등 기록물을 가지고 만들 수 가 없었다. 그래서 형상관리라는 통합관리방법론이 탄생되었다.

누구인지는 모르지만 동양인 아마 일본인이 형상관리로 해석을 하였다. 그러나 오역인지 절묘한 해석인지는 모르지만 Configuration이라는 말을 형상(形狀)이라는 말로 번역을 하였다. 형상관리에서 형상의 의미는 물건(物件)의 생김새나 상태(狀態)라고 할 수 있다. 이것을 현대적으로 표현한다면 제품(Product)이나 시스템(System)의 물리적 실체에 대한 특성이나 구성 상태를 관리하며 그것들이 변경되었을 때 누가, 언제, 왜 변경되었는가를 수명주기 동안 기록하고 관리하고 추적하고 감리하는 것이다.

그러나 영어의 의미에서 Configuration이라는 의미는 arrangement of a group of thing이라고 말할 수 있다. Arrangement의 의미는 정돈, 정리, 배합, 조정, 합의 등의 의미를 가진다.

형상관리를 간단하게 말하면 조율을 통한 통합관리방법론이다. 대상은 시스템일 수 도 있고 제품이나 프로젝트라고 말할 수 도 제품과 소프트웨어의 결합일 수 도 있다. 다시 말해서 시스템 통합관리방법론이며 다양한 제품의 하드웨어, 소프트웨어 등 모든 제품을 통합적으로 관리하는 방법론이다.조금 철학적으로 말한다면 제품을 개발하거나 사업을 할 때 추상적인 관리대상을 형상화하여서 관리하는 것을 형상관리라고 할 수 있다. 그러면 어떤 것이 추상적이라고 말할 수 있냐 하면 기능, 성능, 제약조건, 제품의 사양 등은 추상적이다. 여기에서 추상적이라는 것은 글로 표현할 수 있는 것이지 실제적으로 보이는 것이 아니라는 것이다. 이것들은 물리적으로 실체인 제품의 특징을 나타내는 추상적인 항목이며, 이것을 형상으로 표현하는 것이 문서(Document)라고 할 수 있다. 여기서도 문서는 우리가 일차적으로 생각하는 종이문서(Paper)가 아닌 기록물이라는 추상적 지식물 또는 콘텐트를 의미한다.

예를 들어서 인생의 활동은 추상적인 활동들의 연속이다. 이것을 형상화 한 것이 출생신고 그리고 혼인 신고, 사망신고 등으로 우리들의 호적에서 변경 내용이 문서화 또는 기록화 되는 것과 유사하다.하드웨어 시스템을 개발할 때 구체적인 예로써 원자력발전소를 건설하는 사업(Program)에서 다양한 이해당사자(Stakeholder)와 소통을 하면서 통합적으로 관리하기 위해서는 설계요건, 물리적 실체(발전소), 시설 등의 정보를 문서화하여서 일관성을 수립하여서 관리하여야 한다. 또한 이러한 일관성을 전 수명기간 동안 유지해야 한다. 요구사항과 물리적 실체 그리고 시설 형상정보가 일치하여야 한다.

일치에 대한 요소 또는 관리 대상을 형상요소(Configuration Item)이라고 한다. 말이 어렵지 관리항목을 말한다. 모두 관리할 수 는 없기 때문에 가장 중요한 대상이나 항목을 말한다. 발전소에서는 발전소 구조물, 계통, 기기, 사업자 요건, 규제요건, 설계요건, 기능특성, 운전변수, 문서, 도면, 소프트웨어 등 일 수 있다.

또한 형상관리에서 가장 중요한 개념 중에 하나는 베이스라인 또는 기준선이라는 것이다. 원자력발전소는 물론 대부분의 공장의 생선시설 등의 각 단계의 베이스라인이 있다. 예를 들어서 제품의 수명주기에서 보면 개념설계, 기본설계, 상세설계, 생산 또는 건설, 운용/유지/보수 그리고 폐기를 단계를 가지는데, 각 단계별 베이스라인 또는 기준선을 가진다. 개념설계 다음은 기능기준선(functional baseline) 기본설계다음에는 할당기준선(allocation baseline), 그리고 상세설계 다음에는 제품기준선(product baseline)그리고 완성한 다음에는 운전 또는 운용기준선(operational baseline)이라고 한다.

형상관리는 보통 제품(일반 응용 소프트웨어 제품과도 동일)의 전 수명주기를 통해서만 발생하고 긴 수명을 가진 제품은 납품 후에도 형상관리에 대한 추적을 해야 한다.

형상관리는 개발 형상관리과 생산 형상관리, 또한 비용 예측을 위한 관리적인 성격을 지니는 작은 의미로 쓰이기도 하지만 큰 범주로 생각을 해보면 제품의 수명주기간에 모든 단계별로 형상관리가 사용될 수 있다. 제조업에서의 형상관리는 제품이 변경되었다는 과정과 상황을 기록, 보고하여 어느 정도 목적에 도달했을 때 충족되었다는 사실을 검증하는 일련의 프로세스를 말한다. 프로세스 중간중간 주요한 이정표(Milestone)이 되는 시점에서는 산출 되는 각종정보 (기술문서, 도면, 제품구조, 자재/부품 마스터, 공정 및 작업정보)에 대한 이력을 관리함으로써 장기간 진행되는 업무정보를 체계적이고 효율적으로 관리할 수 있다.

형상관리와 혼동하여서 사용하는 개념에서는 버전관리, 변경관리 등이 있다. 형상관리 프로세스에는 이러한 리비전, 버전 그리고 설계변경을 포함하고 있다. 리비전이나 버전(Version)은 개정관리라고 할 수 있다. 버전은 문서나 도면, 소스코드 등 정보개체(Item)가 한번 check-out을 하면 PLM에서는 자동적으로 1, 2, 3 등으로 변경된다. 그리고 리비전(Revision)은 이러한 아이템이 베이스라인이나 동결된 후 다시 사용할 때 A, B, C 등으로 증가 된다. 산업에 따라서 Version을 Issue로 사용하는 데도 있지만 개념은 동일하다.

왓트(Watts)가 쓴 개발 문서관리 핸드북 (Engineering Documentation Control Handbook) 에서는 형상관리는 설계 엔지니어와 나머지세계를 연결하는 다리라고 정의하였다. 그리고 기업의 형상관리 성숙도를 5단계로 나누어서 제일 아래 단계를 E (Incapable/No process), D (Acceptable), C (Efficient), B (Best in Class), 그리고 최고의 단계를 A (World Class)라고 정의 하였다.

요즈음은 형상관리가 소프트웨어 분야에서 많이 사용되고 있다. 소프트웨어 형상관리(SCM: Software Configuration Management)라고 불리며, 소프트웨어 분야에서의 PDM이라고 할 수 있다. 소프트웨어 개발 프로젝트를 진행할 때 디지털 파일로 작성된 모든 작업의 결과와 변경사항을 추적하며, 지역적으로 떨어져 있는 여러 개발자들의 협업이 가능하게 하는 시스템이다.

소프트웨어 형상관리(SCM)는 SW개발 및 유지보수 과정에서 발생하는 소스코드, 문서, 인터페이스 등 각종 결과물에 대한 계획, 개발, 운용 등을 종합하여 시스템의 형상을 만들고, 이들 형상에 대한 변경을 체계적으로 관리, 제어하기 위한 활동이다.

또한 소프트웨어 시스템 개발할 때부터 유지보수에 대비하여 만들어져야 한다. 계발 당시에 이러한 점을 소홀히 하게 되는데 추후에 비용증가의 요인이 된다. 소프트웨어가 계속 사용되고 발전하기 위해서는 이러한 개념과 문서화가 필요하다. 소프트웨어 형상관리에서는 관리대상은 대략적으로 다음과 같다.

- 개발되는 소스코드

- 지원 소프트웨어

- CASE 형상요소

- 개발 관련 문서 (분석서, 설계서, 사용지침서)

- 소프트웨어 개발 폴더, 라이브러리

- 프로젝트 계획

- 시험계획/절차/자료

- 형상관리 계획/절차

- 문제점/개선보고서

- 형상관리보고서

그러면 누가 형상관리가 필요하며, 왜 필요한 것인가를 생각하여 보자. 과거에는 특별한 환경에서 형상관리가 적용되었다. 제품의 구조가 복잡하고 제품수명주기가 길고 다양한 분야에 엔지니어가 협업을 할 때에 반드시 형상관리가 적용되어야 실패의 확률을 줄일 수 있었다. 그러한 과정에서 유지보수, 사용기간에 예측하지 못한 항목에 대응하고 필요한 정보문서를 검색하여 완전과 관리에 대응할 수 있을 수 있었으나 현재에는 다양한 환경에서 형상관리를 적용하고 있다.

고사양의 제품이 요구되는 환경 (항공전자)

제품의 수명주기가 길고 고가인 경우 (항공기개발)

제품의 운용에서 극도의 안전을 요구하는 환경 (원자력발전소 시설)

제품을 개발하는 과정에 복잡한 계약관계와 이해당사자가 개입되어있는 환경 (항공방산)

제품이나 시스템의 개발 과정에 서로 다른 복합기술이 사용되는 환경 (철도시스템)

다품종 소량생산의 환경에 소프트웨어와 하드웨어의 결합이 필요한 환경 (메카트로닉스)

다수의 사람들이 한 제품을 동시에 작업하는 경우 (소프트웨어 개발)

제품의 사용 중 개선이나 개량이 지속적으로 일어나는 경우 (인프라, 무기체계)

혁신적인 신제품의 개발환경 (제품혁신)

현재에는 고객이나 개발당사자가 현단계의 산출물과 바로 이전이나 이후의 단계의 산출물의 일치성을 확인 및 인가(Validation)하고 사용자가 요구하는 제품을 개발하였는지 검증(Verification)를 하는 형상관리는 절대적인 역할을 한다.

나의 경험에 의하면 대부분의 개발자들이 형상관리 프로세스를 싫어한다. 심지어는 개발도 힘들어 죽겠는데, 이러한 일까지 해야 하냐고 항의도 한다. 그러나 형상관리는 개발자의 가장 중요한 업무 중에 하나이다. 그리고 형상관리 담당자들은 형상관리 개념과 지식이 약해서 현업사람들을 이끌어가지 못한다. 형상관리 담당자들은 적극적으로 의사결정에 개입을 하여야 한다.

형상관리에서 관리의 의미는 Management이다. 우리말에 관리로 사용하는 영어단어에는 Management, Administrative, Control라는 말이다. 관리의 가장 단순한 단계는 Control이다. 이것은 깊은 지식이 없이 주어진 조건에서 반응만 하면 되는 것이다. 그리고 Administrative는 약간의 업무지식과 결정된 관리능력이 필요하다. 그러나 Management는 깊은 업무지식과 패러다임을 알고 더 좋은 결정을 할 수 있는 창조적인 능력이 요구된다. 그러므로 형상관리자는 이러한 능력이 필요하며, 기업에서는 이러한 인재를 양성해야 성공할 수 있다.

그러나 형상관리 자료야 말로 그냥 형식적으로 하는 것이 아니라 시스템의 수명주기 동안 미래에 무슨 문제가 발생하더라도 해결할 수 있는 유일한 자산(Asset)이라고 할 수 있다.

계획 안은 중요하지 않다, 계획 진행이 중요하다. - 아이젠하워 장군

Plans are nothing, planning is everything ?General Dwight D. Eisenhower

출처 : http://blog.daum.net/hyongsikcho/5416368

Prototypin, Pilot, PoC, BMT 의 차이점

JAESOO — Fri, 17 Oct 2014 15:56:36 +0000

1. 프로토타이핑 모형

- Prototypin/Pilot/PoC/BMT 의 차이점 알아오기

위부분이 궁금하여 잠시 웹서핑.....

[궁금증]

PILOT을 저는 새로운 프로젝트를 시험화하여 먼저 진행하고 성공적인경우 실제 개발을 진행

실제 프로젝트를 들어가기전의 시범프로젝트라고 알고 있었는데...

오류를 발견하기위한 시험테스트가동을 의미하는거라고 되어있네요....

업무에서 혼용되어서 쓰이는거 같은데..

다른분들은 어떻게 생각하시나요?

[웹서핑및 프로젝트관련문서 확인]

1. 성능 시험(BMT : benchmark test)
[정의]
어떤 기계나 시스템을 실제로 사용될 것과 같은 여건에서 성능을 측정하기 위해 하는 여러 가지 검사.
통상적으로 1개 또는 여러 개의 대표적인 프로그램을 비교하고자 하는 컴퓨터들에 수행시켜 성능을
측정함으로써 컴퓨터의 속도나 단위 시간당 일 처리량 등을 비교할 수 있다.

[프로젝트]

프로젝트개발의 도입단계의 RFP에 의한 제안서를 제출한 후보업체의 아키텍처등 적합성및 성능검증을위해
BMT테스트를 실시후 해당 테스트결과는 업체선정의 평가에 반영된다.

2. 개념 증명 [ POC, proof of concept, 槪念證明 ]
[정의]
제품, 기술, 정보 시스템 등이 조직의 특수 문제 해결을 실현할 수 있다는 증명 과정.
아직 시장에 나오지 않은 신제품에 대한 사전 검증을 위해 사용된다.

[프로젝트]
경쟁제품과의 비교에 이용되는 벤치마크테스트와 달리 제품이나 기술에 대한 확신이 부족할 경우
도입 위험을 완화하고 기술적인 접근방법을 확인하여 사용자의 반응을 확인할 목적으로 실시함

3.파일럿 [ pilot ]
[정의]
원시 프로그램이나 시험 프로그램 등을 시험하는 일.
프로그램을 실제로 운용하기 전에 오류 또는 부족한 점을 찾기 위하여,
실제 상황과 유사한 조건에서 시험 가동하는 행위이다.

[프로젝트]
시범테스트및 통합테스트단계의 SW결함측정테스트

4.시제품화 [ prototyping, 試製品化 ]
[정의]
새로운 컴퓨터 시스템이나 소프트웨어 개발 기법의 하나.
시제품화는 시제품, 시험 사용, 개선 과정을 반복하여 실용판의 사양을 완성해 나가는 기법으로,
전통적인 생명 주기 모델 또는 폭포수 모형(water-fall model)의 단점을 보완하기 위해 점진적으로 시스템을
개발하는 접근 방법이다. 시제품의 시험 사용을 통해서 이전에 밝혀지지 않았던 사용자의 요구 사항을 구체적으로
규명할 수 있다는 장점이 있으며, 특히 초기에 요구 사항이 확실하지 않거나 경영 환경의 급속한 변화 등으로
사전에 모든 요구 사항을 결정할 수 없는 불확실한 상황에서 소프트웨어의 개발 작업을 유연하게 제어,
관리할 수 있게 해 준다.

[프로젝트]
개발의 초기 단계에 전체적인 기능을 간략한 형태로 구현한 잠정판 또는 시제품을 만들어 사용자에게 제공한다.
사용자의 시험 사용을 통해서 요구 사항을 분석하거나 요구 사항의 정당성을 검증하여 다음 단계 또는
실용 시스템에 반영한다.

[출처] Prototypin/Pilot/PoC/BMT 의 차이점 (정보처리기술사카페(IT Supreme Team)) |작성자 정지영

출처 : http://sunkyu.tistory.com/71989

국내에서 보급된 ERP 솔루션사별 ERP종류 - 업데이트 되는 포스트

JAESOO — Tue, 16 Sep 2014 08:53:17 +0000

업데이트 할때마다 제일 위에 두겠습니다.

다른 포스트에서도 말씀드렸다 시피 ERP업체는 국내에 꽤 많은 편이다.

근래에는 그런 업체들이 철수하고 망하는 경우에는 인력들이 나와서 지금은 더 많아진 편이고

소위 Front 단위의 솔루션을 하는 기업들도 ERP vendor라는 이름으로 사업을 하고 있습니다.

대표적으로 Play를 했던 업체들을 추억처럼 리스트화가 되어 있는 포스트를 보고 ...
(뭐 신문 기사를 올려 놓은 듯 해서 ... 첨언을 좀 했습니다. 이렇게 하면 저작권에 문제가 안 된다고 하던가요?)

불쾌하신 분들은 설득적인 말 몇마디만 해주시면 삭제하거나 설득이 안 된다면 게속 포스트는 이어집니다.
(없는 이야기를 하겠다는 것은 아니고요.)

Quiero Elegir by crsepulv

예전 자료를 기준으로 만들었습니다.

현재의 내용과 좀 차이가 있을 수 있습니다.

업체명	솔루션	주요 특징	Knowing
SAP코리아	SAP R/3, mySAP ERP	• 기업용 ERP솔루션 부문 시장 점유 1위	맞습니다만 다른 제품에 비해서 가격이 높습니다.
		• 지난 31년간 전세계 120개국 2만여 기업에서 현장 사용 검증	돈 없으면 고객도 아닙니다. (농담반 진담반)
		• 마이크로소프트 닷넷(.NET), IBM 웹스피어와 연동	인정합니다.
한국 오라클㈜	Oracle e-Business Suite	• 어플리케이션, DB, 개발툴, Implementation 모두 제공	맞습니다만 .net / SQL에 비해서 가격이 높습니다.
		• 중소기업 ERP구축방법론 보유 : FastForward	우리가 생각하는 중소기업하고 다를 수 있습니다.
		• Order Management, MFG모듈의 코드 불안정성	개선이 됐다고는 하는데 정확하게 모르겠습니다.
		• 높은 비용(라이센스, 컨설팅 비용, 유지/보수)	SAP처럼 마찬가지 입니다. 돈 없으면 고객도 아닙니다.
		• 대기업 계열사 등 중견 기업에 Focus	맞습니다.
SSA GT	BPCS	• 한국 시장에서의 점유율은 5% 미만	더 떨어집니다.
SSA GT	BPCS	• 매출은 전부 제조업 분야에서 발생	맞습니다만 Win Back을 많이 당했습니다.
QAD	MFG/PRO, eQ 3.5, eQ Supply Visua lization	• 대규모 제조업(자동차,전자,화학,제약)에서 주로사용	자동차 전문입니다. 국내에서는 철수 했습니다. 호주에서 라이센스를 구매해야 합니다. 오토에버닷컴에서 현대자동차 협력 업체 대상으로 영업진행하다가 못한 사례가 있습니다.
		• 세계 25대 자동차 회사 중 13개 업체에서 사용	맞습니다. 저 회사 창업자 남편이 자동차 공장에 다녀서 늦게 퇴근해서 S/W를 만들어서 일찍 퇴근 시켰다는 이야기가 있습니다.
		• 중간 규모 및 대규모 제조업 시장에 Positioning	Text version이 2-3년전에도 공급된 적이 있습니다. 국내 사정과는 맞지 않다는 이야기도 있습니다.
J.D. Edwards	J.D. Edwards ERP /SCM, Ariba e-Procurement	• 중간 규모 제조업 Target (매출 규모 2천억 ~4천억)	삼양사에서 쓰는 것으로 알고 있습니다.
		• 타 외산 ERP에 비해 소규모	SAP, Oracle에 비해서는 떨어지는 것을 알고 있습니다.
		• 국내는 ㈜윌러스에서 공급	제약에 강점이 있다지만 악몽같은 꿈을 꾸다가 살아난 기업을 알고 있습니다.
		• 전세계적으로 6300여 고객 보유	그렇겠죠.
삼성 SDS	UniERP II , UniERP Lite	• 국내 ERP 업체 중 선두 (시장 점유율 : 8.26%)	삼성전자에 납품하면 강제조항이였던 적이 있습니다.
		• 해외 사업 전개 (중국/일본/구주/미국/동남아)	이건 SAP 아닌가요? 삼성전자 내부에서 진행했던 아니면 납품업체 대상으로 진행한 것 같습니다.
		• 3-Tier 구성/웹지원	글쎄요.
		• 뉴소프트기술과 공동으로 중소기업 대상 uniLITE 출시	uniLite는 시장에서 그렇게 좋은 평을 못 얻고 있습니다.
		• 다국어/다통화 지원	맞습니다. 다통화는 제대로 인것으로 알고 있습니다.
뉴소프트 기술	B2B ERP, uniLITE	• B2Bi 및 PKI 인증 보안 시스템 내장	코스닥 상장 후 회사 인크루트라는 곳에 팔아버렸습니다. 주주의 가치란? 판단에 맞기겠습니다.
		• 10억~500억 미만의 전기//전자 조립업과 유통업 Target	이때 레퍼런스를 가지고 있다면 잔당(?)들이 일을 하는 것 입니다.
		• 자동차 업종 및 섬유 업종 버전은 Channel 영업	자동차 업종은 아닙니다. 전기 전자 영업입니다. / 저 업종에 Channel 영업은 안 한 것으로 알고 있습니다.
더존 디지털웨어	Neo-M, NEOplus, Neo-Q, Neo-X	• 세무 회계 솔루션의 80%이상의 시장 점유율	다 맞습니다만 ERP 회사는 아니라고 생각합니다.
		• 개인 및 기업을 위한 ASP 사업 진행	다 맞습니다만 ERP 회사는 아니라고 생각합니다.
		• 싱가포르 정부의 ASP 시범 사업에 참여/ 중국 진출	다 맞습니다만 ERP 회사는 아니라고 생각합니다.
소프트파워	TopEnterprise, TopERP	• ‘3만개 중소기업 IT화 지원 사업’ 참여 솔루션 업체 중 최다 계약 실적 (25% 점유)	말도 안되는 점유율은 … 저는 내막은 그누구보다 잘 알고 있습니다.
		• 중견기업/대기업용 ERP 솔루션으로 서울대, KAIST와 공동 개발 (topEnterprise)	한참 전의 이야기 입니다. ERP라는 말이 유행하기 전의 말입니다.
		• 국내 ERP 업체 매출 2위 (6.87%)	계약에 대한 개수라면 맞을 겁니다. 하지만, 유지보수 유지율은 아니라고 생각합니다.
영림원	K.System Grand, K.System Standard (ERM)	• 3-Tier Architecture/ 객체 지향형 컴포넌트	새 제품 출시 이후 문제가 많다고 합니다. 매번 새제품을 내지만 홍역은 거래처가 앓고 있다고 합니다.
		• No Customization	기본 모듈에서 SI를 합니다. 정책이 저런 것이지 일을하는 방법은 커스터마이징을 겸한 컨설팅을 합니다.
		• 올 11월 전 모듈 웹버전 출시	한참 전의 이야기 입니다. 지금은 신제품이 WPF기반으로 나왔다고 들었습니다. 하지만, 안정화가 될려면 시간이 좀 걸려야 한다고 합니다.
지엔텍	Vision21, @Vision21	• 100% Java로 개발된 객체 지향형 컴포넌트 구조	망했다고 들었습니다.
		• 3-Tier Architecture (BEA의 WebLogic 사용)	속도가 느리다고 들었습니다. 데이터도 많이 틀리고 결산을 할려면 전산실에서 밤을 세워야 한다고 계산을 하는게 아니라 계산이 되도록 하는데 많은 시간이 걸린다고 들었습니다. 그것도 전기.전자 업종에서 ... Business Application을 Java로 개발하면 안된다는 사례가 여기에 있습니다. 속도문제가 제일 큽니다. 인력구하기가 힘듭니다. 고가의 H/W를 써야 합니다. (차라리 ERP로 고생하는 직원에게 고기 회식을 몇번 더 시켜주는 것이 옳은 일이라 봅니다.)
		• ASP 사업 적용을 위한 Multi DB, App. Server 구조	ASP 사업은 꽃을 못 피웠다고 들었습니다.
		• 영어, 중국어, 일본어 지원	맞습니다. 하지만, 의미없습니다.
한국 하이네트	Infra ERP, Infra PRO 2000, Medi ERP, 윈파워	• 11년간의 업무 전산화 경험 보유	모회사가 ERP를 도입해서 실패하고 SAP로 검토/구축을 했다고 들었습니다.
		• 소규모 사업자 Target	맞습니다. 회계는 더존, 키컴, 물류는 하이네트였던 적이 있었습니다. 소프트파워와 함께 1만개. 3만개 사업의 최대 수혜 업체
		• 제약/제조업 분야 업무 Process에 특화된 솔루션	제약부분에는 많은 납품 사례는 있지만 UI가 문제가 있고 낡은 개발툴이 였다고 들었습니다.
		• 대규모 사이트 시스템 구축 경험 및 지원인력 부족	코스닥 상장 후 회사 다른 곳에 팔아버렸습니다. 주주의 가치란? 판단에 맞기겠습니다.
코인텍	Eagle ERP	• 마이크로소프트사의 .Net을 기반으로 국내 기술로 개발된 세계 최초의 100% 웹 ERP 솔루션	망했다고 들었습니다.
코인텍	Eagle ERP	• 중견 기업용 ERP	중견 기업을 대상으로 SI를 했다고 들었습니다.
대한상공 회의소	SMERP, SMERPpop	• 중소규모 대상 기업용 ERP	지금은 다른 업체가 ERp 제품 이름을 바꾸어서 하고 있습니다.
		• 제조업종과 유통업종으로 세분	제조업종도 별로이고 그렇다고 유통업종도 좋지 않습니다.
		• 100% 웹기반 ERP 솔루션	100%는 아닙니다.

다소 내용이 다르거나 이상하다고 생각이 되는 부분이나 회사나 제품은
e-Mail로 연락을 주시면 다시 한번 알아보도록 하겠습니다.

2005년도 자료네요. 지금과는 많이 차이는 나지만 귀차니즘 때문에 ...
http://blog.naver.com/addibuddi?Redirect=Log&logNo=19152279 한번 보시고요.

■ ERP 시장 최근 동향

중소기업 ERP `최대격전지` 부상

그동안 국산 솔루션 업체들의 텃밭이었던 중소·중견기업(SMB) 전사적자원관리(ERP) 시장에 외산 솔루션 업체들이 잇달아 진출하면서 이 시장이 기업용 애플리케이션 업계의 최대 격전지로 부상했다.
-> 격전지이지 먹을 거리는 거의 없다시피 한 시장이라고 생각합니다.
SMB라는 의미가 외산에서 생각하는 것 하고는 많이 차이가 납니다.
근래에 모 외국계 ERP회사에서 중소기업이라는 이름을 빼고 강소기업이라는 이름으로 등급이 낮은 제품을 가지고 영업을 하던데 ... 세상이 좀 많이 변했다고 할 수 있습니다. 쳐다보지도 않던 시장을 ...

21일 관련업계에 따르면 SAP코리아와 한국오라클이 최근 SMB용 ERP 제품과 사업전략을 발표한 데 이어 한국마이크로소프트도 본사의 글로벌 파트너인 홍콩계 ESG코리아와 함께 내달 `ERP 솔루션 세미나'를 개최하는 것을 시작으로 ERP 사업에 간접적으로 진출할 계획이다.
-> ESG 이후 몇몇 MS 파트너가 있었습니다. ERP는 MS에서 책임을 안진다는 이야기가 있습니다.
하지만, 외산 ERP는 국내 지사에서 책임을 진 사례가 없는 것으로 알고 있습니다. 파트너사가 책임을 지고 수행을 하는 것으로 알고 있습니다.

또 중견기업 ERP 시장을 주도해온 SSA GT코리아도 최근 바안코리아 합병작업을 완료하고, 매출액 1000억~3000억원대 중견기업 시장은 물론 중공업, 철강 분야 등으로 사업을 다각화할 계획이다. 여기에다 JD에드워드의 국내 총판인 윌러스는 피플소프트 제품을 추가로 공급하기 위해 현재 협상을 벌이는 등 외산업체들의 인수합병에 따른 후폭풍이 중견기업 시장에 큰 영향을 미치고 있다.
-> 지난 옛이야기 인것 같습니다.

이와함께 다국적 기업을 대상으로 CA의 `액팩' ERP 제품을 공급해온 온라인패스도 최근 홍콩의 외산 ERP 업체와 손잡고 중견기업용 제품을 추가로 선보일 계획이다.
-> 지난 옛이야기 인것 같습니다.

이에 따라 국내 중견 및 중소기업 ERP 시장은 SAP 오라클 등 대형 ERP 업체와 그동안 이 시장을 주도해온 국내 ERP 업체, SSA GT코리아 윌러스 온라인패스 한국MS 등 외국계 중견 솔루션 업체 등의 3파전으로 전개될 전망이다. 특히 삼성SDS, 영림원, 코인텍, 뉴소프트기술, 소프트파워 등 주요 국산 ERP 업체들은 최근 1~2년 사이에 매출액 1000억원대의 중견기업 시장으로 사업영역을 빠르게 확대하고 있어 외산 체들과의 시장쟁탈전이 불가피하다.
-> 쟁탈전에서 사라진 업체들이 있네요....

이중 시장판도에 가장 큰 영향을 미칠 변수는 SAP코리아와 한국오라클의 SMB 시장을 겨냥한 `미니 ERP' 제품의 출시. 양사는 모두 중견기업과 중소기업을 각각 겨냥한 별도의 제품과 서비스로 시장을 공략한다는 전략이다.
-> 오라클은 왜 저는 모르고 있었죠? 그게 아니라 ASP 제품을 이야기하는 것 같은데.

SAP코리아는 매출액 200억~2000억원 정도의 기업들을 대상으로 △500억~2000억원 규모의 경우 `마이SAP 올인원'으로 △500억원 내외의 기업의 경우 내년 상반기에 출시할 `마이SAP 비즈니스원'으로 공략한다는 계획이다. SAP코리아는 내년 매출액의 15% 가량을 두 분야의 제품으로 거둔다는 목표다.
-> SAP 코리아에서의 성과는 Business One이 이룬 것 같더라구요.

한국오라클은 오는 11월 `오라클 e비즈니스 스위트 스페셜 에디션'이라는 중소기업용 제품을 국내에 선보일 계획이다. 한국오라클은 현재 아시아태평양본부와 국내 협력사 정책, 기존의 SMB용 제품인 패스트포워드와 스페셜 에디션의 포지셔닝 문제 등을 협의중이다.
-> 지난 옛이야기 인것 같습니다.

한국MS도 내년경 ERP 전담조직인 `마이크로소프트 비즈니스 솔루션(MBS)'을 신설하기로 내부 방침을 정한 것으로 알려졌으며, 당분간 ESG코리아의 사업을 간접지원하는 형태로 ERP 사업에 나설 것으로 보인다.
-> 지난 옛이야기 인것 같습니다. 아직까지 몇년째 국내 시장에 문만 두드리고 있는 것 같습니다.

업계 한 전문가는 "상반기 국내 ERP 솔루션 시장은 약 1000억원 내외인데 한국오라클과 SAP코리아의 일부 중견기업 프로젝트 수주를 포함해 적어도 70% 가량이 SMB 분야"라며 "당장은 국산과 외산 ERP의 경쟁이 매출액 1000억원대의 중견기업 시장에서 벌어지겠지만 머지않아 수백억원 대의 중소기업시장에서도 격전이 불가피할 것"이라고 전망했다.
-> SAP가 포문을 연것 같습니다. 하지만, 글쎄요 ... 다른 나라와 같을까요? 또, 글로벌 형태의 통합을 추구하는 회사에게는 맞지만 ... 글쎄요 ... 그리고, 그게 ...

출처 : http://erp4u.tistory.com/484

인건비, 제경비, 기술료 개념 (소프트웨어사업 대가의 기준, SW사업 대가산정 가이드)

JAESOO — Thu, 04 Sep 2014 17:21:01 +0000

☞ 인건비 : 사업에 직접 투입되는 인력에게 지븍하는 급여성 비용
☞ 제경비 : 직접비(인건비와 직접경비)에 포함되지 아니하는 비용으로서 간접비를 말하며, 임원, 서무, 경리직원 등의 급여, 사무실비, 사무용 소모품비, 비품비,

기계기구의 수선 및 상각비, 통신운반비, 회의비, 공과금, 운영활동비용 등을 포함 (직접인건비의 110%～120%까지 계산)
☞ 기술료 : 소프트웨어개발사업자가 개발·보유한 기술의 사용 및 기술축적을 위한 대가로서 조사연구비, 기술개발비, 기술훈련비 및 이윤 등을 포함
(직접인건비에 제경비의 20～40%)

참고 : 소프트웨어사업 대가의 기준 (2009)

출처 : 상임위 제출 자료 중

관리인원(PM 등)은 직접인건비인가? 제경비인가?

JAESOO — Thu, 04 Sep 2014 17:20:39 +0000

지난달 말 정보통신부로 SW사업대가를 적용한 사업에 대한
감사원 질의가 들어와 답변차원으로 다녀왔습니다.

“모 연구소”에서 작성한 예정원가가 문제가 되었는데 정보화사업에서 관리인원(PM, QM, SM 등)에 대한 직접인건비와 제경비 적용범위에 대한 논란이 된 것입니다.

“모 연구소”에서는 예정가격을 작성함에 있어 수발주기관이 합의한 문서를 근거로
관리인원을 직접인건비부분으로 편성하였으나,
감사원에서는 관리인원은 제경비에 포함되는 간접인건비로 중복 계상됨으로
중복된 부분은 환수하여야 한다는 것이었습니다.
양측의 의견이 정리되어 원만하게 해결되었지만
앞으로도 유사한 분쟁이 발생할 가능성이 높다고 생각되어
이와 관련된 이슈를 말씀드리고자 합니다.

관리인원은 직접인건비에 포함되는가? 아니면 간접인건비(제경비)에 포함되는가?

제경비에 대한 소프트웨어사업 대가의 기준에서의 정의는
직접비(인건비와 직접경비)에 포함되지 아니하는 비용으로서 간접비를 말하며, 임원, 서무, 경리직원 등의 급여, 사무실비, 사무용 소모품비, 비품비, 기계기구의 수선 및 상각비, 통신운반비, 회의비, 공과금, 운영활동비용 등을 포함하는 비용으로 말하고

엔지니어링사업 대가의 기준에서도
직접비(직접인건비와 직접경비)에 포함되지 아니하고 엔지니어링활동주체의 행정운영을 위한 기획, 경영, 총무 분야 등에서 발생하는 간접 경비로서 임원․서무․경리직원 등의 급여, 사무실비, 사무용 소모품비, 비품비, 기계기구의 수선 및 상각비, 통신운반비, 회의비, 공과금, 운영활동비용 등 유사한 내용을 말하고 있습니다.

그러면 직접비와 간접비에 대한 구분이 중점인데
직접과 간접에 대한 「국가를 당사자로 하는 계약에 관한 법률 및 시행령, 시행규칙」 등의 계약관련 법률에서 정의하는 내용을 살펴보면

인건비의 직접/간접 구분으로
예정가격 작성기준 (재정경제부 회계예규 2200.04-160-4, 2007. 10. 12)에서는
직접노무비는 제조현장에서 계약목적물을 완성하기 위하여 직접작업에 종사하는 종업원 및 노무자에 의하여 제공되는 노동력의 대가를,
간접노무비는 직접 제조작업에 종사하지는 않으나, 작업현장에서 보조작업에 종사하는 노무자, 종업원과 현장감독자 등의 기본급 등을 말합니다.
이는 지방자치단체 원가계산 및 예정가격 작성요령 (행정자치부예규 제260호, 2007. 10. 5)에서도 동일하게 정의 하고 있습니다.

경비의 직접/간접구분으로는
소프트웨어사업대가의 기준의 제 3장에 직접경비항목은 별도로 정의되어 있으며 이 외에 간접적으로 발생되는 것은 간접경비로 보게됩니다.

이러한 각 정의를 정리하면
직접인건비는 직접 작업에 참여하는 인력의 노동력에 의한 대가를 말하며
간접인건비는 직접작업에 참여하지는 않으나 보조작업과 감독자의 노동력에 의한 대가를 말한다.
제경비는 간접인건비부분과 경비중 직접경비를 제외한 간접 경비부분, 일반관리부분을 합한 것을 제경비라 하게 됩니다.

위의 정리를 통해 시스템 구축을 들여다보면
작업에 직접 참여하는 인력은 직접인건비로, 보조작업자, 현장 감독자 등은 간접인건비로 구분하게 됩니다. 사업을 관리하는 일반적인 PM(프로젝트 매니저)과 QM(품질 매니저), SM(시스템 매니저) 등의 인력은 제경비에 포함된 것으로 보는 것이 타당합니다.
간혹, 발주기관에서 특수한 작업을 이유로 관리인력의 배치를 요구하는 경우에는 반드시 제안요청서나 과업지시서에 그 내용이 명시되어 있어야 합니다.
관리인원을 직접인건비로 편성할 경우 간접인건비 중복계상으로 중복계상금액 환수 등의 문제가 발생할 수 도 있으니 이점 주의하여야 합니다.

일반적인 PM(프로젝트 매니저)과 QM(품질 매니저), SM(시스템 매니저) 등의 관리인력은
간접인건비로 제경비에 포함됩니다.

“모 연구소”와 감사원의 문제는
수발주자가 합의한 문서를 정확히 확인하지 않아 발생된 일로
수발주자가 합의한 문서를 근거자료로 하였어도 예정가격작성기준(원가계산 및 예정가격 작성요령)과 소프트웨어사업 대가의 기준 등의 제규정을 검토하여 예정원가를 작성하여야 했으나 기초자료 분석을 소홀히 한 결과로 보여집니다.

예정가격을 작성할 때에는 ①반드시 충분한 시간이 보장되어야 하고, ②제안요청서, 과업지시서 등의 명확한 근거자료 확보하여야 하며, ③기본적인 분석에 따른 사업이해와 ④구현 기술의 이해, ⑤사업담당자의 인터뷰 등으로 문서 내에 담지 못해 협상시 제시될 내용들을 확인하고 ⑥SW사업대가 등의 제규정 적용검토는 기본을 지켜야 할 것입니다.

계약담당자나 사업담당자도 원가산정을 의뢰할 때에는 공신력있는 전문기관을 확인하고 발주하는 지혜를 발휘해야 할 것입니다.

사례를 통해 정확한 제경비 적용 방법을 알아보았습니다.
다음 메일에는 더욱 알찬 내용으로 만나 뵙겠습니다.

우리 센터는 보다 현실성있게 다가서는 소프트웨어사업 대가의 기준 개정과
객관적이고 합리적인 예정원가 작성을 위한 원가산정이 되도록 노력하겠습니다.
많은 성원과 격려를 부탁드립니다.
감사합니다.

출처 : http://www.kdb.or.kr/info/info_02_03.php?mode=detail&dbnum=21

Reseller(리셀러), Distributor(디스트리뷰터), Vender(벤더), Dealer(딜러) 차이

JAESOO — Thu, 22 May 2014 15:20:09 +0000

1.reseller - 말 그대로 재판매업자
제조업체로 부터 구매하여 다시 업체나 개인에게 재판매함
(reseller로부터 구매시는 향후 지속적인 A/S등의 서비스를 받기 힘듬)

2.Distributor- 정식으로 본사또는 지사와 license 계약을 맺고 유통시키는 업체
(주로 하드웨어나 부품을 취급)-유통만 하지 제조는 하지않음

3.Vendor - Distributor와 의미가 비슷함
직접제조자일수도 있고 유통만 하는 업체일수도 있슴.
4.Dealer- Reseller와 의미가 비슷함.
(업체로 부터 직접구매해서 판매하거나 다른 유통업체로부터 구매해서
재판매도 함)

출처 : http://ask.nate.com/qna/view.html?n=3034145

프리랜서 단가 계산기

JAESOO — Wed, 14 May 2014 10:33:28 +0000

프리 단가 계산기 입니다.

경력을 만으로 입력한후 옵션들을 선택하고 계산버튼을 누르면 단가가 나옵니다.

단가 : 만원

경력 :	년	만으로 경력
경력옵션 :
가중치옵션 :	업무또는특정기술동일성 : 1+(년수*0.02) 전산전공: 1.03 3년미만: 0.9 PM : 1.13
근무형태 :

무중력 인간 - 세종대왕 (gravity man free)

출처 : okjsp에 as1님의 계산방식을 참조하였습니다.

단가공식 :

단가 = (((경력 + 경력옵션) * 가중치 옵션들 곱하기 * 20 ) + 270 ) * 근무형태

경력 : 만으로 경력

경력 옵션
고졸 : +0
초대졸 : +2
대졸 : +4
대학원졸: +6

(경력 + 경력옵션)이 15년 넘어가면 15년으로 친다.
(경력 + 경력옵션)이 5년이 안되면 5년으로 친다

가중치 옵션들
업무또는특정기술동일성 : 1+(년수*0.02)
전산전공 : (1.03)
3년미만 : (0.9)
PM : (1.15)

근무형태
SI : 1
SM : 0.9

그냥 내기준임니다

http://www.okjsp.pe.kr/seq/174046

출처 : http://techknowdger.blogspot.kr/2014/02/blog-post_16.html

입찰기초 공부하기 (입찰 안내서) - 입찰준비 과정, 참가등록 방법, 공동도급 관련 내용 등

JaeSoo — Mon, 14 Apr 2014 08:41:51 +0000

입찰이 처음이신 회원님을 위해 전자입찰시 꼭 알아야할 내용들을 정리하여

"입찰기초 공부하기"라는 입찰 안내서를 제작하였습니다.

입찰준비 과정, 참가등록 방법부터 공동도급 관련 내용까지 전반적인 기본 내용들을 담아

누구나 무료로 다운로드 받으실 수 있습니다. 아무쪼록 회원님들께 많은 도움이 되었으면 합니다.

혹, 내용중 잘못된 부분이 있거나 궁금한 사항이 있을 경우 고객센터 1544-2785로 문의바랍니다.

입찰기초 공부하기 다운로드 : info21c_bid_study.pdf

출처 : http://www1.info21c.net/

UML기반 개발강좌 3 - 기능점수견적

JaeSoo — Thu, 27 Mar 2014 18:57:21 +0000

UML기반 개발강좌 3 - 기능점수견적

2011/03/23 14:22

어제에 이어 UML기반의 개발강좌 3편이다.
오늘 할 이야기는 Activity Diagram을 뽑고 Function Point와 연동하여 견적내기이다.
먼저 다음 포스트를 읽고 오자.

[기능점수견적 산정강좌 바로가기]

기능점수 견적을 요점정리하면 다음과 같다.

1. 기능점수는 기능을 가지고 도출할 수 있다.
2. 기능점수는 디자인 등 부가적인 부분에 대해 견적할 수 없다.
3. EI/EQ/EO, ILF/EIF 만 무슨 의민지 알면 기능에 대한 도출은 쉬울 것 같다.

암튼 UML로 이러한 견적을 뽑아 내려면 EI/EQ/EO, ILF/EIF를 도출해야 한다는 결론이 나온다.
그런데 내가 도출한 USE CASE에는 아무것도 보이지 않는다. 그냥 기능만 있지 그 안에 무슨 내용이 어떻게 오고가는지가 없다.
이럴때 쓰라고 있는게 Activity Diagram이다.
즉, Activity Diagram은 Use CASE를 분해해서 표현하는 그림으로 하나의 기능을 세밀하게 쪼게는 역할을 맡고 있다.
물론 내가 사용하는 설계 방식에서는 Activity Diagram은 Class Diagram으로 전개시키는 역할도 맡고 있다. 이건 다음시간에 삺펴보고 암튼 Use CASE 하나를 잡고 쪼게보자.

나는 "경로를 안내받는다"라는 녀석을 선택했다. (왜? 네비게이션은 안내받으려고 사는거 아니었나요?)

1. USE CASE중 "전원을 연결한다"는 "전원을 조작한다"와 중복되므로 삭제했다.

2. 오른쪽 Model Explorer에서 "경로를 안내받는다" Use CASE를 선택하고 마우스 우클릭하여 Diagram을 추가하자.

3. 이름을 USE CASE와 구분하기 위해 "//"를 추가하여 "//경로를 안내받는다"로 변경하였다.

4. 이제 "ToolBox"에 뜨는 Diagram이 다음과 같이 바뀐다. 역시 쓰는 넘만 쓰니까 다 자세히 알필요는 없다.

"ActionState"는 Method가 되는 녀석이다. 어떤 의미인지는 나중에 예제로 표현해 보겠다.
그리고 InitialState, FinalState는 시작과 끝이고 Decision이라는 넘은 분기이다.
나머지는 선이니까 생략.
한가지 주의할 점은 Activity Diagram을 그리는데 Use CASE를 뒤엎을 각오를 해야 한다는 것이다.
이게 무슨 의미인지 "경로를 안내받는다." Activity Diagram을 한번 보도록 하자.

위의 Activity가 과연 사용자 입장에서의 Activity인가? 뭔가 혼자 돌고 있는 그림이라면 Use CASE를 너무 작게 쪼겐것이다.
그렇다면 사용자의 입력을 기다리기 위해 "목적지를 입력한다"라는 녀석과 "경로를 안내받는다"라는 녀석을 합칠 필요가 있다.
따라서, USE CASE를 다시 조정했다.

몇몇 USE CASE를 날려버렸다. 가장 핵심적인 기능부터 접근했기 때문에 가능한 빠른 판단이다.
이제 Swimlane을 사용자 까지 포함시켜서 "경로를 안내받는다"라는 USE CASE를 Activity Diagram으로 전개시킬 준비가 된것이다.
다음은 그 결과이다.

이제 위와 같이 한 이유를 설명하겠다.
첫째, 이렇게 사용자를 포함시킬 수 없다면 그것은 요구사항이 아니다. 따라서, 개별 요구사항을 합쳐서 요구사항을 크게 만들어야 한다.
둘째, 반대로 지나치게 클수 있다. 이경우 인수시험계획을 만들기 어렵다. 지나치게 커서 시험항목이 보이지 않는 것이다. 이경우는 쪼게야 한다.
무엇보다 가장 큰 이유는 위와 같이 요구사항을 Activity Diagram으로 테스트 할 수 있다는 점이다.

아무튼 각각의 ActionState들은 Method와 동일하다고 가정하고 Method에서 사용할 Entity와 부가설명을 달아보자.

이제 내 눈에는 그럴싸하게 보인다.
Method는 총 11개가 도출되었고 Entity도 다수 도출되었다.
물론 네비게이션 전문가가 보기에는 빠진 기능이 많을 것이다. 어차피 빠진건 검토하면서 다시 넣으면 될일이고 현재 생각할 수 있는 기능은 다 들어간 것같다.

업무상 꼬이는 부분도 없으며 요구사항 그자체로는 완벽하다.
아무튼 이제 견적을 한번 때려보자.
- 초기화는 단순 입력만 이니 EI/ILF
- 목적지이름조회, 목적지주소조회는 EQ/ILF
- 주소목록선택, 목적지목록선택은 EI/ILF
- GPS좌표를 획득하는건 외부 시스템 연동으로 EIF
- 경로획득은 ILF
- 현재좌표획득은 EIF
- 음성안내는 EQ/ILF
- 현재지도갱신 EQ/ILF
- 안내종료는 EQ/ILF

이상 대충 뽑았다.
따라서 기능점수 견적은 다음과 같이 작성되어야 한다.
- EI : 8
- EQ : 4
- EO : 0
- ILF : 7
- EIF : 2

하여 결론적으로 간이 견적표는 다음과 같이 나온다. (위에 기능점수 견적산정 링크에서 다운로드 받으세요.)

총 FP점수는 110.9점이 도출된다.
보정계수와 원가산정표로 가서 나머지 보정을 하자.
먼저 기능점수의 복잡도로 "평균복잡도"를 선정했다. 물론 네비게이션 만드는게 쉬운일은 아니겠지만...

규모보정계수는 300점 미만이므로 그대로 두고...
어플리케이션 유형 보정계수는 통신제어용(GPS)이므로 비율을 100% 해줬다. (합계는 100%여야 한다.)

언어는 알아서 하면 되고... 품질/특성 보정계수는 다음과 같이 설정했다.

결과적으로 89,929,418 원의 원가가 발생하고 여기에 이윤 25%를 붙여서 총 112,411,773원의 견적이 완성된다.
물론 여기에 디자인비용, 각종 직접비용은 생략되었으니 이건 알아서 넣자.

이것으로 Activity Diagram으로 USE CASE(요구사항)을 테스트하고 견적을 내는 단계까지 완료.
다음에는 Activity Diagram으로 인수시험CASE를 만들어 보자.

ps. 띰띰해서 그려본 현재 적용한 개발 프로세스

중요한게 바로 요구사항 Pool이다.
요구사항이 들어오면 즉시 실행하는게 아니라 일단 Pool에 넣어둔다.
(왜냐하면 감정을 최대한 없애기 위한 조치이다. 훗날 냉정하게 바라보면 불필요한 기능을 구현하느라 시간을 다 소모했던 경험이 있다면 반드시 적용하자.)
프로젝트 협의체에서는 얼마나 완료되었는지 시연하고, 이슈를 해소하기위해 정책을 정리하고, 요구사항 Pool을 뒤져서 개발우선순위를 조정한다. 우선순위가 조정된 개발범위중 상위 몇개를 골라서 구현지시를 하면 개발팀은 분석설계후, 코딩하고 단위테스트를 진행한다. (Visual Studio는 단위테스트를 자동생성해줘서 권장. 아마도 이클립스도 자동으로 만들어 주는 Plugin이 있을것 같음)
이후에 Build하고 통합테스트라는 테스트를 거친뒤에 개선요구사항과 버그 수정사항을 다시 Pool에다 넣어둔다.
잠깐의 휴식을 가진뒤에 다시 처음부터 우선순위 먹이고... etc etc..

암튼 UML은 이중에서 분석설계서 및 테스트 계획서에 사용됨.
빌드 테스트 결과는 HUDSON을 활용하자.

출처 : http://wolfpack.pe.kr/i/entry/601

FP 견적방법

JaeSoo — Thu, 27 Mar 2014 18:52:53 +0000

**********************
중요 : 아래 글중 EQ와 EO의 개념이 사실과 다르게 적혀 있습니다.
EQ는 로직을 타지 않고 그대로 출력하는 기능이며,
EO는 로직으로 가공된 채로 출력하는 기능입니다.
이점 착오 없으시기 바랍니다.
지적해주신 dh님께 감사드립니다.
참고 링크 : http://www.hilgroup.com/fp_pmvs/jsp/sh ··· 1_01.htm

**********************

Funtion Point 견적서는 2010년 5월부터 지경부 고시로 의무화된다.
기존에 M/M 즉, Head Count 방식은 사라지게 되는것이다.
(물론 공공기관의 이야기다. 민간기업은 ... 에효...)

아무튼 Funtion Point 즉, 기능점수 어떻게 견적을 내야하는지에 대해 Sample Xls 파일하고 같이 떠들어 보고자 한다.

1. 먼저 만들고자 하는 시스템 기능에 대해 목록화해야 한다.
기능의 정의는 다음과 같다.
먼저 데이터와 트랜젝션을 이해해야 한다.
데이터는 그야말로 시스템에 저장된 데이터이며 트랜젝션은 시스템 내외부로 세션이 왔다 갔다 하는것이다.

데이터는 EI, EO, EQ가 있으며
EI는 유저가 시스템의 데이터를 입력하는 것이다.
EO는 유저가 시스템으로 부터 데이터를 받는 것이다.
EQ는 유저가 시스템에 데이터를 입력하여 그 결과를 받는 것이다.
다시말해
EI는 일반적으로 입력, 수정, 삭제 행위이고 EO는 출력기능, EQ는 조회기능이다.

여기서 하나더 나가면 트랜젝션이라는 항목이 있고 시스템 내부라면 ILF, 외부시스템연계라면 EIF로 표현한다.

복잡하지만 쉬우니 한번 봐보도록 하자.
식별할때 유념할 사항은 UML USECASE 식별할때와 유사하니 흟어 보자.
첫째, 자기완결적이어야 한다.
둘째, 유저입장이어야 한다.

또 필요한 사전지식이 바로 지경부에서 2010년 2월 26일에 고시한 지식경제부 고시 제 2010-52호이다.
여기에는 간이 기능점수표라는 것이 포함되어 있는데 다음과 같다.

어차피 SAMPLE에 포함되어 있으니 그려러니 하자.
이제 샘플파일가지고 실습한번 해보자.

보안관련 요구사항이 7개있는데 이걸 표현하면 다음과 같다. (물론 요건이 7개라는 이야기다)

- 로그인은 "내부논리"를 읽는 것으로 "조회" 1개 밖에 없다.
즉, ILF 1개, EQ가 1개이므로 로그인의 FP=7.5X1 + 3.9X1="11.4"이다.
물론 정석으로하면 더 복잡하지만 화면 UI가 안나온 상황에서는 예측에 의한 간이법을 사용하는 것이다.

2. 이제 개발원가를 산정하자.
- 먼저 규모보정 계수를 산정하자. 목록의 총합계가 300FP를 넘는가가 관건인데 안넘는다면 0.65를 적용하고 300FP이상이라면 0.108*log e(FP)+0.2229 를 한다.

- 어플리케이션 유형에 대한 보정을 산정하자.
샘플에서는 일반적인 업무 처리용 S/W이므로 업무처리용에 100%.

합계는 반드시 100%여야 한다.
- 그리고 언어보정계수를 산정하자.
여기서는 웹을 가정하므로 보정계수 0.8에다가 100%~

- 마지막으로 품질/특성 보정계수를 입력한다.
각각의 상황에 맞는 특성을 입력하면 모든 작업이 끝난다.

이제 SAMPLE의 개발원가 산출란을 확인하면 지경부고시에 따른 분석, 설계, 구현, 시험 비용에 의거해 자동 개발원가가 산출된다.

예를 들어 분석 개발원가는 "94511*79.3*0.8*1.0*0.65*1.125"로 "4,384,412원"이다.
그래서 총합이 "23,075,885"원인것이다.
여기에 총괄표에서 보는바와 같이 최고 25%에 이윤을 붙일수 있다.

3. 직접경비를 산출하자.
직접경비는 다음으로 정의된다.
- 필요 컴퓨터 시스템 사용료
- 소프트웨어 도구 사용료
- 선투자 후정산 사업으로 추진되는 사업의 지급이자
- 발주자 요구에 의한 특정기술 도입과 관련된 전문가 비용
- 여비
- 특수자료비
- 인쇄, 청사진비
- 자료조사비
- 기자재시험비
- 위탁비와 현장 운영비 (보조요원의 급여와 현장사무질 임차료 및 운영비)
- 모형제작비
- 기타 당 소프트웨어 사업에 특별히 소요되는 직접비용 일체

여기까지 산출되고나면 최종 견적을 산정되는데
최종 견적가 = 개발원가 + 개발원가의 최대 25%까지의 이익 + 직접비용
이다.

여기서 또 Nego하겠지만...
혹시나 FP때문에 견적 못내고 계신 개발자 분들이 계신다면 참고하시기 바랍니다.

2010년기준 FP SAMPLE.zip

소프트웨어사업_대가의_기준(지식경제부고시_제2010-52호).zip

출처 : http://www.wolfpack.pe.kr/445

기능점수(FP,Function point) 관련 정의 및 비용산정

JaeSoo — Thu, 27 Mar 2014 18:47:48 +0000

Function Point를 활용한 소프트웨어 비용산정

프로젝트 데이터베이스 축적해 효율성 확보가 목적

임호진|동양종합금융증권 과장

우리는 소프트웨어의 적절한 비용을 알기 위해 많은 노력을 해 오고 있다. 하지만 소프트웨어를 비용으로 추정하는 데에는 많은 어려움이 있다. 그것은 소프트웨어는 일반 하드웨어와는 다르게 비가시성, 변경, 비마모성, 복잡성 등의 특징을 가지고 있고 이러한 특징은 비용예측을 어렵게 만드는 요인이기도 하다.

기존에는 소프트웨어의 비용산정시에 간단하게 비용을 계산 할 수 있는 LOC(Line Of Code)방식이 사용됐다. 하지만 LOC는 소프트웨어의 비용을 산정할 때 ‘양’적인 측면만을 강조하고 ‘기능’적인 측면의 비용산정에는 문제가 발생한다.

이러한 LOC의 문제점을 해결하고 사용자 관점의 기능과 양을 고려한 비용산정 기법이 바로 Function Point이다. 지금부터 Function Point의 산정절차에 대해서 자세히 알아보자.

측정유형 결정

Function Point는 비용을 산정하기 전에 개발 프로젝트, 개선 프로젝트, 애플리케이션이라는 3가지 유형으로 분류한다. 즉, Function Point의 첫번째 단계는 이러한 세가지 유형 중 하나를 결정하는 단계이다.

측정범위와 애플리케이션 경계식별

측정범위와 애플리케이션 경계식별은 현재 개발하고 있는 혹은 변경할 소프트웨어에 대한 전체범위를 결정하고 각 어플리케이션의 경계를 분류하는 과정이다.

- ILF(Internal Logical File): 어플리케이션 경계 내에서 유지되는 데이터 및 제어정보
- EIF(External Interface File): 어플리케이션 경계 밖에서 유지되는 데이터 및 제어정보

데이터 기능점수 산정

데이터 기능점수 산정은 먼저 앞에서 나온 ILF와 EIF를 식별하는 것이다. ILF와 EIF를 식별하면 각각 복잡도와 기여도를 결정하여 데이터 기능점수를 도출한다. 먼저 복잡도 산정 방법은 DET(Data Element Type)과 RET(Record Element Type)을 통해서 이루어진다. DET는 ILF나 EIF에 유지되는 필드 중에서 사용자가 식별 가능하고 비반복적인 필드를 의미하고 RET는 DET의 서브 셋을 의미한다. 이 둘을 식별하고 개수를 파악하는 것이다.

DET와 RET를 계산 후에 이것을 기여도 테이블로 변환해서 최종 데이터 기능점수를 계산한다.

	1~19 DET	20~50 DET	51이상 DET
1 RET	낮음	낮음	보통
2~5 RET	낮음	보통	높음
6이상 RET	보통	높음	높음

	ILF 미 조정 기능점수	EIF 미 조정 기능점수
낮음	7	5
보통	10	7
높음	15	10

트랜잭션 기능점수

트랜잭션 기능점수는 사용자가 식별 할 수 있고 최소한의 업무를 처리 할 수 있는 단위 프로세스를 식별하고 각 단위 프로세스 별로 EI/EO/EQ로 분류한 다음 복잡도와 기여도를 계산하여 트랜잭션 기능 점수를 계산한다.

EI/EO/EQ의 단위 프로세스가 식별되면 DET와 FTR(File Transfer Reference)를 통하여 복잡도를 계산한다. DET는 앞에서 이야기 한 것 처럼 반복되지 않고 사용자가 식별 가능한 필드이고 FTR은 어플리케이션에서 참조하는 ILF나 EIF의 수를 의미한다.

EI/EO/EQ 별로 DET와 FTR이 계산 되었으면 복잡도와 기여도를 계산하면 된다.

EI의 FTR/DET	1~4 DET	5~15 DET	16이상 DET
0~1 FTR	낮음	낮음	보통
2 FTR	낮음	보통	높음
3이상 FTR	보통	높음	높음

EI(External Input)	ㆍ 애플리케이션 경계 밖에서 경계 안으로 들어오는 데이터나 제어정보를 처리하는 단위 프로세스
EO(External Output)	ㆍ 애플리케이션 경계 밖으로 조회되는 것으로 파생 데이터 생성과 같은 처리로직을 포함하는 단위 프로세스
EQ(External Inquiry)	ㆍEO와 같으나 파생 데이터 생성과 같은 처리로직을 포함하지 않는 단위 프로세스

	EI/EQ	EO
낮음	3	4
보통	4	5
높음	6	7

미조정 기능점수의 결정

미조정 기능점수는 데이터 기능점수와 트랜잭션 기능점수의 합으로 계산된다.

조정인자 결정

Function Point는 14개의 조정인자를 가지고 있다. 이러한 14개의 조정인가는 0~5까지의 영향도로 이루어지며 이것은 미조정 기능점수 값을 35% 조정 할 수가 있다.

[조정인자]

1. 데이터 통신 (Data Communication)

2. 분산 데이터 처리 (Distributed Data Processing)

3. 시스템 성능 (System Performance)

4. 자원 제약 정도 (Heavily Used Configuration)

5. 트랜잭션 비율 (Transaction Rate)

6. 온라인 데이터 비율 (On-Line Data Entry)

7. 최종 사용자 효율성 (End-User Efficiency)

8. 온라인 갱신 (On-Line Update)

9. 처리 복잡도 (Complex Processing)

10. 재사용성 (Reusability)

11. 설치용이성 (Installation Ease)

12. 운영용이성 (Operational Ease)

13. 다중 설치성 (Multiple Sites)

14. 변경 용이성 (Facilitate Change)

조정 기능점수 결정

조정인가 값이 결정되면 개발, 개선, 어플리케이션의 유형에 따라 조정인자를 반영하여 최종 Function Point 값을 계산하게 된다.

애플리케이션 기능점수 = 미조정 기능점수 * 조정값

이렇게 Function Point를 통해서 소프트웨어의 비용을 계산 할 수가 있다. 지금까지 알아본 방식은 이미 요구분석과 설계가 끝난 다음에 비용을 산정하는 상세법 이다. 하지만 소프트웨어 개발 제안단계에서는 이러한 방법을 통해서 소프트웨어의 비용을 추정 할 수가 없을 것이다. 이러한 경우는 통계적인 데이터를 활용하여(평균값) 소프트웨어 비용을 추정한다. 이러한 방법을 기안법이라고 한다.

지금까지 수학적 소프트웨어 비용산정인 Function Point에 대해서 알아보았다. 실제로 많이 쓰이고 있으므로 기본 개념과 경험을 확실히 알 필요가 있을 것이다. 또한 기안법을 활용하기 위해서는 과거 프로젝트에 대한 정보가 축척 되어 있어야 한다. 그러므로 프로젝트 종료 후에 프로젝트에 대한 경험적 교훈이 무엇보다 형식지로 표현된 데이터베이스에 축척 돼야 한다.

제공 : DB포탈사이트 DBguide.net

출처명 : 경영과컴퓨터 [2006년 1월]

Posted by 시나위

출처 : http://develop1004.tistory.com/entry/%ED%8E%8CFunction-point-%EA%B4%80%EB%A0%A8-%EC%A0%95%EC%9D%98-%EB%B0%8F-%EB%B9%84%EC%9A%A9%EC%82%B0%EC%A0%95-1

기능점수 활용 프로젝트 추정과 계획 – 4.프로젝트 추정 및 진척관리 간이법

JaeSoo — Wed, 26 Mar 2014 18:05:47 +0000

프로젝트의 추정/계획과 진척관리에 기능점수를 활용하는 것은 기능의 일관성있는 규모에 대한 계획의 수립과 관리를 가능하게 한다. 하지만 복잡한 수치로 나타나는 기능점수(소수점이 있는)를 이용하여 점수를 부여하고 진척관리에 사용하는 것은 매우 번거럽고 어려운 작업이 될 수 있다.

이를 보완하기 위하여 점수를 간략화하여 진척관리에 활용하는 방법을 사용하면 좀 더 편하게 작업이 가능하다.

이는 기능의 유형에 따른 일반적인 기능점수의 비율을 이용하여 정수의 배수 들로 구성된 일련의 값을 기능점수 대신사용하는 것인데, 아래와 같이 대표적인 기능 들의 기능점수 비율이 정수의 배수로 나타남을 알 수 있으며, 이를 기능점수 대신 사용가능하다.

기능	세부기능	기능점수	비율(4로 나눔)
일반조회	단순조회	3.9	1.0
통계조회	통계조회, 인쇄	9.1	2.3
입력	단순입력	4	1.0
관리	입력,수정,삭제,조회	15.9	4.0

즉, 약간의 오차를 무시하면 1, 2, 4 의 값을 사용할 수 있다. 따라서, 각 기능의 점수를 1, 2, 4 중 하나의 값으로 설정하고 관리한다.

기능	세부기능	추정점수
일반조회	단순조회	1
통계조회	통계조회, 인쇄	2
입력	단순입력	1
관리	입력,수정,삭제,조회	4

이는 각 기능의 규모 차이를 가장 작은 기능을 1로 보고, 그 규모의 차이를 대략 추정하여 점수를 부여하는 방식이며, 점수는 쉬운 비교를 위하여 배수로 증가하는 것이 좋다.

일반적으로 1, 2, 4, 8의 4가지 점수를 사용한다.

참고

사실 이 방식은 User Story의 규모추정에 사용되는 Story 점수 추정법이다. 나는 기능점수를 도입하기 전, 이미 1, 2, 4, 8 방식의 Story 추정점수 방법을 사용해왔는데, 우연히 이 비율이 기능점수에서도 거의 일치함을 발견하였다. User Story의 추정점수는 개발자가 직관적으로 임의의 점수를 부여하는 방식이라, 프로젝트 간 점수부여 방식에서 차이가 발생할 수 있어서, 사내의 성과 기준 점수로 사용하기는 힘드므로, 이 기능점수간의 비율에 대한 기준으로 사내 모든 프로젝트의 추정점수를 부여하도록 하였다.

이 방법을 사용하면, 기능점수를 측정하지 않은 프로젝트에서도 개발계획을 수립할 때 빠르게 규모를 추정하여 개발계획을 수립할 수 있으며, 그 결과에 4를 곱하면 대략적인 기능점수로의 변환도 가능하다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ed%99%9c%ec%9a%a9-%ed%94%84%eb%a1%9c%ec%a0%9d%ed%8a%b8-%ec%b6%94%ec%a0%95%ea%b3%bc-%ea%b3%84%ed%9a%8d-4-%ed%94%84%eb%a1%9c%ec%a0%9d%ed%8a%b8-%ec%b6%94%ec%a0%95/

기능점수 활용 프로젝트 추정과 계획 – 3.기능점수에 의한 일정계획 및 진척관리 예시

JaeSoo — Wed, 26 Mar 2014 18:05:15 +0000

앞에서 설명한 기능점수에 의한 추정과 계획/관리 기법을 예를 들어 설명한다.

기능점수 산출

먼저 개발할 기능의 기능점수를 산출한다. 그 결과 아래와 같이 기능점수가 산출되었다고 가정하자.

기능명		EI			EO	EQ	ILF	EIF
기능명		입력	수정	삭제	EO	EQ	ILF	EIF
결재요청	결재문서작성	1					결재문서
	결재선입력	1					결재선
?	결재양식선택	?	?	?	?	1	결재양식	?
	결재선검색					1	사용자
결재처리	결재문서목록조회	?	?	?	?	1	결재문서	?
?	결재문서조회	?	?	?	?	1	결재문서	?
?	결재처리	?	1	?	?	?	결재문서	?
?	결재상태조회	?	?	?	?	1	결재문서	?
?	결재문서출력	?	?	?	?	2	결재문서	?
정보관리	사용자관리	1	1	1	?	2	사용자	?
?	부서관리	1	1	1	?	2	부서	?
?	결재양식관리	1	1	1	?	2	결재양식	?
?	월별결재통계	?	?	?	1	?	결재문서	?

이를 정리하여 실제 구현할 트랜잭션 기능의 점수만을 산출하면 아래와 같다.

기능명		EI	EO	EQ
결재요청	결재문서작성	1
	결재선입력	1
?	결재양식선택	?	?	1
	결재선검색			1
결재처리	결재문서목록조회	?	?	1
?	결재문서조회	?	?	1
?	결재처리	1	?	?
?	결재상태조회	?	?	1
?	결재문서출력	?	?	2
정보관리	사용자관리	3	?	2
?	부서관리	3	?	2
?	결재양식관리	3	?	2
?	월별결재통계	?	1	?
합계		12	1	13

즉, 이를 기능점수로 계산하면 아래와 같다.

기능유형	평균복잡도			합 계
외부입력(EI)	12	×	4.0	48.0
외부출력(EO)	1	×	5.2	5.2
외부조회(EQ)	13	×	3.9	50.7
총 기능점수				103.9

즉, 개발계획을 수립해야할 기능의 총 기능점수는 103.9점이다.

프로젝트 투입자원 산출

위 기능을 구현하는데 총 4주가 주어졌다고 하자. 계산을 쉽게 하기 위하여 모든 개발자는 개발속도가 10점/Week 라고 가정한다면,

적정 개발인력 = 103.9 / (4주 * 10) = 2.6

이 된다. 따라서, 개발인력을 3명을 투입하기로 한다.

프로젝트 주기계획수립

프로젝트 기간은 총 4주가 주어졌으므로, 4주간의 주기계획을 수립한다. 개발보고는 주로 주단위로 하게 되므로, 각 주기를 1주로 잡고, 각 주기의 일정을 작성한다.

개발주기	시작일	완료일
주기1	2012-08-27	2012-08-31
주기2	2012-09-03	2012-09-07
주기3	2012-09-10	2012-09-14
주기4	2012-09-17	2012-09-21

개발계획 수립

주기와 투입인력이 정해졌다면, 기능점수를 산출한 각 기능에 대하여 개발계획을 작성한다. 이 때, 개발할 주기와 담당자 등을 모두 지정하여 계획을 수립한다.

기능		개발계획			개발관리
기능		우선순위	기능점수	개발주기	담당자	상태
결재요청	결재문서작성	2	4.0	주기3	개발자1
	결재선입력	2	4.0	주기3	개발자1
	결재양식선택	2	3.9	주기3	개발자2
	결재선검색	2	3.9	주기3	개발자2
결재처리	결재문서목록조회	3	3.9	주기3	개발자3
	결재문서조회	3	3.9	주기3	개발자3
	결재처리	3	4.0	주기4	개발자1
	결재상태조회	4	3.9	주기4	개발자1
	결재문서출력	4	7.8	주기4	개발자2
정보관리	사용자관리	1	19.8	주기1, 주기2	개발자1
	부서관리	1	19.8	주기1, 주기2	개발자2
	결재양식관리	1	19.8	주기1, 주기2	개발자3
	월별결재통계	4	5.2	주기4	개발자3

개발주기검증

각 개발주기별로 적정한 개발분량이 분배되었는지를 검증할 필요가 있다. 앞에서 작성한 개발계획을 이용하여 각 주기별 기능점수를 계산하여 검증한다.

개발주기	기능		개발관리			총포인트
개발주기	기능		기능점수	담당자	상태	총포인트
주기1,2	정보관리	사용자관리	19.8	개발자1		59.4 (29.7)
		부서관리	19.8	개발자2
		결재양식관리	19.8	개발자3
주기3	결재요청	결재문서작성	4.0	개발자1		23.6
		결재선입력	4.0	개발자1
		결재양식선택	3.9	개발자2
		결재선검색	3.9	개발자2
	결재처리	결재문서목록조회	3.9	개발자3
		결재문서조회	3.9	개발자3
주기4		결재처리	4.0	개발자1
		결재상태조회	3.9	개발자1		20.9
		결재문서출력	7.8	개발자2
	정보관리	월별결재통계	5.2	개발자3

위 표에서 각 주기별로 균등하지만 않지만, 대략 비슷하게 점수가 배분되었으므로 이에 따라 진행하는 것으로 결정한다.

인력할당계획 검증

주기에 대한 적정성이 검증되었다면 각 개발자의 업무부하의 적정성을 검증한다. 앞의 주기검증과 마찬가지로 개발계획을 다시 각 개발자별로 분류하여 개발자당 개발 기능점수를 산출한다.

담당자	총포인트	개발주기별 포인트
담당자	총포인트	주기1	주기2	주기3	주기4
개발자1	35.7	9.9	9.9	8	7.9
개발자2	35.4	9.9	9.9	7.8	7.8
개발자3	32.8	9.9	9.9	7.8	5.2
총계		29.7	29.7	23.6	20.9

이 역시 검증 결과, 각 개발자 별로 거의 비슷한 점수를 개발하므로, 적정하다고 판단한다.

진척관리

적정한 일정 및 인력계획을 수립했으므로, 계획대로 프로젝트를 진행한다. 구현단계에서 실제 개발 진척도의 관리는 이미 수립한 개발계획을 기반으로 개발주기별로 완료한 점수를 체크하여 관리한다.

총 기능점수	103.9

개발주기	기능점수	번다운계획	실완료포인트	실제번다운	진척도
시작	0	103.9	0	103.9	0%
주기1	29.7	74.2	28	75.9	27%
주기2	29.7	44.5	25	50.9	51%
주기3	23.6	20.9	15	35.9	65%
주기4	20.9	0	35.9	0	100%

번다운은 완료한 기능을 기준으로 하는 것이 아니라 남은 기능, 즉, 앞으로 개발을 해야 하는 기능을 기준으로 산출된다. 즉, 시각적으로 얼마나 많은 일이 남아 있는지를 표현하므로 프로젝트의 진행상황을 파악하기에 매우 용이하다. 위 표를 이용하여 번다운 차트를 작성하여 아래와 같이 표시할 수 있다.

위와 같이 계획과 실진척을 하나의 그래프로 표현하여 진척상황을 쉽게 파악할 수 있다. Agile 측에서는 이와 같은 시각적인 차트를 잘보이는 곳에 출력하여 게시할 것을 권장하고 있다. 실제로 진척상황을 개발팀이 항상 보이는 곳에 게시하면 진척에 대한 자극제 역할을 할 수 있다.

성과관리

진척관리를 할 때, 주기별 진척도만을 관리할 수도 있지만, 앞에서 설명한 바와 같이 각 개발자의 평균 개발속도를 산출하거나, 각 개발자의 프로젝트 기여도에 따른 성과 및 보상을 하려는 경우, 각 개인별로 개발한 기능점수를 관리하는 것이 좋다.

프로젝트를 수행하다보면 일반적으로 계획과 실제 개발이 다르게 진행될 때가 많다. 개발담당자도 각 개발자의 개발속도 차이에 의하여 실제로 계획과 다른 개발자가 개발할 수도 있으므로, 각 주기별로 실제 기능별 개발자를 기록하여 프로젝트 종료시 전체 개발성과를 산출한다. 이 데이터를 지속적으로 관리하여 각 개발자의 평균개발속도의 정확도를 높일 수 있다. 또한 각 개발자의 개발기여도를 산출하여 성과에 반영할 수도 있다.

담당자	계획기능점수	개발기능점수	개발기간㈜	평균 개발속도
개발자 1	35.7	39.7	4	9.9
개발자 2	35.4	31.4	4	7.9
개발자 3	32.8	32.8	4

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ed%99%9c%ec%9a%a9-%ed%94%84%eb%a1%9c%ec%a0%9d%ed%8a%b8-%ec%b6%94%ec%a0%95%ea%b3%bc-%ea%b3%84%ed%9a%8d-3-%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98%ec%97%90-%ec%9d%98/

기능점수 활용 프로젝트 추정과 계획 – 2.기능점수에 의한 프로젝트 계획과 진척관리

JaeSoo — Wed, 26 Mar 2014 18:04:16 +0000

앞에서 기능점수를 활용하여 프로젝트의 추정을 하는 기법을 배웠다. 이를 기초로 기능점수를 프로젝트의 계획과 그 관리에도 활용할 수 있다.

프로젝트 추정에서의 질문과 마찬가지로, 구현단계에서의 일정계획을 어떻게 수립하는가? 에 대한 질문에 어떻게 대답하겠는가?

대다수의 개발팀은 개발일정계획을 그리 세밀하게 수립하지 못하며, 그 진척관리 또한 명확하게 관리하지 못한다. 또한 대부분의 프로젝트는 WBS라는 Work 기반의 일정계획을 수립하고 있으며, 프로젝트에서 가장 많은 기간을 차지하는 구현단계는 WBS 상에서 몇줄의 일정으로 표현될 뿐이다.

또한 진척도의 보고시 진척도를 산출하는 기준 또한 매우 모호하게 표현된다. 대부분의 프로젝트관리자는 WBS상의 활동이 수행되었는가를 보고 진척도를 산출한다. 하지만, 실제 개발 과정에서 “어떤 활동을 수행했는가”는 실제 “구현이 얼마나 진행되었는가”에 대한 답을 주지는 못한다.

구현에서의 가치는 활동의 수행이 아니라 실제 기능의 완료에 있기 때문이다. 활동의 결과는 “고객의 가치(기능)”가 얼마나 실현되었는지를 전혀 측정할 수 없으며, 이는 개발프로세스에서 관리할 필요가 없음을 의미한다.

(무슨 활동을 얼마나 했는가는 실제 프로젝트를 얼마나 수행하였는지에 대한 척도가 될 수 없다. 또한 활동을 얼마나 했는지는 측정할 수도 없다.)

이전의 WBS방식의 진척도 산출은 활동의 수를 정하고 활동을 완료한 개수로 진척도를 정하는 방식이었다. 사실 이 방식은? “개발의 진척”의 의미로 사용하기에는 무리가 있다. 활동의 완료라는 것은 실제 개발의 진척도와는 무관하기 때문이다.

(WBS에 의한 진척을 보고받아본적이 있는가? 프로젝트가 시작되기도 전에 수립된 WBS 계획과 프로젝트 진행시의 진척은 거의 일치한다. 이 것은 둘중 하나다. 계획수립을 한 사람이 “예언자”이던지, 계획에 결과를 의도적으로 일치시켰던지)

현대적인 개발분야의 전반적인 패러다임은 “기능” 중심으로 전환되고 있다. 지금 설명하고 있는 기능점수와 관련된 일련의 교육자료 또한 이 “기능”중심의 개발사상을 그 기반으로 하고 있다.

즉, 진척도는 고객이 요구한 기능이 얼마나 완료되었는가에 의하여 산출되어야 하며, 이는 업무의 수행여부와는 별개이다. 따라서 구현단계에서의 진척은 반드시 “기능의 구현완료”로 측정되어야 하며, 이는 기능점수를 기준으로 측정할 수 있다.

참고

파킨슨 법칙 : 일의 양은 주어진 시간에 따라 늘어난다.

활동단위의 업무지시는 활동 자체를 줄이거나, 활동을 의도적으로 늘리는 결과를 가져온다.

즉, 실제 업무의 완료여부와 관계없이, 활동에 주어진 일정이 되면 끝나버린다.

거꾸로, 실제 업무가 완료되었더라도, 일정이 끝나지 않은 경우, 해당 업무는 완료계획일까지 지속된다.

최근 들어 소프트웨어의 대가기준은 이전의 인건비방식(활동을 한 사람에 대한 대가)에서 기능점수방식(소프트웨어의 기능의 규모)로 변경되었다. 이는 “가치”의 기준이, 더 이상 의미 없는 활동을 기준으로 하는 것이 아니라 실제 “실현한 가치”를 중심으로 이동하였음을 의미하는 것으로 소프트웨어 분야의 특성을 반영하고자 하는 노력의 결과이다.

즉, 이것은 소프트웨어 회사의 대가에만 국한된 것이 아니라, 모든 가치 기준을 “기능?가치”를 기준으로 관리하여야 함을 의미한다.

(소프트웨어 개발이 활동 및 활동에 투입된 자원의 양으로 결정되지 않음은 모두가 공감한다.)

소프트웨어 기업은 기능에 의하여 대가를 지불 받고 소프트웨어의 개발과정은 기능에 의하여 그 계획이 수립되어야 한다. 그래야만이 실제 대가에 대한 “실현결과”를 측정할 수 있다. 기존의 WBS는 소위 “머리수”에 의한 대가기준을 사용하던 시절에 적합하다.

이 개념은 그 소프트웨어 개발과정에 참가한 개발자의 성과 측정에도 그대로 적용된다.

이전의 활동에 대한 대가 ? 활동에 의한 계획 방식을 사용했을 경우, 그 성과는 “활동의 양”이 되어야 한다. (공수라고 불리우는) 즉, 기업의 이윤이 활동에 의하여 분해되고 그 분해된 활동에 투입된 성과(시간)에 의하여 분배되는 것이다.

하지만 기능에 의하여 대가가 산정되고, 기능에 의하여 계획이 수립된 경우, 그 성과는 개발자가 개발한 “기능의 수”가 된다.

위에서 설명한 바와 같이, 일정계획의 수립과 수립된 계획에 의한 진척도 측정에 기능점수를 활용할 수 있다. 기능점수는 이미 고객의 요구사항이 “단위기능”으로 분해되어 있으며, 각각의 기능의 “규모”또한 점수로 표현되어 있다. 즉, 기능점수는 개발의 양으로 볼 수 있으므로 이 양을 각 개발일정단위에 분배하고, 실제 개발된 양을 측정하여 객관적인 진척도를 수치로 표현가능하다.

기능점수를 일정에 분배하고, 완료된 기능점수를 측정하여 진척을 관리한다.

즉, 프로젝트 추정에 의하여 산출된 일정과 투입자원을 기능점수에 의하여 각 개발주기에 분배한다. 개발주기는 개발일정에 따라 적절히 분할하여 수립하고, 각 개발인력의 개발속도를 고려하여 주당 개발 기능점수를 판단하여 배분한다.

[개발주기계획]

개발주기	시작일	종료일
1주기	2012-08-27	2012-08-31
2주기	2012-09-03	2012-09-07
3주기	2012-09-10	2012-09-14

[자원계획]

개발자	개발속도
개발자1	10.0
개발자2	9.5

[개발계획]

기능	기능점수	담당자	개발주기	기능점수합계
기능1	10.0	개발자1	1주기	34.4
기능2	3.9	개발자1	1주기
기능3	4.9	개발자2	1주기
기능4	15.6	개발자2	1주기

위와 같이 그 규모가 측정된 각 기능에 대하여 기능별로 개발담당자와 개발일정을 지정하면, 어떤 개발자에게 또는 어떤 주기에 부하가 많은가를 미리 검토할 수 있고, 검토 결과에 의하여 개발계획을 보정할 수 있다. 또한 수치에 의한 명확한 일정별 개발범위가 결정되어, 실제 구현결과를 측정함으로써 계획대비 실제 진척율을 매우 객관적으로 측정하여 산출할 수 있게 된다.

즉, 실제 가치 있는 기능의 완료를 기반으로 계획을 수립하고, 그 진척도를 측정할 수 있다. 또한 이 기능점수는 실제 개발원가로 바로 환산되므로, 실제 완료된 진척을 돈으로 측정할 수도 있다.

이러한 방식을 사용할 경우, 구현의 진척도는 “완료”만을 기준으로 삼는다. 일부완료는 고려하지 않으며 반드시 “구현완료”된 기능을 측정하는 것이 좋다. 또한 계획대비진척을 Agile에서 즐겨 쓰는 번다운 차트를 이용하여 표현하면, 시각적으로 프로젝트의 진척도와 위험도를 쉽게 확인할 수 있다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ed%99%9c%ec%9a%a9-%ed%94%84%eb%a1%9c%ec%a0%9d%ed%8a%b8-%ec%b6%94%ec%a0%95%ea%b3%bc-%ea%b3%84%ed%9a%8d-2-%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98%ec%97%90-%ec%9d%98/

기능점수 활용 프로젝트 추정과 계획 – 1.기능점수에 의한 프로젝트 추정

JaeSoo — Wed, 26 Mar 2014 17:59:40 +0000

개발자로서 관리자로서 오랜기간 프로젝트를 수행했지만 프로젝트 초기에 항상 곤란을 겪는 분야가 있다.

바로 프로젝트를 제대로 수행하기 위해서 얼마의 자원을 투입하여야 하고, 일정계획을 어떻게 수립해야 하는가? 에 관한 문제이다.

여러분은,

이 기능을 개발하는데 며칠이 걸리는가?

에 대한 질문에 어떻게 답을 내고 있는가?

아마도, 대부분의 개발자는 지난 프로젝트의 경험에 비추어 대략 몇 명이 몇주 정도 하면 될 것 같다는 식으로 대답을 할 것이고 이에 따라 프로젝트의 추정과 계획수립이 이루어 질 것이다.

하지만 이러한 “경험에 의한 추정”방식은 매우 큰 오차를 가진다.

참고 ?불확실성 원추 (배리 뵘 ? 1981년)

“프로젝트 초기에서의 일정추정치는 실제일정 대비 60%에서 160% 정도의 값을 가진다.”

“요구사항분석이 완료한 시점에서의 추정치 오차는 +- 15% 정도이다.”

우리는 프로젝트의 위험을 줄이기 위하여 보다 정확한 일정추정치를 계산할 수 있어야 한다. 하지만 일정을 추정하는 작업은 개발자 스스로도 과학적인 접근을 할 시도를 거의 하지 않고, 소프트웨어 개발 회사도 개발자에게 맡길 뿐, 크게 개선할려는 노력을 기울지이 않는 분야 인 것 같다.

그렇다면, 일정을 과학적으로 추정할 방법은 없는가?

위의 질문을 우리가 평소에 과학적으로 쉽게 추정치를 계산할 수 있는 다른 질문으로 바꾸어 보자.

대구에서 서울까지 자동차로 가는데 얼마의 시간이 걸리는가?

이 문제는 쉽게 풀 수 있을 것이다. 대구에서 서울까지의 소요시간 추정을 하기 위해서는 어떠한 값을 알아야 하는가? 아래의 값을 알면 바로 해답이 나올 것이다.

대구에서 서울까지의 거리

자동차의 평균 속도

즉, 추정을 위한 규모(거리)와 평균적인 속도를 알면, 규모의 종료를 위한 추정(시간)이 산출될 것이며, 거리는 고정이므로 평균속도 값이 정확하면 정확할수록 보다 정확한 추정치를 얻게 된다.

다시 원래의 문제로 돌아가보자. 위의 이동시간 문제를 비추어 볼 때,? 개발의 일정추정을 위하여 어떠한 값을 알아야 하는가? 그것은 바로 “개발규모”와 “평균개발속도”이다.

개발의 일정 추정을 위해서는 “개발규모”와 개발자의 “평균개발속도”가 필요하다.

개발규모

프로젝트의 규모는 무엇으로 측정하는가? 개발규모라는 것은 개발자의 능력, 개발프레임워크, 개발성향 등 외부적인 요인으로 크게 달라질 수 있다. 즉, 객관적으로 그 규모를 정의할 수 있는 단위가 필요하다.

즉, 개발환경적인 요소를 배제하고, 그 크기를 대구에서 서울까지의 거리와 같이 객관적인 규모로 정의할 수 있는 단위가 필요한데, 이것이 바로 기능점수이다.

기능점수는 개발의 규모를 객관적인 수치로 표현한다.

즉, 개발규모는 기능점수를 산출하여 측정할 수 있다.

기능점수는 사용자의 요구기능을 객관적 수치로 점수화하여 표현한다. 즉, 프로젝트의 전체 기능을 통하여 전체 기능점수를 산출하면, 우리가 프로젝트에서 개발해야 할 전체 규모가 된다.

우리는 기능점수를 산출할 수 있으므로, 이미 일정추정을 할 준비가 되어 있다. 그리고 이 기능점수를 이용하여 보다 과학적이고 정확한 규모를 산출하고 일정을 추정할 수 있다.

참고

Agile을 공부한 분이라면 “User Story”란 용어를 들어보았을 것이다. 이 User Story는 어떻게 보면 “사용자요구사항”또는 “Usecase”와 비슷한 개념인데, Agile에서는 이 User Story를 이용한 프로젝트 추정/계획 기법이 있다. 자세한 내용은 아래의 책을 참고하기 바란다.

불확실성과 화해하는 프로젝트 추정과 계획 (Agile Estimating and Planning)

인사이트, 마이크 콘

이 책에서 설명하는 프로젝트 추정기법과 이 글에서 설명하는 기능점수를 이용한 프로젝트 추정기법은 거의 유사하다. 단지, User Story 점수를 기능점수로 대체한 것 뿐이다.

User Story 점수는 개발구성원이 각 User Story에 난이도나 규모에 따라 직관적으로 임의의 점수를 부여하는 것이다. 그리고 이렇게 측정된 User Story 점수를 기반으로 일정 추정을 하게 된다.

이는 개발자의 경험과 직관에 의하여 점수를 임의로 부여하므로 매우 빠르게 전체 점수를 산출할 수 있지만, 점수를 부여하는 구성원에 따라 달라질 수 있고, 상당한 개발경험을 요구하게 된다. 이러한 방식이 나쁜 것은 아니다. 나도 이 방식에 의하여 프로젝트 추정을 많이 하고 있다. 하지만, 소프트웨어 개발회사 전반에 걸친 객관적인 규모산정에는 무리가 따르며, 국내 SI의 현실에 잘 맞지 않을 수도 있다.

사실, 이 글에서 설명하고자 하는 프로젝트 추정기법은 이 User Story에 의한 프로젝트 추정법에서 아이디어를 얻었고, 이를 응용하여 User Story 대신 보다 객관적인 점수를 산출하는 기능점수로 대체하였다.

평균개발속도

개발자의 개발속도는 어떻게 표현할 수 있을까?

이미 개발의 규모에 대한 단위(FP)가 결정되었으므로 개발자의 평균개발속도는 특정시간단위 당 개발규모단위로 표현된다. 즉, 시간단위당 개발기능점수가 개발속도가 된다.

개발속도 = 총개발기능점수 / 총개발시간

단위 : FP / Week (개발시간을 주로 표현한 경우)

그렇다면 프로젝트에 투입된 개발자의 평균개발속도는 어떻게 산출하는가? 그리고 각 개발자의 능력에 따라 개발속도가 모두 다른데 이는 어떻게 하는가?

대부분의 프로젝트는 다수의 개발자가 투입되어 수행하게 되므로, 정확한 개발속도의 산출을 위해서는 개개인의 개발속도를 알아야만 한다. 즉, 전체 그룹에 대한 개발속도는 산출하기도 힘들고, 산출되더라도 실제 일정추정에 적용하기에는 오차가 너무 크다. 따라서, 개발회사는 일정추정을 위해서는 개발자 개개인의 개발속도를 미리 측정하여야 한다.

이는 “평균값”이므로 당연히 기존 데이터가 존재하여야 하고, 이를 통계로 산출할 수 있어야 한다. 즉, 처음 기능점수에 의한 프로젝트 추정방법을 도입하는 경우, 이러한 통계값이 없으므로 바로 정확하게 적용하기는 힘들다. 초반에는 완전히 “추측치”를 사용하여 측정하여야하고, 이후 점차 기능점수에 의한 개발 데이터가 누적되면 그 정확도는 점점 올라가게 된다.

즉, 개발회사는 이후의 추정 정확도를 높이기위하여 각 개발자별 투입기간과 투입기간동안 실제 개발한 기능점수 데이터를 관리하여야 한다. 이 데이터가 지속적으로 관리되고 누적된다면, “평균개발속도”의 정확도는 올라가며 이는 곧 프로젝트 일정 추정의 정확도가 올라가는 결과를 가져온다.

개발자의 실적을 기능점수를 이용하여 누적관리하고 이를 통하여 평균개발속도를 얻는다.

각 개발자의 평균개발속도 자료가 충분히 없다면, 샘플기능을 추출하여 개별적으로 개발속도를 측정해서 사용할 수도 있다. 즉, 프로젝트 대상 기능중 일부를 실제 개발해보고 속도를 측정하여 사용하는것이다. 하지만 이방법은 프로젝트 추정기법 초기에만 활용하고 되도록 각 프로젝트 수행시 개발자의 실적을 관리하여 통계에 의하여 사용하는 것이 좋다.

프로젝트의 일정추정을 위하여 개발자의 실적을 기능점수로 관리하여야 한다는 것은 또다른 기능점수의 활용대상을 낳는데, “개발자의 성과관리”부문이다. 즉, 기능점수를 이용하여 성과를 수치로 측정한다는 것이다. 이는 추후 다시 설명하기로 한다.

프로젝트 추정

프로젝트의 기간과 기능점수가 산출되었다면 프로젝트 계획단계에서 일정계획, 자원투입계획을 프로젝트 추정에 의하여 미리 산출해볼 수 있다. 이미 프로젝트의 기간과 투입인력이 결정되어 있는 상태라면 이러한 조건을 모두 계산하여 프로젝트 일정계획과 자원계획의 적정성을 검증하거나 프로젝트 위험도를 예측해볼 수 있다.

예를 들어 프로젝트의 총 기능점수가 1000점인 경우, 실제 구현기간이 20주라면, 주당 개발속도(FP/week)는 50점이어야 한다. 만약 개발자 전원이 주당 개발속도가 10점이라면 이는 개발자를 5명 투입해야 한다는 결론이 나온다. 즉, 기능점수와 평균개발속도 데이터를 이용하여 적정 자원투입계획을 수립할 수 있다.

만약 이미 기간과 자원투입계획이 수립된 상태라면, 미리 프로젝트 일정상의 위험을 검사해볼 수 있다.

앞의 예에서, 투입자원 전체의 평균 개발속도가 8점이라면, 구현기간 동안 개발가능한 기능점수는 (8점 * 5명 * 20주), 800점이다. 즉, 200점이 기간 내에 개발이 되지 않을 것으로 추정된다. 이 경우, 200점을 개발할 추가 적인 인원을 산출하여 투입하던가 기간내에 기존 인원이 추가적인 작업으로 10점을 개발할 수 있도록 일정계획을 수립하여야 한다.

이와 같이 기능점수에 의한 프로젝트 추정 기법은 수치에 의하여 추정과 계획을 수립할 수 있도록 하여 보다 정확한 프로젝트 관리를 가능하게 해준다.

참고

많은 소프트웨어 개발 회사의 관리자는 프로젝트 수행시 무리한 일정계획을 요구하고, 보다 적은 투입인력을 원한다. SI 사업의 경우, 인건비와 시간을 줄이는 것이 수익을 늘려주므로 어쩔 수 없는 요구이긴 하지만 개발자 입장에서는 이는 곧 야근과 같은 무리한 업무량을 요구하는 것이므로 항상 불만이 커지게 된다.

또한 개발자 측에서 주장하는 “이 일정은 무리한 일정입니다.”또는 “이 인력으로는 무리입니다.”라는 얘기는 관리자에게 거의 받아들여지지 않는다. 이를 주장하기 위해서는 수치에 의하여 객관적인 근거자료가 있어야 하는데, 대부분 이것을 제시하지 못하기 때문이다. 따라서, 개발팀은 기능점수에 의한 프로젝트 추정법 같은 기법을 도입하여 그 근거를 제시할 수 있어야 하며, 과부하에 따른 보상을 요구하거나 과부하 상태임을 주장할 수 있어야 한다.

물론 그 성과를 받아들이는 것은 회사의 몫이지만, 그래도 개발자가 본인의 목소리를 높이기위해서는 객관적인 근거를 제시할 수 있는 방법을 알고 있어야 한다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ed%99%9c%ec%9a%a9-%ed%94%84%eb%a1%9c%ec%a0%9d%ed%8a%b8-%ec%b6%94%ec%a0%95%ea%b3%bc-%ea%b3%84%ed%9a%8d-1-%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98%ec%97%90-%ec%9d%98/

기능점수 산출 프로그램 – FPStudio

JaeSoo — Wed, 26 Mar 2014 10:37:20 +0000

기능점수산출을 하다 보면 상당한 반복작업이 동반되고, 기능점수산출 초보자는 어렵게 느낄 수 있는 부분들이 많아서,

기능점수를 보다 쉽게 산출할 수 있는 프로그램을 개발하였습니다.

이 프로그램은 제가 근무하는 회사에서 기능점수산출을 하기 위하여 개발한 프로그램이므로 다른 회사 실정에 조금 맞지 않을 수도 있으나 일반적인 상황에서의 기능점수 산출을 위한 도구를 포함하였으니 대부분의 상황에서 사용 가능하리라 봅니다.

지원하는 기능은,

엑셀을 이용한 신규개발 기능점수 산출
자체 편집기를 이용한 신규개발 기능점수 산출
신규개발 기능점수를 위한 엑셀양식
재개발 기능점수산출을 위한 엑셀양식
기능점수 산출 매뉴얼

등 입니다.

이 프로그램은 .Net 4.0과 Excel Interop을 이용하여 개발되었으므로, 아래의 환경이 필요합니다.

.Net 4.0 Framework
Excel 2010

설치는 아래의 파일을 다운하시고, 압축을 푼 후, 설치프로그램을 실행하면 됩니다.

[FPStudio Download]

사용방법은 프로그램 내에 사용법을 참조하시거나 아래의 매뉴얼을 참조하세요.

FPStudio 사용방법

1. 프로그램 실행

-?????? Winitech.Wisdom.FPStudio.exe를 실행한다.

메인화면

-?????? 프로그램을 실행하면 아래와 같은 메인화면이 나타난다.

-?????? 메인화면에서 제공하는 각 기능은 아래와 같다.

신규개발 – Excel Editor	신규개발용 FP 산출 – Excel을 편집기로 사용
신규개발 – Form Editor	신규개발용 FP 산출 – 자체 편집기 사용 자동FP기능(프로세스명에 의하여 FP 자동입력) 제공
신규개발 – Excel File	신규개발용 FP 산출 – 표준FP산출양식 (Excel실행)
재개발 – Excel File	재개발용 FP 산출 – 표준FP산출양식 (Excel실행)
매뉴얼 – 소프트웨어대가산정가이드	소프트웨어대가산정 가이드 표시 2012년 한국소프트웨어산업협회 발행
FP산출방법	FP 산출방법 교육자료 표시
FPStudio	FPStudio 매뉴얼 표시

2. 신규개발 ? Excel Editor 사용방법

2.1 편집

파일 열기

-?????? FP Studio 프로그램을 사용하여 저장한 파일을 오픈하여 편집할 수 있다.

-?????? 메뉴의 “파일 ?열기”를 선택하여 FP신규 파일 (확장자 : .fpxlsx)를 선택하면 저장된 정보가 화면에 표시된다.

-?????? 이때 다시 내용을 편집하고자 한다면 “엑셀편집”을 선택한다.

Excel 을 통한 기능 입력

-?????? Excel Editor는 기능 입력시 엑셀을 사용한다.

-?????? 메뉴의 “엑셀편집”을 선택하면 엑셀 프로그램이 실행되며 표시된 양식에 기능을 입력한다.

-?????? FP의 입력방법은 메인화면의 “FP산출방법”을 선택하면 표시되는 문서를 참조한다.

-?????? 엑셀은 2010 버전을 사용하므로 반드시 PC에 Excel 2010이 설치되어 있어야 한다.

2.2 기능입력

자세한 내용은 “FP산출방법”을 참조한다.

트랜잭션 기능 입력

-?????? 엑셀양식은 기본적으로 기능명에 4단계의 Level을 표시한다. Level의 변경을 원한다면 양식에서 기능명 부분에 열을 추가적으로 삽입하거나 기존 열을 삭제할 수 있다.

-?????? 지원하는 Level은 1개에서 10개까지 이다.

-?????? 엑셀에서 각 기능명과 외부입력(EI), 외부출력(EO), 외부조회(EQ)의 수치를 입력한다.

데이터 기능 입력

-?????? 각 기능이 필요로 하는 내부논리파일(ILF), 외부연계파일(EIF)의 이름을 기입한다.

-?????? 중복되어도 괜찮으므로 각 기능별 필요 논리파일을 모두 적는다.

-?????? 한 기능이 여러 논리파일을 사용하는 경우 각 이름을 쉼표로 구분하여 연속적으로 적는다.

기능 저장

-?????? 기능의 입력이 완료하고 입력된 기능의 총 FP와 원가를 산출하려면 엑셀파일의 저장을 선택한다.

-?????? 엑셀의 저장을 선택하면 자동으로 입력된 내용이 화면에 표시되고, 전체 FP와 원가가 계산되어 표시된다.

2.3 개발원가보정

-?????? 메뉴의 “개발원가보정”을 선택하면 아래의 화면이 표시되며, 각 항목을 입력하고 “확인”을 선택하면, 개발원가보정이 적용되어 개발비가 다시 계산되어 표시된다.

2.4 이윤/경비 입력

-?????? 메뉴의 “이윤/경비”를 선택하여 아래의 화면이 표시되며, 각 항목을 입력하고 “확인”을 선택하면, 개발비가 다시 계산되어 표시된다.

2.5 FP 정보입력

-?????? FP 산출에 부가적인 정보를 입력하고자 한다면 메뉴의 “FP정보입력”을 선택한다.

-?????? 이 정보는 파일 저장 시 함께 저장된다.

2.6 파일 저장

-?????? 작성한 FP 산출내역은 파일로 저장할 수 있다.

-?????? 파일 저장을 위해서는 “파일 ?저장”을 선택한다.

-?????? 메뉴의 “FP파일로 저장”을 선택하면, “Form Editor”와 호환되는 파일로 저장할 수 있다.

2.7 엑셀파일로 저장

-?????? 작성된 FP 산출내역을 타기관 제출용으로 저장할 수 있다.

-?????? 이를 위하여 “파일 ?엑셀파일로 저장”을 선택하면, 각 기능내역과 최종 계산된 원가 등의 내역을 제출가능한 형태의 엑셀파일로 저장한다.

-?????? 저장된 엑셀파일은 FP 산출을 위한 수식이 모두 적용되어 있으므로, 그대로 제출하거나 수정가능하다.

3. 신규개발 ? Form Editor 사용방법

-?????? Form Editor는 보다 간편하게 FP를 작성하거나, FP에 익숙하지 않은 사람을 위한 기능을 제공한다.

-?????? 기본적인 FP 산출 기능은 모두 Excel Editor와 동일하며, 기능의 편집을 Excel 대신 자체 편집기를 사용한다.

-?????? 편집기는 미리 정의된 기능명을 입력하는 경우, 자동으로 기능에 대한 Point가 입력되는 기능을 제공한다.

3.1 편집

파일 열기

-?????? FP Studio 프로그램을 사용하여 저장한 파일을 오픈하여 편집할 수 있다.

-?????? 메뉴의 “파일 ?열기”를 선택하여 FP신규 파일 (확장자 : .fpn)를 선택하면 저장된 정보가 화면에 표시된다.

편집기를 통한 기능 입력

-?????? 기능은 편집기의 Level 부문에 입력한다.

-?????? 기능 Level은 기본적으로 4개의 Level을 표시한다. 이를 변경하고자 하는 경우, 툴바의 “프로세스레벨수”를 선택하면 변경화면이 표시된다.

3.2 기능입력

자동FP 기능

-?????? Form Editor는 기본적으로 “자동FP”기능이 활성화 되어 있다.

-?????? “자동FP”기능은 편집기상의 최하위 Level 기능명의 입력시, 기능명을 분석하여 자동으로 Point를 채우는 기능이다.

-?????? 이 기능이 동작하기 위해서는 최하위 Level의 기능명을 반드시 미리 정해진 규칙에 의하여 입력하여야 한다.

-?????? 자동 FP 기능을 중지하고자 하는 경우, 툴바의 “자동FP”를 클릭하여 선택해제한다.

자동FP 기능을 위한 기능명 입력방법

-?????? 자동FP 기능은 최하위 Level의 기능명을 사용한다.

-?????? 자동FP 기능이 동작하기 위해서는 기능명이 아래의 구조로 입력되어야 한다.

단어(Optional) + ““ + “데이터기능명” + 트랜잭션기능명
단어	추가적인 정보를 나타내는 단어들 필요시에만 사용 (Optional) 단어 뒤에는 반드시 한자리 이상의 Space가 입력되어야 함 예) 시간대별, 일일 등
데이터기능명	기능의 주체가 되는 정보(데이터)의 명 트랜잭션기능명을 미리 정의된 이름을 사용하는 경우, 자동FP 기능에 의하여 데이터기능명이 추출되어 입력됨 예) 사용자, 부서, 관서 등
트랜잭션기능명	기능의 트랜잭션 동작을 나타내는 이름 미리 정의된 이름을 사용하는 경우, 자동FP 기능에 의하여 Point가 자동으로 입력됨 예) 관리, 입력, 수정, 삭제, 조회 등

-?????? 입력 사례

입력한 기능명

자동입력

사용자관리

미리정의된 “관리”에 의하여 아래와 같이 자동입력됨

데이터명 : 사용자

Point : EI(3), EO(0), EQ(2)

시간별 지령통계

미리정의된 “통계”에 의하여 아래와 같이 자동입력됨

“시간별”은 부가적으로 입력된 단어로 판단

데이터명 : 지령

Point : EI(0), EO(1), EQ(0)

-?????? 데이터 기능은 입력된 트랜잭션기능명에 의하여 내부논리파일과 외부연계파일 중 결정된다.

-?????? 정의된 기능명은 메뉴의 “자동FP규칙”을 선택하면 표시된다.

3.3 개발비 산정

개발원가보정

이윤/경비 입력

-?????? 메뉴의 “이윤/경비”를 선택하여 아래의 화면이 표시되며, 각 항목을 입력하고 “확인”을 선택하면, 개발비가 다시 계산되어 표시된다.

개발비산출

-?????? 메뉴의 “개발비산출(단축키 : F5)”를 선택하면 편집기에 입력된 정보에 대한 FP와 개발비가 산출되어 화면에 표시된다.

3.4 FP 정보입력

-?????? FP 산출에 부가적인 정보를 입력하고자 한다면 메뉴의 “FP정보입력”을 선택한다.

-?????? 이 정보는 파일 저장 시 함께 저장된다.

3.5 파일 저장

-?????? 작성한 FP 산출내역은 파일로 저장할 수 있다.

-?????? 파일 저장을 위해서는 “파일 ?저장”을 선택한다.

3.6 엑셀파일로 저장

-?????? 작성된 FP 산출내역을 타기관 제출용으로 저장할 수 있다.

-?????? 이를 위하여 “파일 ?엑셀파일로 저장”을 선택하면, 각 기능내역과 최종 계산된 원가 등의 내역을 제출가능한 형태의 엑셀파일로 저장한다.

-?????? 저장된 엑셀파일은 FP 산출을 위한 수식이 모두 적용되어 있으므로, 그대로 제출하거나 수정가능하다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ed%94%84%eb%a1%9c%ea%b7%b8%eb%9e%a8-fpstudio/

재개발기능점수 산출 엑셀양식

JaeSoo — Wed, 26 Mar 2014 10:28:44 +0000

앞의 설명에서 사용된 재개발기능점수 산출을 위한 엑셀 양식입니다.

사용법은 재개발기능점수 산출 설명을 참조하세요.

[엑셀양식다운로드]

[스크린샷]

출처 : http://rainiac.com/dev/index.php/%ec%9e%ac%ea%b0%9c%eb%b0%9c%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%97%91%ec%85%80%ec%96%91%ec%8b%9d/

기능점수 산출 실전 – 10.재개발 기능점수 산출 Tip

JaeSoo — Wed, 26 Mar 2014 10:27:20 +0000

설계변경율을 너무 높게 책정하지 마라

-?????? 일단 프로젝트가 재개발일 경우, 평균적인 설계변경율은 10% ~ 25% 수준이다.

-?????? 설계변경율이 너무 높으면, 검증기관에서 근거 제시를 요구할 수 있으므로, 적정 수준을 유지하도록 한다.

-?????? 특히, 데이터 기능의 변경율이 높으면 기존 테이블 레이아웃 대비 변경 근거의 제시 요구를 받을 수도 있으므로 주의한다.

트랜잭션기능의 설계변경율은 전체 변경 기능에 대하여 일괄적용하라

-?????? 설계변경율을 각 기능별로 일일이 적용하는 것은 매우 힘든 일이다.

-?????? 대부분의 경우, 변경기능의 설계의 변경율은 전체에 유사한 비율로 적용되니, UI, BL, DL 중 어느 유형이 변경될지 만을 결정하고, 그 비율은 전체에 대하여 일괄적으로 적용하는 것이 산출시간을 단축시켜준다.

-?????? 사실 설계가 몇 % 변경될지를 미리 정확하게 예측할 수는 없다. 따라서 내부적으로 조금변경(25%), 보통변경(50%), 많이변경(75%) 등의 기준을 세우고 그에 따라 적용하는 것이 편할 수 있다.

개발언어가 변경되면 코드변경율은 100%이다

-?????? 간혹, 기존 C/S 프로그램을 Web으로 전환한다거나, 프레임워크 상의 변경으로 인하여 개발언어가 변경되는 경우가 있다.

-?????? 이 경우, 설계변경과 무관하게 코드의 변경율은 100%이다.

재개발특성평가를 판단하기 힘들다면 중간값으로 선택하라

-?????? 사실 재개발특성평가는 검증하기 힘든 값이다.

-?????? 무난하게 각각 중간값을 선택하면 된다.

최종 개발비는 코드변경율과 시험변경율에 의하여 많이 좌우된다.

-?????? 코드변경율과 시험변경율이 전체 변경율에 차지하는 비율은 60%이다.

-?????? 즉, 단 두개의 값 입력만으로 상당한 비율이 변경될 수 있으며, 이 두개의 값은 객관적으로 증명하기 힘든 값이므로, 극단적인 값이 아니라면 크게 문제시 되지 않는다.

-?????? 이를 이용하여 큰폭으로 개발비를 조정할 수 있다.

재개발이 신규개발보다 개발비가 높게 나올 수도 있다.

-?????? 재개발의 설계/구현/시험 변경율이 높고, 재개발특성도 높다면 재개발이 오히려 신규개발보다 높게 나올수 있다.

-?????? 이 경우, 고객과 협의하여 신규개발로 산출하는 것이 바람직하다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%8b%a4%ec%a0%84-10-%ec%9e%ac%ea%b0%9c%eb%b0%9c-%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-tip/

기능점수 산출 실전 – 9. 재개발기능점수산출

JaeSoo — Wed, 26 Mar 2014 10:26:46 +0000

소프트웨어 재개발은 이미 개발된 소프트웨어의 일부를 다시 개발하거나, 발주자가 보유한 소프트웨어 자산을 재사용한 개발이다.

SI 사업에서 기존에 사용하던 시스템이 없어서 신규로 개발하는 경우도 있지만, 많은 경우 이미 있는 시스템을 개선하는 사업도 많이 존재한다. 따라서, 실제 재개발 기능점수도 상당히 빈번히 사용되며, 이미 기존에 사용되고 있는 시스템을 확장하는 경우 또는 기존에 사용하고 있는 기능을 변경하는 경우, 반드시 사용하여야 한다.

하지만 재개발 기능점수는 신규개발 기능점수에 비하여 상당히 복잡하여 대부분 그 산출방법을 모르고 있으며, 재개발 기능점수 또한 신규개발 기능점수 산출을 기반으로 계산되므로 기능점수 산출방법을 알고 있어야 한다.

재개발 기능점수는 단순하게 설명하자면,

-?????? 전체 기능을 신규개발과 재개발 대상으로 분류하고

-?????? 신규개발은 신규개발 기능점수로 산출하고

-?????? 재개발 대상은 해당기능의 신규개발 기능점수에 재개발 비율을 곱하여 기능점수를 산출하고

-?????? 이를 합산하여 전체 기능점수를 구한 다음,

-?????? 신규개발과 동일한 방법으로 단가를 적용하여 개발비를 산출한다.

즉, 신규개발과 다르게 재개발 기능점수 산출에서 추가되는 작업은

-?????? 기능을 신규개발과 재개발로 분류하는 작업

-?????? 재개발 기능에 대하여 설계변경율과 구현/시험 변경율을 구하는 작업

이렇게 두가지 이다.

즉, 기존 신규개발 기능점수 산출에 익숙하다면, 위의 설계변경율을 구하는 방법만 알면 크게 어렵지 않다. 신규개발부분은 따로 분류하여 신규개발 기능점수를 적용하면 되므로, 재개발에 대한 설계변경율만 추가적으로 알면되며, 구현/시험변경율은 산출자가 임의의 값을 지정하는 부분이므로 따로 작업할 필요는 없다.

따라서 이하 설명자료에서는 설계변경율을 구하는 방법에 대하여 자세히 설명하도록 한다. 그리고, 이미 기능점수 산출에 대한 이해하 있다고 가정하고, 바로 재개발을 위한 엑셀양식을 이용하여 산출하는 방법으로 설명한다.

트랜잭션 기능의 도출 및 분류

재개발의 경우, 이미 기존의 기능목록이 존재하므로 기능의 도출은 오히려 쉬운 경우가 많다. 기존 기능의 기능점수 내역이 있다면 거의 그대로 사용하면 된다. 단지, 신규추가기능이 필요하다면 추가적으로 도출하고, 각 기능에 대하여 신규기능/재개발기능을 분류하는 작업을 하면 된다.

재개발의 기능도 신규개발과 동일하게 기능과 유형을 결정하여야 하므로 아래와 같이 엑셀 양식에 각 기능을 작성한다.

위 그림에서 기존의 기능을 모두 그대로 채우고, 기능유형(EI/EO/EQ)도 그대로 적용한다. 예를 위하여 정보관리 부문에 두개의 신규기능을 추가하였다. 또한, 재사용유형 부분에 수정인지 신규인지를 구분해 주었다.

트랜잭션기능의 설계변경율 결정

?설계변경율은 소프트웨어의 재개발 또는 재사용을 위하여 어느 정도의 설계 노력이 필요한지를 나타낸다. 즉, 설계가 기존 기능에서 얼마나 변경되는 가에 대한 비율이다. 변경율이 높으면 높을수록 재개발 노력이 많이 필요하게 되므로, 비용이 증가하게 된다.

설계변경율은 세가지 요소를 측정하게 되는데 각각의 요소는 아래와 같다.

-?????? UI(User Interface, 사용자인터페이스) 변경율 : UI가 얼마나 변하는 가에 대한 변경율

-?????? BL(Business Logic, 업무처리로직) 변경율 : 내부 비즈니스 로직이 얼마나 변하는 가에 대한 변경율

-?????? DL(Data Logic, 데이터처리로직) 변경율 : 데이터 처리 로직이 얼마나 변하는 가에 대한 변경율, 즉, 주로 SQL상의 변경에 해당한다.

이 세가지의 변경율은 각각 전체 설계 변경율에 반영되는 가중치가 설정되어 있다. 전체 설계 변경율은 아래와 같은 공식에 의하여 결정된다.

트랜잭션 설계 변경율 = 0.25 * UI변경율 + 0.45 * BL변경율 + 0.3 * DL변경율

즉, UI변경율이 100%일 때, 전체 설계의 변경율에 0.25만큼 반영된다는 것이다. 이 변경율은 재사용유형이 수정인 경우에만 적용되며,? 앞에서 작성한 기능에 변경율을 적용하면 아래와 같이 표현된다. 변경율은 설명을 위하여 각각 50%, 25%, 25%로 설정하였다.

위그림에서 변경율을 각각 50%, 25%, 25%로 적용했을 때, 전체 설계변경율은 각각 31%가 됨을 볼 수 있다.

각각의 기능에 대한 설계변경율이 산출되었다면 최종 설계변경율은 해당 기능의 변경율과 기능이 전체 변경에서의 비중을 곱하여 구하게 된다. 즉, 하나의 기능이 전체 기능에서 가지는 비중을 곱하여 구하게 되는데, 이것은 기능별 크기를 변경율에 반영하는 과정이다.

이것을 가중변경율이라 하는데 최종 트랙잭션의 설계 변경율은 이 가중변경율의 합이 된다. 즉, 아래와 같은 공식으로 표현된다.

쉽게 설명하자면, 전체 수정대상 기능의 기능점수가 100점이고 현재 기능의 기능점수가 10점이라면, 해당 기능의 변경율에 10/100을 곱한값(전체에 대한 현재 기능의 비중)이 가중변경율이 되고, 모든 수정대상 기능의 가중변경율을 합한 값이 트랜잭션 기능 변경율이 된다. 이해가 잘 되지 않는 다면, 재개발을 위한 엑셀양식의 수식을 참조하는 것도 좋다.

아래의 그림은 앞에서 입력된 값에 의하여 자동으로 계산된 가중변경율과 설계 변경율이다.

데이터 기능의 도출 및 분류

데이터 기능의 변경율도 유사한 방법으로 진행된다. 먼저 기존의 데이터를 양식에 옮기고, 신규 데이터를 도출하여 작성한다. 그리고 각 데이터에 대하여 재사용유형과 설계변경율을 결정한다.

데이터 기능의 설계변경율 결정

데이터 기능의 설계변경율은 하나의 값으로 결정된다. 산출자가 판단하는 변경 비율을 입력하면 되며, 주로 해당 데이터의 컬럼수 중에 변경되는 컬럼의 개수에 대한 비율로 결정되지만, 확실하지 않은 경우, 적정한 임의의 값을 입력하면 된다.

데이터 기능도 트랜잭션기능과 마찬가지로 규모비중에 의하여 가중변경율이 결정되고, 이의 합을 전체 데이터기능 설계 변경율로 산출한다.

코드/시험변경율 결정 및 총변경율 산정

설계변경율이 산정되었다면 마지막으로 코드와 시험변경율을 결정한다. 총변경율은 설게, 코드, 시험 변경율 각각에 대하여 가중치가 부여되어 이를 곱한 값을 합산하여 구하게 된다.

코드변경율은 전체 소스코드가 어느정도 변할지에 대한 비율을을 예측하여 결정한다. 판단하기 힘들다면 통상 설계변경율의 두배정도를 책정하며, 프레임워크 등의 변경으로 인하여 다른 언어로 개발된다면, 코드변경율은 100%가 된다. 시험변경율은 재개발 기능에 대하여 통합 및 시험에 드는 노력이 신규개발에 대하여 어느 정도 필요한지를 비율로 책정한다.

앞에서 산출한 설계변경율에 코드 및 시험변경율을 50%로 결정한 결과는 아래와 같다.

재개발 특성 평가

재개발 기능점수 시에는 재개발 특성 요인을 평가하여 점수에 반영한다. 이 재개발 특성은 재사용소프트웨어 평가 노력수준, 재사용소프트웨어 난이도 수준, 재사용 소프트웨어 친숙도 수준이 있다. 각각의 특성값은 아래와 같이 결정한다.

재사용 소프트웨어 평가노력

재사용할 대상 소프트웨어를 직접 실행하여 재사용 타당성 및 가능성을 판단하는 평가를 어느 정도 수행하는지에 대한 점수이다.

재사용 소프트웨어 난이도 수준

재사용 대상 소프트웨어의 프로그램 구조화 정도, 어플리케이션 관점에서의 명확성 정도, 소스코드의 서술정도에 대하여 각각 판단한다. 최종 재사용소프트웨어 난이도 수준은 아래의 3가지 난이도의 평균점수이다.

재사용 소프트웨어 친숙도 수준

재개발 사업에 참여하는 인력들이 재사용 대상 소프트웨어를 타 사업에서도 사용하여 익숙한 정도를 판단한다.

최종 변경규모 산출

최종 변경규모는 재사용 소프트웨어 규모와 변경율 및 재사용 소프트웨어 특성을 고려하려 하여 신규개발 관점에서 보는 규모로 변환된 규모이다. 즉, 이 규모가 산출되면 기능점수당 단가를 적용하여 신규개발과 동일한 방법으로 개발비를 산출할 수 있다.

최종 변경규모는 총 변경율이 50이하인 경우와 50 초과인 경우를 구분하여 계산한다. 각각의 산출공식은 아래와 같다.

앞에서 입력한 내용에 의거하여 최종 변경규모를 산출하면 아래와 같다.

즉, 앞의 예에서 수정대상 소프트웨어의 기능점수는 신규개발 78.08과 동일한 규모란 뜻이다. 변경규모가 최종 기능점수로 도출되면 이후는 이 점수에 의거한 비용을 산출하면 된다.

총 기능점수 산출

만약 기능에 신규개발도 포함되어 있다면, 수정에 대한 변경규모와 신규개발에 대한 기능점수를 각각 산출하여 합산하여야 한다. 앞의 예에서 신규기능이 2개 포함되어 있으므로, 이를 합산하여 최종 기능점수를 산출한 결과는 아래와 같다.

개발원가 및 최종 개발비 산정

최종 기능점수가 산출되었으므로 개발원가와 개발비는 신규개발과 동일하게 산출하면 된다. 즉 단계별 단가와 보정계수를 이용하여 최종 기능점수에 대하여 산출한다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%8b%a4%ec%a0%84-9-%ec%9e%ac%ea%b0%9c%eb%b0%9c%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98%ec%82%b0%ec%b6%9c/

기능점수 산출 엑셀 양식

JaeSoo — Wed, 26 Mar 2014 10:23:36 +0000

앞의 설명에서 사용된 기능점수 산출을 위한 엑셀 양식입니다.

사용법은 기능점수 산출 설명을 참조하세요.

트랜잭션기능과 데이터 기능을 입력하면 거의 대부분 자동으로 산출됩니다.

[엑셀양식다운로드]

[스크린샷]

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%97%91%ec%85%80-%ec%96%91%ec%8b%9d/

기능점수 산출 실전 – 8.-기능점수산출 정리

JaeSoo — Wed, 26 Mar 2014 10:21:49 +0000

기능점수 산출을 위한 방법을 앞에서 길게 설명했지만, 실제로 수식이 적용되어 있는 엑셀 양식을 사용하거나, 본인이 개발한 FP산출 프로그램을 사용하면 크게 어렵지 않게 작업할 수 있다.

사실상, 기능점수 산출은 거의 기능도출과 유형 결정만 하면 나머지는 자동으로 처리되므로, 기능을 도출하는 방법만 알면 된다고 볼 수 있다.하지만, 이 기능의 도출은 경험이 많이 필요하다. 따라서, 다양한 프로젝트에 실제로 한번 산출을 해보는 것이 좋다.

또한 실제 프로젝트의 개발비 산정시, 기능점수 결과에 의하여 예산이 책정되어야 하지만 아직은 그 반대로 예산에 기능점수를 맞추는 것이 현실이다. 앞에서 설명한 기능점수 산출요령에서 최종 개발비를 낮추거나 높이는 요령 들은 기능점수의 목적상 피해야 할 일 들이지만, 아직은 어쩔 수 없이 저런 요령을 사용해야 한다. 이는 앞으로 국내의 소프트웨어 개발비에 대한 인식이 바뀌면 점차 개선될 것으로 기대해 본다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%8b%a4%ec%a0%84-8-%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98%ec%82%b0%ec%b6%9c-%ec%a0%95%eb%a6%ac/

기능점수 산출 실전 – 7. 기능점수 산출 Tip

JaeSoo — Wed, 26 Mar 2014 10:21:15 +0000

실제 기능점수를 예산단계에서 산출하면, 도출하기에 매우 애매한 상황이 많다. 사실 개발비를 되도록 많이 책정해야 하는 기업입장에서는 많은 기능을 도출하여 개발비를 늘려야 하는 입장이지만, 기능점수의 개념이 요구사항의 복잡도를 측정하는 방식이므로, 요구사항이 명확하지 않은 예산수립단계에서는 많은 기능을 제대로 도출하기가 쉽지 않다. 또한 기능점수는 사용자에게 의미있는 기능을 도출하는 방식이기 때문에 개발비를 많이 받아야 하는 서버용 프로그램이나 내부로직위주의 제어 프로세스는 오히려 금액이 책정되지 않는 문제가 발생한다. 또한 대부분의 영업 또는 제안단계에서는 이미 예산이 확정되어 있어서, 기능점수에 의한 개발비를 확정되어 있는 금액에 맞추어야 하는 상황이 많이 발생한다.

최근 공공기관에서 발주하는 프로젝트는 전문기관에 기능점수의 검증을 의뢰하는 경우가 늘고 있다. 이런 경우, 검증기관에서 기능점수의 도출 근거 자료를 제시하도록 요구하거나, 잘못 산정된 기능점수의 경우, 기능을 제거하여 개발비가 줄어드는 결과를 가져올 수도 있다.

따라서, 기능점수를 실전에 사용할 경우, 산출에 대한 경험도 많이 필요하고, 상황에 따른 산출 요령도 어느정도 필요하다. 이러한 상황별 요령 및 기능점수 검증을 통과하기 위한 팁들을 소개한다.

기능점수 검증기관은 “점수”를 검증한다. “기능”은 검증할 수 없다.

-?????? 기능점수를 검증하는 기관은 기능점수를 도출한 프로젝트의 업무를 모른다.

-?????? 즉, 기능이 제대로 도출되었는가를 판단할 수는 없다.

-?????? 기능의 검증은 주로 “기능명의 형태”와 기능의 유형의 일치에 집중된다.

-?????? 따라서, 기능의 명칭과 기능의 유형(EI/EO/EQ)가 일치하면 기능의 검증은 대부분 통과된다.

기능의 명칭은 CRUD 성 동사를 사용하라

-?????? 위에서 설명한 바와 같이 검증기관은 명칭과 유형의 일치성을 본다.

-?????? 즉, 기능의 명칭을 기능유형이 명확하게 파악되는 이름을 사용한다.

-?????? 즉, “관리”, “입력”, “수정”, “삭제”, “조회”, “검색”등과 같이 CRUD가 명확한 이름을 사용한다.

-?????? 이와 같은 이름은? EI, EO, EQ를 명확하게 한다.

내부처리 기능인 경우, 사용자에게 의미있을 것 같은 이름으로 바꾸어라

-?????? 서버 프로그램 또는 백그라운드처리 등의 기능은 사실 기능점수에 도출되지 않는다. 기능점수의 기능은 사용자에게 의미있는(주로 UI를 가지는) 것만 도출하기 때문이다.

-?????? 하지만 이런 기능을 개발비에서 누락시킬 수 없다면, 사용자에게 의미있는 것 같은 이름으로 기능을 도출하라. 위에서 얘기했듯이, 검증기관은 기능 자체의 적정성을 파악할 수 없으므로, 이름과 유형만 맞으면 된다.

-?????? 즉, “xxx 처리”, “xxx 전송”, “xxx 수신”, “xxx 집계”등과 같이 내부프로세스인 듯한 느낌의 이름은 피한다. 이런 이름은 거의 지적당할 수 있다. 대신 “조회”, “입력”과 같은 이름을 사용한다.

기능점수 검증기관은 “EO”를 검증한다.

-?????? 기능점수에서 EO를 많이 틀리게 되므로 EO가 산출되면 유심히 살피게 된다.

-?????? 대부분의 조회는 모두 “EQ”이다. 수학적 계산결과에 의한 결과를 조회하는 경우만 EO를 사용하라.

-?????? EO는 반드시 “통계”와 같은 명칭을 사용하고, EO와 EQ의 판단이 힘들다면 그냥 EQ를 사용하라.

개발비를 늘이고 싶다면 “기능”을 늘여라

-?????? 개발비 산정과정을 보면, 가장 쉽게 개발비를 높이는 방법은 보정계수를 높이는 방법이다.

-?????? 하지만 보정계수는 검증기관이 객관적으로 판단가능한 부분이므로, 너무 높이게 되면, 지적을 받을 수 있다. 즉, 개발비가 보정계수를 낮춤으로서 마지막에 축소될 위험이 있다.

-?????? 어플리케이션 유형의 경우, 유형별 비율을 실제 전체 기능에서 해당 유형의 기능 수를 세어서 검증하라고 요구받는 경우도 있다.

-?????? 즉, 안전하게 개발비는 높이는 방법은 기능을 늘이는 것이다.

기능을 늘이기 위해서는 기존 기능에 부가적인 기능을 더 도출하라

-?????? 앞에서 기능점수 검증기관은 “기능의 적정성”을 판단할 수 없다고 했다.

-?????? 또한 검증기관은 모든 요구사항을 알고 있지도 못한 경우가 많다.

-?????? 즉, 이미 만들어진 기능으 더 분할하거나, 기능에 “정보의 선택”, “유사정보의 관리”등 숨어 있는 추가 기능들을 도출하여 추가한다.

-?????? 그 기능들이 명칭과 유형이 일치하는 이상, 추가에 대한 위험은 없다. 단, 기능점수에 적힌 이상, 개발시 반드시 개발되어야 한다.

-?????? 노련한 분석자라면, 개발범위를 늘이지 않고 기능점수만을 늘이는 요령을 익힐 필요가 있다.

데이터 기능을 적극 활용하라

-?????? 데이터 기능을 ILF의 경우 전체 기능중에 가장 높은 평균복잡도를 가진다. 즉, 가장 금액이 비싼 기능이다.

-?????? 대부분 기능 검증 시, 트랜잭션 기능을 위주로 검증한다. 트랜잭션 기능은 EI/EO/EQ의 적정성을 검증하게 되지만, 데이터 기능은 대부분이 ILF기 때문에 크게 검증을하지 않는다.

-?????? 또한 트랜잭션기능에 기술된 항목은 실제 프로젝트 수행시, 모든 기능을 구현해야 한다. 하지만 데이터 기능은 논리적인 데이터이기 때문에 모든 것이 테이블로 구현될 필요는 없다.

-?????? 즉, 데이터 기능을 합리적으로 늘이거나 줄여서 개발비를 큰 폭으로 조정가능하다.

-?????? 개발비를 늘이고자 한다면, 데이터 기능을 많이 도출하라. 단, 도출된 데이터의 관리가 반드시 트랜잭션기능에 존재하여야 한다.

개발비를 낮출려면 기능을 제거하라.

-?????? 앞의 설명에 반대되는 개념이다. 예산의 한계에 의하여 개발비를 전체적으로 낮추어야 할 경우도 있는데, 이 때, 보정계수 등으로 낮추는 방법은 피하도록 한다.

-?????? 돈을 적게 받는다면, 기능을 제거하여 실제 개발범위를 줄이는 것이 바람직하다.

-?????? 만약 기능자체를 줄일 수 없는 상황이라면, EI가 3으로 책정되는 “xxx관리”계열의 기능을 “xxx입력”으로 바꾸고 EI를 1로 변경한다. EI는 복잡도가 높은 기능이므로, 전체적인 개발비가 많이 줄어들 것이다.

보정계수는 되도록 낮게 설정한다.

-?????? 기능점수에 익숙하지 않을 경우, 대부분 개발비를 보정계수를 이용하여 조정한다.

-?????? 보정계수는 어느 정도 기준이 명확하므로 이 경우 검증기관에 집중적인 지적을 받게 된다.

-?????? 보정계수는 되도록 낮게 설정하는 것이 안전하다. 낮을 경우 거의 지적을 받지 않는다.

-?????? 일반적인 프로젝트에서 품질/특성 보정계수의 경우, 대부분 “1”이다. 성능은 실제 성능에 대한 요구가 없거나 성능측정을 위한 도구를 사용하지 않는다면 무조건 “0”이다. 그리고, 신뢰성과 다중사이트도 요구사항이 없다면, “0”으로 설정한다.

개발비의 미세조정은 이윤으로 가능하다.

-?????? 이윤은 전체 개발원가의 0%에서 25%까지 설정가능하다.

-?????? 이를 이용하여 최종 목표금액을 어느정도 조절가능하다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%8b%a4%ec%a0%84-7-%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-tip/

기능점수 산출 실전 – 6. 상황별 기능점수 산출방법

JaeSoo — Wed, 26 Mar 2014 10:20:36 +0000

기능점수를 산출하다 보면, 대부분의 경우는 그 기능명에 의하여 기능유형이 결정되지만 가끔 기능으로 도출은 하였으나, 유형을 결정하기가 애매한 경우가 있다. 아래는 대표적인 기능유형과 자주 만날 수 있는 상황들에 대한 산출 예이다.

사용자 정보 관리

-?????? 검색과 CRUD 모두를 포함하는 기능

-?????? 검색 기능은 단순조회이므로 “EQ”에 1을 추가

-?????? 관리를 위한 상세정보 조회는 단순조회이므로 “EQ”에 1을 추가

-?????? 관리화면은 입력, 수정, 삭제를 포함하므로 각각 1을 추가

-?????? 사용자정보는 “사용자”데이터를 사용하므로 ILF에 “사용자”추가

EI			EO	EQ	ILF	EIF
입력	수정	삭제
1	1	1		2	사용자

사용자 정보 조회

-?????? 사용자의 정보의 검색과 상세조회 화면이 있는 기능

-?????? 검색 기능은 단순조회이므로 “EQ”에 1을 추가

-?????? 상세정보 조회는 단순조회이므로 “EQ”에 1을 추가

-?????? 사용자정보는 “사용자”데이터를 사용하므로 ILF에 “사용자”추가

EI			EO	EQ	ILF	EIF
입력	수정	삭제
				2	사용자

일일 착신통계

-?????? 일별 착신현황의 통계를 조회하고, 인쇄하는 기능

-?????? 통계조회는 수학적 계산을 요하는 조회이므로 “EO”에 1을 추가

-?????? 인쇄는 단순조회이므로 “EQ”에 1을 추가

-?????? 착신정보 테이블을 사용하므로 ILF에 “착신정보”추가

EI			EO	EQ	ILF	EIF
입력	수정	삭제
			1	1	착신정보

신고전화 대이관

-?????? 수보대에 연결된 전화를 다른 수보대로 연결

-?????? 신고전화를 이관하기 위해서는 이관할 대상 수보대를 조회하여야 한다. 따라서 EQ에 1을 추가한다. 또한 ILF에 “수보대정보”를 추가한다. (이러한 정보가 테이블로 만들어질지에 대하여 고민할 필요는 없다. 정보가 사용되면 일단 논리파일에 적는다. 내부논리파일은 꼭 테이블인 것은 아니다)

-?????? 신고전화를 대이관 하기 위해서는 CTI서버에 이관명령을 전송하여야 한다. 즉, 사용자는 “전화의이관요청”을 시스템외부로 출력하게 되므로 “EQ”에 1을 추가한다.

EI			EO	EQ	ILF	EIF
입력	수정	삭제
				2	수보대정보

기상정보연계

-?????? 기상청 연계를 통하여 수신된 기상정보를 사용자에게 보여주는 기능

-?????? 기상정보를 기상청(외부)으로부터 수신(입력)받으므로 EI에 1을 추가하고 EIF에 “기상정보” 추가

-?????? 기상정보를 사용자에게 표시하므로 EQ에 1추가

EI			EO	EQ	ILF	EIF
입력	수정	삭제
	1			1		기상정보

시스템 간의 데이터 송수신

-?????? 3. 기능점수 측정방법에서 기능점수는 시스템의 외부와 데이터를 트랜잭션하는 경우에만 측정된다고 하였다.

-?????? 즉, 시스템의 내부에서의 송수신은 기능점수로 측정되지 않는다.

-?????? 예를 들어, 관제시스템과 관제시스템이 I/F 하는 장치제어서버가 모두 동일 프로젝트에서 개발된다면, 관제 시스템과 각 서버간의 통신 기능은 기능점수로 도출할 수 없다. 각 프로그램이 모두 동일 시스템 경계 내부에 있으므로 모든 기능유형에 해당되지 않는다.

-?????? 동일한 예로 C/S 구성에서 클라이언트와 서버간의 통신(SQL)은 기능유형에 해당하지 않는다.

-?????? 기능으로 측정되기 위해서는 시스템의 경계 외부에 있는 시스템과 데이터를 송수신하여야 한다.

-?????? 즉, 위 예에서 장치제어 서버가 이미 구축되어 있거나 외부 시스템에 있다면, 시스템의 경계외부에 있으므로 송수신기능을 외부입력이나 외부조회로 산출될 수 있다.

-?????? 즉, 내부 시스템간의 데이터 송수신 기능은 기능으로 도출하지 않는다. 부득이 도출하고자 한다면 기능이름을 송수신 계열로 명명하지 않고 다른 이름을 사용하여야 한다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%8b%a4%ec%a0%84-6-%ec%83%81%ed%99%a9%eb%b3%84-%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c%eb%b0%a9%eb%b2%95/

기능점수 산출 실전 – 5.기능점수 및 소프트웨어 개발비 산정 예제

JaeSoo — Wed, 26 Mar 2014 10:19:58 +0000

앞에서 설명한 기능점수의 산출과 그에 따른 개발비 산정을 이용하여 실제 산출하는 방법을 알아보도록 한다. 실전에서는 대부분 엑셀양식을 미리 만들고 대부분의 계산을 스크립트로 처리하므로, 대부분의 작업은 기능의 도출과 기능의 유형을 결정하고, 보정계수를 입력하면 나머지는 자동으로 처리된다.

실제 본인이 사용하는 양식을 이용하여 개발비를 산정하는 방법을 실제 사례를 통하여 설명한다.

요구사항

앞에서 예로 들었던 간략한 전자결재 시스템에 대하여 작업한다. 요구사항이 이렇게 구체적으로 나올리는 없겠지만, 일단 예를 들어 아래와 같은 요구사항이 있다고 가정한다.

요구사항

결재 요청

-?????? 사용자는 새로운 전자결재 문서를 생성하여 작성할 수 있다.

-?????? 결재시 결재선과 결재양식을 지정할 수 있으며, 결재선 지정시, 직원을 검색하여 지정할 수 있다.

결재처리

-?????? 사용자는 본인에게 수신된 결재문서목록을 조회할 수 있다.

-?????? 사용자는 결재문서목록을 선택하여 결재문서를 조회할 수 있다.

-?????? 사용자는 본인에게 수신된 결재문서를 결재 또는 반려처리할 수 있다.

-?????? 결재를 요청한 사용자는 본인이 작성한 문서의 결재상태를 조회하고 결재문서를 출력할 수 있다.

정보관리

-?????? 시스템관리자는 결재에 사용될 사용자정보와 부서정보를 관리할 수 있다.

-?????? 시스템관리자는 결재에 사용될 결재유형별 양식을 관리할 수 있다.

-?????? 시스템관리자는 월별 결재처리 통계를 조회할 수 있다.

기타

-?????? 웹환경에서 개발한다.

기능도출 및 기능유형 결정

-?????? 요구사항을 분석하여 트랜잭션기능과 데이터기능을 도출한다.

-?????? 쉬운 도출을 위하여 아래와 같은 엑셀양식을 이용하여 요구사항을 만족하는 기능을 기입한다.

-?????? 기능명과 트랜잭션유형을 입력하고, 기능이 필요로하는 데이터명을 입력한다.

기능명		EI			EO	EQ	ILF	EIF
기능명		입력	수정	삭제	EO	EQ	ILF	EIF
결재요청	결재문서작성	1					결재문서
	결재선입력	1					결재선
?	결재양식선택	?	?	?	?	1	결재양식	?
	결재선검색					1	사용자
결재처리	결재문서목록조회	?	?	?	?	1	결재문서	?
?	결재문서조회	?	?	?	?	1	결재문서	?
?	결재처리	?	1	?	?	?	결재문서	?
?	결재상태조회	?	?	?	?	1	결재문서	?
?	결재문서출력	?	?	?	?	2	결재문서	?
정보관리	사용자관리	1	1	1	?	2	사용자	?
?	부서관리	1	1	1	?	2	부서	?
?	결재양식관리	1	1	1	?	2	결재양식	?
?	월별결재통계	?	?	?	1	?	결재문서	?

-?????? 위 예에서 “입력”, “선택”도 기능으로 도출한다. 사용자 입장에서 무언가를 “선택”하는 행위도 하나의 기능으로 보아야 하기 때문이다. 실제 이 “선택”은 추후 개발시 콤보박스 하나로 구현될 지라도, 요구가 있다면 하나의 EQ로 도출되어야 한다.

-?????? 결재문서출력 기능은 “조회”와 “인쇄(출력)”을 모두 가지므로 EQ를 2로 잡는다.

기능점수 산출

-?????? 위의 표를 완성하였다면, 실제 기능점수 산출용 엑셀에 트랜잭션기능과 데이터 기능을 옮긴다.

-?????? 엑셀양식에서 보통 트랜잭션과 데이터는 다른 쉬트로 정리하게 되며, 데이터기능은 위 표에서 중복을 제거하고 옮긴다.

[트랜잭션기능 쉬트]

기능명		EI	EO	EQ
결재요청	결재문서작성	1
	결재선입력	1
?	결재양식선택	?	?	1
	결재선검색			1
결재처리	결재문서목록조회	?	?	1
?	결재문서조회	?	?	1
?	결재처리	1	?	?
?	결재상태조회	?	?	1
?	결재문서출력	?	?	2
정보관리	사용자관리	3	?	2
?	부서관리	3	?	2
?	결재양식관리	3	?	2
?	월별결재통계	?	1	?
합계		12	1	13

[데이터기능 쉬트]

데이터명		ILF	EIF
전자결재	결재문서	1
?	결재선	1
?	결재양식	1	?
?	사용자	1
?	부서	1	?
합계		5	0

-?????? 위 표를 완성하면 트랜잭션과 데이터 기능의 유형별 합계가 산출되었으므로, 엑셀 스크립트에서 자동으로 기능점수를 산출하도록 할 수 있다.

-?????? 총 기능점수를 산출하기 위하여 아래의 테이블을 사용한다.

기능유형	평균복잡도			합 계
내부논리파일(ILF)	5	×	7.5	37.5
외부연계파일(EIF)	0	×	5.4	0.0
외부입력(EI)	12	×	4.0	48.0
외부출력(EO)	1	×	5.2	5.2
외부조회(EQ)	13	×	3.9	50.7
총 기능점수				141.4

보정계수 산출

-?????? 보정계수는 아래의 쉬트를 이용하여 계산한다. 쉬트에는 수식으로 값을 입력하면 각각의 보정계수값을 자동 계산하도록 할 수 있다.

-?????? 전체를 웹으로 개발하게 되므로 언어는 Java와 스크립트를 반씩 사용하는 것으로 설정하며, 어플리케이션 유형은 100% 업무처리용이다. 일반적인 C/S와 웹환경의 경우 분산처리는 1로 설정하면 되며, 나머지 품질특성은 요구가 없으면 모두 0이다.

개발원가 산출

-?????? 위의 작업까지 완료하였다면, 개발원가는 자동계산되며, 계산된 쉬트는 아래와 같다.

소프트웨어 개발비 산출

-?????? 개발원가에 이윤과 부가가치세를 더하여 최종 개발비를 산출한다.

-?????? 예에서는 이윤 10%를 책정하였다.

-?????? 계산에 의하여 위 전자결재 시스템의 총 개발비는 556,700,000원이다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%8b%a4%ec%a0%84-5-%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%eb%b0%8f-%ec%86%8c%ed%94%84%ed%8a%b8%ec%9b%a8%ec%96%b4-%ea%b0%9c%eb%b0%9c%eb%b9%84/

기능점수 산출 실전 – 4. 개발비산정

JaeSoo — Wed, 26 Mar 2014 10:15:52 +0000

앞에서 설명한 기능점수는 다양한 분야에 사용될 수 있는데, 가장 많이 사용되는 것이 개발비의 산출이다. 기능점수로부터 개발비를 산정하는 방법은 매우 쉽다. 왜냐하면, 국내에서 표준으로 기능점수당 단가가 책정되어 있기 때문이다. 이는 지식경제부에서 고시한다.

개발비는 “보정전 개발원가”와 “보정후 개발원가”에 의하여 책정되는데, 보정전 개발원가는 기능점수당단가를 단순히 기능점수에 곱한 값이며, 보정후 개발원가는 프로젝트의 품질적, 언어적 특징을 고려한 보정계수를 곱한 값이다.

보정전 개발원가

보정전 개발원가는 단순히 최종 기능점수에 기능점수당 단가를 곱하여 구한다.

보정전 개발원가 = 기능점수 * 기능점수당단가

기능점수당 단가 = 497,427 원

즉, 앞장의 예에서 기능점수는 총 62.4점이었다. 이 경우 보정전 개발원가는,

보정전 개발원가 = 62.4 * 497,427원 = 31,039,445원

이 된다.

위 기능점수당 단가는 분석,설계,구현,시험의 4단계를 모두 포함하는 금액이다. 때에 따라서는 개발의 전과정을 수행하지 않고, 일부만을 수행할 수도 있는데, 이를 위하여 각 개발단계별로 기능점수 당 단가를 가중치에 따라 별도로 책정하고 있다.

단계	분석	설계	구현	시험	합계
가중치	0.19	0.24	0.32	0.25	1.00
단가	94,511원	119,382원	159,177원	124,357원	497,427원

보정후 개발원가

실제 개발비 산정에는 보정전 개발원가는 사용되지 않고, 보정후 개발원가를 사용한다. 보정후 개발원가는 보정전개발원가에 4가지 보정계수를 곱하여 구하게 되는데, 이는 소프트웨어의 개발난이도, 규모, 품질 등에 따라 개발에 드는 노력이 달라지게 되므로 이를 개발비에 반영하는 것이다.

보정계수는 아래의 유형이 존재한다.

규모보정

-?????? 일반적으로 소프트웨어 개발의 규모가 커지면 커뮤니케이션 등의 복잡도의 증가 등으로 개발에 필요한 비용이 증가한다.

-?????? 이를 위하여 개발규모에 대한 개발비를 보정하며, 공식은 아래와 같다.

어플리케이션 유형보정

-?????? 개발되는 어플리케이션의 유형에 따라 개발비를 다르게 책정한다.

-?????? 일반적으로 단순 정보처리용보다 통신제어용, 과학기술용, 지휘통제용 등의 어플리케이션은 그 복잡도로 인하여 개발에 드는 노력이 증가한다.

-?????? 이를 위하여 어플리케이션의 유형에 따라 보정을 하게 되며, 그 값은 아래와 같다.

-??????? 위의 표의 값에 따라 보정계수를 곱하게 되며, 실제 산출은 전체 어플리케이션에서 각 유형의 비율을 계산하여 산출하게 된다.

-??????? 실제 계산 양식은 아래와 같으며, 최종보정계수값은 유형별보정계수를 비중과 곱하여 합산하면 된다.

언어 보정계수

-?????? 개발에 사용될 개발언어에 따라 개발의 생산성에 영향을 주게 되므로, 개발언어에 따른 보정계수를 적용한다.

-?????? 언어유형은 총 5가지로 구분되며 각각의 유형과 보정계수는 아래와 같다.

-?????? 언어 보정계수는 구현에 해당하므로 후에 보정후 개발비 산정시 분석/설계의 단가에는 적용되지 않는다.

-?????? 실제 계산 양식은 아래와 같으며, 최종보정계수값은 유형별보정계수를 비중과 곱하여 합산하면 된다.

품질 및 특성 보정계수

-?????? 사용자가 시스템에 요구하는 특정한 품질 및 특성 또한 개발의 생산성에 영향을 미친다.

-?????? 이를 위하여 사용자 요구 품질/특성에 따른 보정을 적용한다.

-?????? 이 보정계수는 반드시 사용자의 요구가 있는 경우에만 적용되어야 한다.

-?????? 그 유형은 아래의 4가지 유형이 있으며, 각각의 기준에 따라 영향도가 평가된다.

-??????? 위의 표에 따라 영향도를 평가 하고 각 요소별 영향도를 모두 합하여 총영향도를 계산한다.

총영향도 = 각 보정요소별 영향도 값의 합산

-??????? 총영향도가 산정되면 실제 품질 및 특성 보정계수는 아래와 같이 계산된다.

품질및특성 보정계수 = 0.025 * 총영향도 + 1

-??????? 다른 보정계수와 마찬가지로, 아래의 표를 이용하여 품질 및 특성 보정계수를 계산한다.

보정후 개발원가 산출

-?????? 보정후 개발원가는 위에서 설명한 보정계수를 개발의 각 단계별 단가에 곱하여 산출한다.

-?????? 이때, 앞에서 설명한 바와 같이, 언어보정계수는 분석,설계에는 적용하지 않으며, 구현,시험에만 적용하여 계산한다.

-?????? 실제 계산은 아래와 같은 표를 이용하여 산출하면 편리하게 할 수 있다.

-?????? 실제 작업에서는 거의 대부분 엑셀로 양식을 만들어 자동으로 계산한다.

직접경비 및 이윤 계산

-?????? 실제 개발비 산정에서는 개발이윤과 직접경비를 적용한다.

-?????? 이윤은 소프트웨어사업의 대가기준에 따라 개발비의 25% 이내에서 책정할 수 있다.

-?????? 즉, 25% 이내에서 상황에 따라 적정한 값을 적용하면 된다.

-?????? 직접경비는 대부분 SI 사업에서는 사업자가 부담하므로, 대부분 산정에서 제외되지만, 계약상 직접경비를 개발비에 포함하는 경우, 각 경비항목과 산출내역 금액을 작성하여 개발비에 합산한다.

최종 소프트웨어 개발비 산정

-?????? 지금까지의 계산한 값을 모두 더하여 최종 개발비를 산정한다.

-?????? 즉, 보정후 개발원가, 이윤, 직접경비를 더하고, 필요시 부가가치세를 더하여 최종 금액을 산출한다.

-?????? 최종 개발비는 아래와 같은 표로 표현된다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%8b%a4%ec%a0%84-4-%ea%b0%9c%eb%b0%9c%eb%b9%84%ec%82%b0%ec%a0%95/

기능점수 산출 실전 – 3. 기능점수 측정방법

JaeSoo — Wed, 26 Mar 2014 10:13:09 +0000

기능점수의 측정은 “요구사항수집”, “기능도출”과 “기능별점수측정”의 세가지 단계로 이루어진다. (그래서 기능점수다) 일반적으로 기능점수를 이용하여 개발비를 산출하는 과정은 아래와 같다.

요구사항수집

기능점수는 “사용자의 요구”에 대한 복잡도의 측정이므로 요구사항이 없으면 도출할 수 없다. 즉, 요구사항을 수집하거나, 제안요청서 등에서 추출하거나, 기획/영업단계라면 직접 고객이 필요한 사항을 도출하여야 한다.

사실 기능점수는 기획/영업단계에서 많이 산출된다. 실제 SI 사업의 영업단계에서 고객에게 프로젝트의 예산수립을 위한 자료를 제공하여야 하기 때문이다. 이 시점에서 기능점수의 산출시 “산출담당자”는 누가 적당한가에 대한 문제가 발생한다. 영업부는 기능점수를 모르고 개발부서는 요구사항을 모른다.

사실 이 시점에서 적임자는 없을 듯하다. 소프트웨어 개발업체라면 영업부서/개발부서 모두 기능점수에 대한 상당한 이해도가 있어야 하며, 이에 따라 두 부서가 협력하여야 한다.

즉, 영업부서는 기능점수 산출 요청시, 산출자에게 충분한 “요구사항”을 정리하여 전달하여야 한다.

기능도출

기능점수에서의 “기능”은 개발자 측면에서 “구현기능”과 다른 의미이다. 이는 철저히 사용자 관점이며 실제 구현 시의 프로그램 구조와는 별개의 의미이다. 따라서, 반드시 모든 기능은 “사용자가 인지할 수 있는 기능”의 형식으로 도출되거나, 이에 유사하게 표현하여야 한다.

기능은 요구사항이 기술된 문장을 분석하여 해당 요구를 만족하기 위해서는 어떤 기능을 제공하여야 하는지를 도출하여야 한다. 즉, 하나의 요구사항 문장은 여러 개의 기능을 포함할 수 있다. 따라서, 요구를 분해하여 최소의 단위 기능으로 도출하여야 한다. 이는 개발방법론의 분석단계에서 요구사항을 정의하고 이를 분해하여 프로세스를 도출하는 과정과 거의 유사하다.

일반적으로 기능을 도출하는 방법은 아래와 같다.

기능은 요구사항을 분해하여 논리적인 최소 업무단위로 도출

-?????? 기능를 도출하기 위하여 사용자 요구를 분석하고, 이를 바탕으로 필요한 기능을 분해하여 도출한다.

-?????? 추후 몇 개의 윈도우 등으로 구현될 지 고려할 필요는 없다. 단지, 어떤 트랜잭션 기능을 갖게 될 것인지만 도출하면 된다.

하나의 요구사항이 다루는 정보가 여러가지 일 경우, 모든 기능을 별개로 취급한다.

-?????? 요구사항이 다수의 정보를 나열하고 나열된 정보 모두를 처리하는 기능을 요구하는 경우에 해당한다

(예) Email, Fax, Web, 전화 등으로 수신되는 주문정보를 조회할 수 있어야 한다.

-?????? 이런 경우, 추후 하나의 공용모듈로 처리 가능하더라도 각각을 개별적인 기능으로 도출하여야 한다. : Email주문조회, Fax주문조회, Web주문조회, 전화주문조회

-?????? 기능점수에서 기능은 요구사항의 복잡도를 측정하므로 각각의 정보를 요구했다면 각각을 모두 다른 기능으로 인식하여야 한다.

사용자가 인지 가능한 기능만을 도출한다.

-?????? 기능점수에서 기능은 사용자가 인지 가능한 기능을 도출한다.

-?????? 즉, 사용자가 어떤 행위를 하거나, 사용자에게 어떤 정보를 주는 기능이 주로 도출된다.

-?????? 따라서, 기능명이 사용자가 인지할 수 없는 느낌의 이름은 피하도록 한다.

-?????? 즉, 기능명이 “XXX 처리”, “XXX 표시”와 같이 표현되면, 이는 사용자가 인지할 수 없는 기능으로 보이므로 피하도록 한다.

-?????? 대신 “XXX관리”, “XXX입력”, “XXX조회”와 같은 사용자관점에서의 능동적인 이름을 주로 사용한다.

기능의 유형에 해당하는 트랜잭션 기능을 요구로부터 도출한다.

-?????? 기능점수에서 트랜잭션기능은 입력/출력/조회 유형밖에 없다.

-?????? 즉, 기능을 이 세가지 유형 관점에서 도출한다.

-?????? 주로 C(생성), U(수정), D(삭제)와 통계(출력), 조회 또는 검색(조회), 선택(조회) 으로 끝나는 이름을 기능으로 도출하는 것이 좋다.

서버 기능, 인터페이스 기능 등은 기능명을 변형하여 도출한다.

-?????? 실제 기능이 서버기능이라 사용자가 인지할 수 없는 기능인 경우, 기능점수 산출을 위해서는 이름은 변형하여 사용자가 인지가능한 것처럼 표현해야 할 경우가 있다.

-?????? 즉, “XXX 처리”, “XXX 송수신”과 같은 기능은 “XXX 저장”, “XXX 수신”등과 같은 이름을 사용한다.

-?????? 송신은 “XXX입력” 으로 표현하고, “EI ? ILF(송신데이터)”로 도출, 수신은 “XXX조회” 등으로 표현하고, “EQ ? ILF(수신데이터)”로 도출한다.

-??? 만약 송수신 대상 시스템이 외부 시스템이라면 다르게 도출된다. 송신은 외부로 출력되는 기능이므로 “XXX조회” 또는 “XXX출력”으로 표현하고 “EQ or EO ? ILF”로 도출, 수신은 외부에서 입력되는 기능이므로 “XXX입력”으로 표현하고 “EI ? ILF”로 도출한다.

최근 공공사업에서는 사업대가근거로 제시한 기능점수를 전문기관에 의뢰하여 검증하는 경우가 많다. 이 경우, 기능점수의 원리에서 벗어나는 기능이 도출된 경우 오류로서 지적될 수 있다. 따라서, “사용자 입장에서 의미있는 이름”으로 기능을 표현하는 것이 중요하다.

데이터 기능의 도출

-?????? 데이터 기능은 대부분 트랜잭션기능에서 도출된다.

-?????? 트랜잭션기능의 이름은 대부분 “목적데이터” + “동사형”으로 표현되는데, “목적데이터”부문이 데이터 기능으로 도출된다.

-?????? 또한 트랜잭션기능과 마찬가지로 이 데이터 기능은 물리적인 데이터가 아니다. 즉, 요구되어진 모든 “정보”가 데이터 기능으로 도출되어야 한다.

-?????? 즉, 요구사항 문장에서 데이터를 뜻하는 명사가 모두 트랜잭션기능으로 도출될 가능성이 높다.

-?????? 다시 강조하자면, 데이터기능의 논리파일은 추후 주로 데이터베이스의 테이블이 되지만, 논리파일을 테이블로만 봐서는 안되며, 각 기능에서 유지관리되거나 조회되는 모든 논리적인 정보를 논리파일로 도출한다.

-?????? 즉, 시스템의 상태정보, 송수신데이터 등 사용자가 인지가능한 모든 정보를 도출한다.

즉 위 설명을 요약하면, 기능은 아래와 같이 도출된다.

예
기능명	트랜잭션기능	데이터기능
사용자 관리	사용자관리	사용자
연락처 조회	연락처조회	연락처

이렇게 도출된 각 기능을 엑셀 또는 다른 도구를 이용하여 정리한다. 이때, 데이터 기능은 모두 취합하여 중복을 제거한 후 정리한다.

트랜잭션 기능

데이터 기능

앞에서 설명한 바와 같이 기능명은 사용자에게 인지 가능한 기능을 사용하여야 한다. 트랜잭션 기능의 유형을 고려했을 때, 기능점수의 검증에서 문제가 되지 않기위해서는 될 수 있으면 아래의 동사형을 사용하는 것이 권장한다.

기능명	설명
관리	생성/수정/삭제와?조회기능을?모두?가지는?관리기능
입력	정보의 생성기능
수정	정보의 수정기능
삭제	정보의 삭제 기능
검색	정보의 검색과 상세정보 조회 기능
조회	단일 정보의 조회 기능
통계	통계의 산출과 표시 기능
산출	정보의 산출(수학적?계산)과?표시 기능 ?
계산	정보의 산출(수학적?계산)과?표시 기능 ?
현황	목록성 정보의 조회 기능
출력	정보의 인쇄/출력기능
인쇄	정보의 인쇄/출력기능
로그인	사용자의 로그인 기능
선택	리스트, 콤보 등의 목록에서 항목을 선택하는 기능
저장	내부 시스템에 정보를 저장하는 기능
송신	내부시스템에?데이터를?송신하거나?저장하는?기능 사용자입장에서의 다른 이름을 사용하기를 권장함 (내부시스템끼리의 송수신은 기능점수에서 기능유형으로 도출되지 않음)
수신	내부시스템으로부터?데이터를?수신하거나?조회하는?기능 사용자입장에서의 다른 이름을 사용하기를 권장함 (내부시스템끼리의 송수신은 기능점수에서 기능유형으로 도출되지 않음)
현황조회	단일 또는 목록성 정보의 조회 기능
내역조회	목록성 정보의 조회 기능
연계송신	외부시스템에?데이터를?송신하는?기능 “외부출력” 또는 “외부조회”를 사용하기를 권장함
연계저장
외부송신
연계수신	외부시스템으로부터?데이터를?수신하거나?조회하는?기능 “외부입력”을 사용하기를 권장함
연계조회
외부수신
외부출력	외부시스템에?데이터를?송신하거나?저장하는?기능
외부입력	외부시스템으로부터?데이터를?수신하거나?조회하는?기능
연계	외부시스템과의?연계기능 -외부입력, 외부출력과동일? “외부입력” 또는 “외부출력”을 사용하거나, 기능유형에 외부출력과 외부입력 모두를 계산

트랜잭션 기능의 유형 결정

-?????? 트랜잭션기능과 데이터 기능의 목록을 도출하였다면, 각 기능별 유형을 결정한다.

-?????? 트랜잭션과 데이터 기능은 각각의 고유한 유형을 가지므로 각각 작업을 하면 된다.

-?????? 우선 트랜잭션 기능은 각 기능의 CRUD(생성/조회/수정/삭제) 만을 고려하므로, 기능이 가지는 특성에 따라 CRUD의 수를 각각 산출한다.

-?????? 각 CRUD 특성은 다수가 산출되어도 무방하다. 기능이 가지는 입출력 기능 모두를 산출한다.

-?????? 아래와 같이 표형식으로 정리하면 편하게 작업할 수 있다.

기능명		외부입력			외부출력	외부조회
기능명		입력	수정	삭제	외부출력	외부조회
시스템관리	사용자관리	1	1	1		2
?	부서관리	1	1	1	?	2
전자결재	결재문서조회	?	?	?	?	2

-?????? 위 예에서 사용자관리는 CUD를 모두 포함하므로 모두 1을 입력하였고, 검색 및 상세정보조회를 가지므로 외부조회가 2가 되었다.

데이터 기능의 유형 결정

-?????? 데이터 기능도 트랜잭션과 동일한 방법으로 유형을 결정한다.

-?????? 데이터 기능은 ILF와 EIF만을 결정하면 되므로, 내부데이터인지 외부데이터인지만을 판단하여 아래와 같이 표로 작업한다.

데이터	내부논리파일	외부연계파일
데이터	내부논리파일	외부연계파일
사용자	1
부서	1	?

기능점수의 산출

-?????? 위의 모든 작업을 완료하였다면, 기능점수는 쉽게 도출된다.

-?????? 간이법을 기준으로 하는 경우, 각 기능유형에 따라 미리 정해진 평균복잡도 점수를 적용해주면 된다.

-?????? 즉, 각 유형(EI/EO/EQ/ILF/EIF) 별 합산을 구하고, 각 유형별 합에 평균 복잡도 점수를 곱한다.

-?????? 최종 기능점수는 이 점수들의 합이다.

-?????? 이는 엑셀로 스크립트를 작성하면 자동으로 산출할 수 있다.

-?????? 아래와 예와 같이 산출한 유형의 합을 구한다.

기능명		외부입력			외부출력	외부조회
기능명		입력	수정	삭제	외부출력	외부조회
시스템관리	사용자관리	1	1	1		2
?	부서관리	1	1	1	?	2
전자결재	결재문서조회	?	?	?	?	2
합계		6			0	6

데이터	내부논리파일	외부연계파일
데이터	내부논리파일	외부연계파일
사용자	1
부서	1	?
합계	2	0

-?????? 각 기능유형별 평균복잡도 점수는 아래와 같다.

기능유형	EI	EO	EQ	ILF	EIF
평균복잡도	4.0	5.2	3.9	7.5	5.4

-?????? 즉, 위의 예에서 최종적으로 기능유형별 합계와 평균 복잡도를 곱하면 총 기능점수는 아래와 같이 계산된다.

기능유형	평균복잡도			합계
외부입력(EI)	6	X	4.0	24.0
외부출력(EO)	0	X	5.2	0.0
외부조회(EQ)	6	X	3.9	23.4
내부논리파일(ILF)	2	X	7.5	15.0
외부연계파일(EIF)	0	X	5.4	0.0
총합				62.4

-?????? 즉, 총 기능점수는 이 경우, 62.4점이 된다.

요약

위에서 설명한 기능점수를 산출하는 순서를 요약하자면,

요구사항으로부터 트랜잭션기능과 데이터기능의 목록을 도출하여 정리한다.

트랜잭션기능과 데이터기능의 유형을 결정한다.

기능유형별 합산에 평균복잡도를 곱하여 총합을 구한다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%8b%a4%ec%a0%84-3-%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%b8%a1%ec%a0%95%eb%b0%a9%eb%b2%95/

기능점수 산출 실전 – 2. 기능점수란?

JaeSoo — Wed, 26 Mar 2014 10:09:55 +0000

기능점수(Function Point, FP) 방법은 사용자 관점에서의 요구 기능을 정량적으로 산정하여 소프트웨어 규모를 측정하고, 이를 바탕으로 소프트웨어 개발과 유지보수를 위한 비용과 자원 소요를 산정하는 방법이다. 즉, 기능점수는 측정의 일관성 유지를 위하여 소프트웨어 개발기술, 개발방법 등은 고려하지 않고 소프트웨어에 요구되어진 “요구사항의 복잡도”를 측정한다. 쉽게 말해서, 복잡하고 많은 요구사항을 가진 소프트웨어일수록 더 많은 점수를 가지게 되는 방식이며, 철저히 요구사항 위주의 측정방식이다.

사실 이 방식은 소프트웨어 분석단계에서도 그대로 적용하는 것이 맞다. 대부분 소프트웨어 개발에서 개발방법론의 잘못된 이해로, 분석 단계에서의 기능 도출을 물리적인 단위로 도출하는데, 이는 잘못된 것이며, 요구사항을 분해하여 논리적인 최소 업무단위로 도출하는 것이 분석단계의 업무기능분해/프로세스정의로 볼 수 있다. 프로젝트 초기에 기능점수를 잘 도출하였다면, 사실 분석단계에서 이를 그대로 사용할 수도 있다.

?기능점수 방법은 다음과 같은 특징을 가진다.

소프트웨어가 사용자에게 제공하는 기능적 요구사항을 측정한다.

-??????? 구현될 기능이 아니라 사용자가 요구한 기능이 어떤 것인지를 기능으로 도출하여야 한다.

-??????? 따라서, 도출되는 기능은 반드시 사용자에게 “의미”있는 것이어야 한다.

-??????? 즉, 사용자가 “인지”할 수 있는 기능이어야 한다.

기능점수는 “소프트웨어가 어떻게 구현되었는지”의 공급자 관점이 아니라 “사용자가 어떠한 기능을 요구했는지”의 수요자 관점에서 측정한다.

-??????? 반드시 기능은 사용자에게 인지될 수 있어야 하며, 개발자 측면에서 필요한 기능들은 도출되지 않는다. (공용모듈 등)

-??????? 기능은 사용자가 요구한 논리적인 업무의 최소단위이다.

-??????? 이는 개발방법론의 프로세스 분해와 매우 유사한 의미이다.

개발이전에 업무량을 측정할 수 있다.

개발은 물론 계획, 운영 등 전 수명주기에 걸쳐서 측정 가능하다.

소프트웨어 개발 및 유지보수의 업무량을 조직, 구현 기술, 공수 적용 방법론, 물리적 또는 기술적 컴포넌트와 무관하게 일관성 있게 측정할 수 있다.

기능을 실제 프로그램이 어떻게 구현될 것인가를 고려하여 도출하면 안된다. FP의 기능은 반드시 논리적인 사용자 측면에서의 기능, 즉 사용자가 인지 가능한 논리적인 최소 단위를 도출하여야 한다.

따라서, 개발시 구현되는 물리적인 모습이 FP에 반영되어서는 안된다.

또한, 반드시 사용자가 인지 가능한 기능만이 포함되어야 한다. 이는 FP의 정의가 사용자관점에서의 요구기능을 측정하는 것이기 때문이다.

위에서 설명한 것을 요약하자면,

기능점수 = 소프트웨어의 기능(Function)이 얼마나 복잡한가를 점수(Point)로 표현한 것

으로 설명할 수 있다. 즉, 어떤 소프트웨어 기능을 아래와 같이 얼마나 복잡한가를 판단하여 점수를 매기는 것이다.

따라서, 기능점수는 기능을 도출하는 방법과 각각의 기능이 가지는 유형을 정의하고 있으며, 각 유형별의 복잡도에 따라 점수를 매기는 법을 정의하고 있다.

기능점수를 설명하는 많은 자료는 주로 점수를 매기는 법에 대하여 설명하고 있다. 사실 기능점수를 처음 접하는 개발자라면, 이 점수체계가 매우 복잡하게 느껴질 수 있지만, 이는 어떤 규칙에 의하여 결정되는 것이므로 도구나 엑셀 등으로 쉽게 처리할 수 있다.

오히려 실제 기능점수 도출에 어려운 것은 점수의 도출이 아니라 “기능의 도출”이다. 이는 사실 어떤 자료에서도 제대로 설명해주지 않고 있으며, 대부분 기능점수 도출에서 잘못 도출되고 있는 부분이다.

“기능의 도출”은 사실 소프트웨어 분석에 해당하는 부분이며, 실제 소프트웨어 개발 프로세스에서의 분석도 잘못이루어지고 있는 경우가 많다. 따라서 이 글 전반에 걸쳐서, 기능은 “사용자의 요구”를 뜻하는 것이라고 반복적으로 강조하고 있다. 사실 거의 대부분 기능도출에서 이 부분이 잘못되고 있기 때문이다.

기능점수의 구성

위에서 기능점수는 기능을 도출하고 각 기능이 가지는 유형에 의하여 점수가 결정된다고 설명했다. 즉, 이미 기능이 도출되어 있는 상태라면, 각각의 기능이 가지는 기능유형만 알면 기능점수가 측정될 수 있다. (사실 뒤에 설명하는 간이법을 사용하면 유형결정 즉시 기능점수가 완료될 수 있다.) 각 기능이 가질 수 있는 유형은 아래 그림과 같다.

1.???? 데이터 기능

기능 점수에서 기능은 크게 “데이터기능”과 “트랜잭션기능”으로 나누어 진다. 사실 우리가 기능으로 생각하는 것은 트랜잭션 기능인데, 데이터 기능은 “사용자가 요구한 정보”를 의미한다. 즉, 사용자가 필요로 하는 데이터단위를 하나의 기능으로 인지한다는 것이다.

따라서, 실질적으로 기능점수를 도출할 때, 하나의 요구사항은 대부분 하나의 트랜잭션기능과 하나의 데이터기능으로 도출된다.

(예) 사용자조회 = 사용자조회(트랜잭션기능) + 사용자(데이터기능)

데이터 기능은 다시 아래의 두가지 유형으로 나뉘어진다. 즉, 단 두가지 유형만을 가지니 둘 중하나로 결정하면 된다.

내부논리파일(Internal Logical File : ILF)

-?????? 사용자관점에서 식별가능한 논리적으로 연관된 하나의 데이터 그룹

-?????? 제어정보로서 측정대상 어플리케이션 내부에서 유지되는 파일

-?????? 즉, 기능점수 측정 대상 시스템 내부에서 관리되는 데이터를 의미

-?????? 이는 데이터베이스의 테이블일 경우가 많으나, 시스템 내부에서 다루는 모든 데이터 그룹이 ILF로 도출될 수 있다. 즉, 테이블이 아닐수도 있다.

-?????? 즉, 시스템 내부에서 다루는 파일, 클래스, 외부 인터페이스를 위한 Structure 등이 ILF가 될 수 있다.

-?????? 외부 인터페이스의 경우, 인터페이스의 주체가 내부시스템인 경우, 송수신데이터는 ILF로 도출된다.

외부연계파일 (External Interface File)

-?????? 측정대상 어플리케이션 내부에서는 오직 참조만 되고 다른 어플리케이션에서 유지되는 파일

-?????? 즉, 외부 연계 시스템에 존재하는 데이터

쉽게 말하자면, 이번 프로젝트에서 생성하여 관리하는 데이터는 ILF이고, 이번 프로젝트에서 만들지 않고, 다른 프로젝트에서 생성하였으나 이번 프로젝트의 기능이 참조(연계)하는 데이터는 EIF이다.

2.???? 트랜잭션 기능

트랜잭션 기능은 우리가 일반적으로 생각하는 업무기능이다. 기능점수에서 트랜잭션 기능의 복잡도는 단지 기능이 입력이냐 조회냐에 의하여만 결정한다. 즉, 정보를 관리를 하는 기능이냐, 정보의 조회만 하는 기능이냐를 구분하여 이에 따라 복잡도를 결정한다.

따라서 아래의 세가지 유형을 가지며, 기능점수 산출 시, 각 기능이 이 세가지 유형을 몇 개나 가지느냐에 따라 복잡도가 결정된다.

외부입력 (EI, External Input)

-?????? 어플리케이션 경계 밖에서 들어오는 데이터나 제어정보를 처리하는 단위프로세스

-?????? 하나 이상의 논리파일을 변경하거나 시스템 동작을 변경함

-?????? 즉, 특정 데이터를 특정 논리적인 파일(ILF, EIF)에 저장하는 기능

-?????? 데이터베이스 관점에서는 Create, Update, Delete에 해당함

-???????외부연계 입장에서는 수신은 외부시스템으로부터 데이터가 입력되므로 EIF에 대한 EI에 해당함

외부출력 (EO, External Output)

-?????? 데이터나 제어정보를 사용자에게 보여주는 프로세스

-?????? 처리로직은 하나 이상의 수학적 계산, 공식 또는 파생 데이터를 포함하거나,

-?????? 하나 이상의 내부논리파일의 유지관리 작업이 발생하거나 시스템의 동작 변경이 수반됨

-?????? 즉, 통계와 같이 데이터를 수학적인 계산에 의하여 처리하여 표시하는 경우에 해당함

외부조회 (EQ, External Inquiry)

-?????? 데이터나 제어정보를 단순히 사용자에게 제공

-?????? 즉, 검색이나 정보조회와 같이 단순히 데이터를 조회하여 그대로 표시하는 경우에 해당함

-???????외부연계(I/F)의 경우, 송신프로세스는 외부시스템에 정보를 출력하는 경우에 해당하므로 ILF에 대한 EQ에 해당함

즉, CRUD(Create,Read,Update,Delete) 중 CUD는 EI 이며, R은 통계형식일 때 EO, 단순조회일 때 EQ이다. 사실 이 부분은 기능이 도출되면 매우 명확하기 때문에 쉽게 도출가능하다. 또한 하나의 기능이 하나의 유형만을 가지는 것이 아니라, 여러가지 유형을 모두 가지는 경우, 각각을 모두 점수에 합산하게 된다. (관리 기능은 CRUD를 모두 가지므로 EI가 3개, EQ가 1개로 표현된다.)

트랜잭션 기능 유형의 규칙

트 랜잭션 기능의 유형을 살펴보면 모두 “외부(External)”이 붙어 있음을 알 수 있다. 이 “외부”는 측정하고자하는 시스템 입장에서의 “외부”이다. 즉, 기능점수는 시스템의 기능입장에서 (시스템이 1인칭이다.) 외부와 내부를 구별하여 그 관계를 유형으로 결정하는데, 모든 기능유형이 “외부”가 붙어 있다는 것은 시스템의 외부와 어떤 입출력이 이루어져야만 기능으로 인정한다는 것을 나타낸다.
즉, 시스템 입장에서 외부에서 입력이 이루어지거나 시스템의 외부로 정보가 출력되어야만 기능으로 본다는 것이다.

여기서 시스템의 외부는 사용자 또는 연계되는 다른 시스템 등이 될 수 있다. 즉, 기능점수의 기능유형은 시스템이 외부와 통신할 때만 측정되며, 내부에서 일어나는 트랜잭션은 기능으로 측정하지 않는다.
대부분의 시스템외부는 사용자가 될 것이므로, 서두에서 얘기한 “사용자에게 의미 있는 기능만을 측정”한다는 것은 바로 이 원리 때문이다.

기능점수의 종류

기능점수 산출방식은 상황에 따라 여러가지 방법이 존재한다.

1. 간이법 / 정통법

국내에서 주로 사용되고 있는 기능점수 방식은 “간이법”이다. 영어로 표현하자면 “Estimate(추산)”인데 영어식표현이 더 정확한 의미를 전달하는 것 같다. 이는 프로젝트 초기 단계에서 각 기능의 정확한 요소를 모르는 경우, 유형별 평균적인 점수를 지정하여 사용하는 것이다.

현재 국내의 소프트웨어 대가 산정시 이 간이법을 기본으로 사용하며, 한국소프트웨어산업협회에서 간이법 사용시의 유형별 평균복잡도 점수를 표준으로 제시하고 있다. 따라서 기능점수 산출시에 이 가이드에 따라 점수를 책정하면 되며, 이후 모든 기능점수 산출에 관한 설명은 “간이법”을 기준으로 한다.

정통법은 위에서 설명한 각 유형에 각 기능이 사용하는 데이터요소의 수를 이용하여 복잡도를 계산한다. 따라서, DET/RET/FTR 등의 추가적인 개념을 알아야 하는데, 이와 같은 데이터요소의 수는 설계가 완료되기 이전에는 도출되기 힘드므로 정통법은 프로젝트 초기 단계에서 잘 사용되지 않는다.

사실 간이법은 각 유형에 따른 평균적인 데이터요소 수를 지정하여 평균점수를 책정한 방식이다.

2. 신규개발 / 재개발

기능을 모두 신규로 개발할 때와 기존에 존재하는 기능을 재개발할 때는 다른 산출방식을 사용한다. 위에서 설명한 것은 모두 신규개발 방식이며, 재개발은 신규개발 시에 비교하여 설계와 코드/시험이 얼마나 변경되는 가의 비율을 산출하여 측정하게 된다. 재개발 기능점수 산출방법은 후에 다시 설명하기로 한다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%8b%a4%ec%a0%84-2-%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98%eb%9e%80/

전사적 자원 관리(Enterprise Resource Planning, ERP)의 개요, 회계 및 인사프로세스, 물류 프로세스, 구축전략, 확장(Extended), 패키지(Package) 선정

JAESOO — Tue, 11 Mar 2014 14:19:09 +0000

=목차

I. ERP의 개요 (I. ERP의 개요_200902_03.pdf)

II. ERP와 회계 및 인사프로세스 (II. ERP와 회계 및 인사프로세스_200903_03.pdf)

III. ERP와 물류 프로세스 (III. ERP와 물류 프로세스_200903_03.pdf)

IV. ERP구축전략 (IV. ERP구축전략_200904_03.pdf)

V. Extended ERP (V. Extended ERP_200904_03.pdf)

VI. ERP Package 선정 (VI. ERP Package 선정_200905_03.pdf)

출처 : http://magazine.infoever.co.kr/ (인포웹진 115호~125호)

ISP(Information Strategy Planning, 정보전략계획)의 이해와 단계별 체크포인트

JAESOO — Tue, 11 Mar 2014 14:01:01 +0000

ISP-정보시스템 구조정의

정보전략계획(ISP)의 이해와 단계별 체크포인트

ISP (Information Strategy Planning : 정보전략계획)

IT 정보전략계획 (ISP)

[1주차]isp의_이해와_단계별_체크포인트.pdf

출처 : http://bluebreeze.co.kr/540

EA(Enterprise Architecture)의 이해, 전략, 구축(BA, AA)

JAESOO — Tue, 11 Mar 2014 13:53:21 +0000

=목차

I. EA의 이해 (I. EA의 이해_200905_03.pdf)

II. EA 전략 (II. EA 전략_200906_03.pdf)

III. EA 구축 (BA) (III. EA 구축 (BA)_200906_03.pdf)

IV. EA 구축 (AA) (IV. EA 구축 (AA)_200907_03.pdf)

‘EA의 이해’ 시간에는 EA에 대한 이해를 돕기위하여 EA에 대한 개괄적인 내용을 알아본다.
이번 장의 목적은 :
1. EA의 개념과 효과에 대하여 간략히 알아보고,
2. EA의 구성요소를 정의하고 각구성요소의 역할을 살펴본다.
3. EA의 도입방안에 대하여 주요고려요소 등을 살펴본다.
4. 국내외의 EA 사례와 동향을 살펴본다.
5. EA 추진전략 및성공전략에 대하여 토의해 본다.
이번 장을통해 EA의 개념으로부터 동향에 이르기까지전반적인이해를 높일수 있을 것이다

출처 : http://magazine.infoever.co.kr/ (인포웹진 121호~124호)

조달청 투찰(전자입찰)방법

JaeSoo — Tue, 03 Dec 2013 10:54:25 +0000

조달청 투찰(전자입찰)방법

전자입찰에 참가하시려면 우선 공인인증서가 설치되어야 하고 각 전자입찰 싸이트에 업체등록이 되어있으셔야 합니다.

대표적인 전자입찰싸이트는 나라장터입니다. 나라장터를 예로 들면

나라장터(www.g2b.go.kr)를 이용하여 공공기관에서 시행하는 입찰, 계약등에 참가하기 위해서는

먼저 공인인증기관 홈페이지를 방문하여 공인인증서를 발급받으신 후에

나라장터 홈페이지에서 국가종합전자조달시스템입찰참가자격등록규정에 의거 신규등록을 하셔야 합니다.

1. 공인인증서 발급

2. 입찰참가자격등록신청

공공기관에서 집행하는 입찰에 참여하고자 하는 자는 나라장터(www.g2b.go.kr)에 접속

(이용자등록-조달업체이용자-경쟁입찰참가자격등록신청)하여 경쟁입찰참가신청서에

물품, 공사, 용역의 해당부분을 입력하여 전송한 후 시행문과 함께 증빙서류를 입력

전송한 해당 지방조달청에 우편 발송 또는 방문 제출하여 주시기 바랍니다.

- 시설업체등록시 필요서류

가. 사업자등록증

나. 법인인 경우 법인등기부 등본, 개인인 경우 주민등록등본

다. 인감증명서 및 사용인감계

라. 허가, 인가, 면허, 등록, 신고증 또는 기타 필요한 자격의 해당업등록증

※ 각 증명서류 사본에는 반드시 증명인감으로 "사실과 상위없음"을 날인하여야 합니다.

3. 적정여부 검토 (조달청 담당자)

등록 담당자는 경쟁입찰참가자격등록신청서의 내용과 구비 서류를 확인하여 등록 요건에

부합되면 확정 등록하여 드립니다.

가. 증빙서류에 "사실과 상위없음"을 날인하는 도장은 인감증명서상의 도장으로 날인

나. 등록신청서를 작성하여 전송한 해당 청에 증빙서류(출력한 시행문의 붙임서류 참조)를

제출하여만 등록 가능

다. 한번 등록된 업체는 이중등록이 안되오니 기 등록된 업체는 기존등록 화면에서 변경등록신청

4. 입찰참가자격 확정등록 (조달청 담당자)

가. 신청내용과 증빙서류가 모두 일치되는 경우는 전부등록에 의거 확정등록

나. 신청내용과 증빙서류가 대부분 일치되는 경우는 그 부분에 대하여 확정등록하고

미흡한 부분에 대하여는 추후 보완하여 변경등록 토록 업체에 안내

다. 신청내용과 증빙서류가 부문 또는 전부에 대하여 확정등록이 불가능한 경우 보완 요구

5. 등록신청확인(업체)

이용자등록-조달업체이용자-등록신청확인 및 시행문 출력에서 신청내용의 진행상태

(대기/승인/보류/반려)확인 가능합니다.

6. 인증서 등록

경쟁입찰참가자격등록이 되면 이용자등록-조달업체이용자-인증서관리-인증서신규등록에서

사용자 정보와 인증서를 등록하여야만 공공기관에서 집행하는 입찰에 참여 가능합니다.

7. 로그인

인증서의 비밀번호를 넣고, 나라장터에 등록된 인증서를 선택하여 로그인

8. 공고조회 및 투찰 (G2B 시스템 이용)

입찰정보 - 물품(시설,용역 중 택1) 로 들어가셔서 참여하고자하는 공고 조회, 확인 후

입찰참여(투찰) 등 G2B 시스템을 이용할 수 있습니다.

신규업체등록과정중 입찰참가자격등록신청서 작성하여 송신 과정 중 인증서를 확인하는 부분이 있습니다.

따라서 입찰참가자격등록신청을 할 경우에는 인증서가 있는 컴퓨터에서 작업하셔야 합니다.

또 인증서등록과 로그인도 마찬가지로 인증서가 있는 컴퓨터에서 작업이 가능합니다.

위 과정이 끝나셨으면 회원님께서 참가하고자하는 입찰을 검색하셔서 투찰을 하셔야 합니다.

투찰가격은 기존의 직찰이나 수의등의 입찰방법과 같습니다.

차이점은 직찰은 직접 발주지관에 투찰을 하시는것이고 전자입찰은 나라장터에 접속하셔서

온라인으로 투찰을 합니다.

신규업체등록과정중 입찰참가자격등록신청서 작성하여 송신 과정 중 인증서를 확인하는

부분이 있습니다.

따라서 입찰참가자격등록신청을 할 경우에는 인증서가 있는 컴퓨터에서 작업하셔야 합니다.

또 인증서등록과 로그인도 마찬가지로 인증서가 있는 컴퓨터에서 작업이 가능합니다.

신규업체는 실적이 없기때문에 금액이 금액에 따라 차이가 있습니다.

소액이나 수의, 관내 입찰등 작은 금액의입찰부터 참가하셔서 실적을 차곡차곡 쌓으시길 바랍니다.

출처 : http://blog.daum.net/scr007/3

ERP? MIS? SIS? BPR?

JaeSoo — Mon, 11 Nov 2013 22:36:17 +0000

1. ERP의 이해와 활용

1. MIS, BPR, SIS, ERP?

기업을 경영함에 있어서 정보시스템이 차지하는 비중은 날로 증대되고 있는 것이 사실인데, 이런 가운데 새롭게 등장하는 이론과 기술, 기법들에 민감해 하고 마치 새롭게 떠오르는 이러한 신조어들에 대해 사내에 적용하지 않으면 왠지 뒤떨어지는 것과 같은 심정인 독자가 있다면 '조삼모사'라는 숙어를 되뇌어 보길 권장하고 싶다. 즉, 경영정보시스템(MIS)이나 BPR, 전략정보시스템(SIS), 전사적 자원관리(ERP) 등은 모두 궁극적으로 경영의 효율을 극대화하고자 하는데 그 목적이 있다면 모두 같은 말이요, 정보시스템을 어떤 방식으로 적절히 이용하여 경영에 도움을 줄 것인가라는 면에서는 서로 공통점이 있다고 할 수 있다. 단지 이들의 장단점이 있을 뿐이며 이들이 중요시하는 관점이 어디에 있는가에 따라 또, 탄생된 기기에 따라 이름이 달리 불리우게 된 것 뿐이다.

이를 Business Process 측면과 Information Technology 측면에서 굳이 구별을 하자면 (그림1)과 같이 구분할 수 있겠다. 이들 중 비교적 먼저 경영에 적용되기 시작했던 MIS는 기존의 Process를 최대한 준수하면서 정보기술 특히, HOST중심의 단위 업무만을 처리했던 관점이었다면, BPR은 Process 중심으로 경영혁신을 도모하면서도 정보시스템의 이용이 부차적인 관점에서 정립한 것이라고 할 수 있을 것이며, 이후 각광을 받았던 SIS는 다양한 정보기술의 이용을 적극적으로 도입하여, 이익 극대화를 추구하였기 때문에 Ⅲ의 위치에 있으면서도 일정 부분은 Process를 혁신하기도 하였으므로 Ⅳ의 위치에 있다고 볼 수 있다. 그러나 이렇게 발전해온 기술과 기법이 혼재 되면서 구축된 정보시스템을 뒷받침하던 Process의 공통적 부분이 표준화되고 이것이 Package형태를 띠면서 ERP라는 새로운 영역의 Software가 등장하게 된 것이다.

2. 사례는 많은데 왜 모범 사례는 적은가?

이러한 ERP는 많은 장점을 갖고 있으면서도 기존의 MIS나 BPR, SIS의 많은 단점을 보강해주는 강력한 위력을 갖고 있는데 그렇다면 이를 통해 성공한 기업이 과연 우리 주변을 둘러 보았을 때 얼마나 되는가 보면 대체로 '사례는 많은데 성공 사례는 많지 않다'고 하는 것이 잠정적 결론인 것 같다.

그러나 이렇게 단정적으로 결론을 짓고 아예 ERP Package를 처음부터 고려치 않거나 도입에 너무 신중을 기하는 것도 좋지 않을 뿐만 아니라, 마치 유행인 것처럼 Test 차원에서 일부 업무(모듈)에 한하여 ERP Package를 도입한 후 결과를 평가하는 것도 바람직하지 않다. 그러나 이와 같은 결론에 대한 근거가 없는 것도 아니라고 판단된다.

즉, 대부분의 ERP는 외국 Package를 한글화하여 도입한 것이기 때문에 이를 적용함에 있어 국내 사용자의 업무적 관행이 빨리 바뀌지 않아 사용자로부터의 불만이 표출되어서 이기도 하고, ERP란 말 그대로 전사의 자원을 통괄적으로 관리하는 System을 말하고 있기 때문에 이를 뒷받침하기 위해서는 기본적으로 Systemic하게 설계된 기능들이 쉽게 변하지 않는 사용자의 업무적.관행에 맞추기 위해 무리하게 Customize한 결과로 ERP에 대한 다소의 부정적 견해를 낳게 했다고 볼 수 있다.

3. 성공적 ERP 도입을 위한 조건

①도입에는 최고 경영자의 의지, 추진에는 프로젝트 리더의 지혜

② 통합의 관점을 잊어서는 안된다

회계 시스템, 영업 관리 시스템, 재고관리 시스템 등 data통합이 되지 않아서 발생하는 제반 비효율적 문제는 대부분 ERP를 도입하는 기업의 공통적 문제이다. 특히 IMF시대에 접어든 환경을 극복하기 위해 필연적으로 개선하여야 할 문제는 바로 통합적 시스템에 의한 비능률적 요소를 제거하는 것이다.

③ 정보시스템인 만큼 사용자의 편의성과 효과적 운영을 고려해야 한다

사용자가 자신이 사용할 시스템에 만족하지 않을 경우 시스템의 성공에는 매우 불리하게 작용하게 된다. 특히 국내 사용자는 서식에 민감하여 결재 처리 등 업무적 관행을 중요시할 수 밖에 없는 상황에 있는 만큼 이를 최대한 반영한 Package를 선택하고 Customize할 수 있도록 하는 것은 ERP 성공에 중요한 고려 요소인 것이다.

④ 목적을 명확히 할 것

도입 기간이 중요한가? 아니면 BPR의 효과가 중요한가? 경영자의 의사결정을 지원하는 시스템이 중요한가? 단기적으로, 중장기적으로 취해야 할 목표는 어디에 둘 것인가? 또한 좀 더 세분화한 목적으로는 BPR에 목적을 둘 경우 경쟁력 강화 위한 내부 업무 프로세스의 개선이나 비용절감 등이 세분화 된 목적이 될 수 있을 것이다.

⑤ 화이트 칼라가 대상이다

화이트 칼라가 하는 일 중 약 20%의 일은 중요한 일의 보조적 일인데 이 업무를 위해 업무 시간의 80%를 소모하고 있는 것이 우리 기업의 현실이다. 그러므로 영업이나 생산 현장의 업무를 Target으로 하는 MIS, BPR, SIS와는 다르게 원장형 Data 공유를 통한 불필요 업무를 없애고 중복적 업무를 일원화, 사전적 문제 해결 등을 해나가는 사무 생산성 개선의 실질적 대안이라고 할 수 있으며 이를 확대하면 IMF시대를 이겨나가는 궁극적 대책이라고도 할 수 있을 것이다

전사적 자원관리 SYSTEM (Enterprise Resource Planning)1. 선진 프로세스로서 기 검증되어있는 시스템이다.2. 표준화, 단순화, 통합화를 통한 시너지 효과 증대.3. 기업자원의 효율적 관리를 지원하며, 전 부문의 경영자원을 하나의 통합적 체계의 시스템으로 구축하고 생산성 극대화 및 COST 최저화 실현.

출처 : http://lunastar.tistory.com/132

CRM, ERP, MIS의 차이점

JaeSoo — Mon, 11 Nov 2013 22:33:56 +0000

우선, CRM은 Customer Relationship managemnt 의 약자로 고객관계관리라 칭하며,

업의 영역에 관계없이 고객과의 업의 관계를 체계적이고 효율적으로 운영 지원해 주는 경영기법으로 보면 될 것 같습니다... 흔히, 지인정보, 업체정보, 영업정보, 디업정보 등을 총체적으로 고객과의 커뮤니케이션을 원할하게 해 주기 위한 기반구조로 보면 되며, 주로 해외 CRM 업체의 솔류션, Siebel(지금은 Oracle에 합병됨), 및 국내 업체로 제시됨.

ERP(Enterprise Resource Planning)의 약어로 전사적 자원관리 라 칭함. 회사 전반적인 영업-생산-조달-물류-배송-자금-재무-회계 등 모든 프로세스화된 툴로서 시스템을 사용함으로써 선진화된 업무 프로세스를 준수하기에 선진 Best Practice가 내장되어 있다고 보시면 됩니다.

MIS는 Management Information System의 약어로, 경영정보시스템이라 칭하며, 사내 전반적인 업무 시스템을 통칭하여 부르기도 하며, 주로, 경영지원 관련 인사-재무-회계-자금 등과 같은 cost부문에 해당되는 시스템루의 통칭으로도 불립니다.

세 가지 모드 경영혁신 툴로 이용되며, 연관 범위로 보면, CRM < MIS < ERP 의 순으로 업무 영역의 범위가 넓고 수준도 깊음.

추세로는 ERP 구축 이후, extended ERP로서 CRM, SCM. SEM 등으로 확산되고 있음.

두서없이 적었지만, 참고하시기 바랍니다...

출처 : http://blog.daum.net/kk241321/7338315

ITSM의 허와 실?

JaeSoo — Tue, 22 Oct 2013 03:03:30 +0000

이번 포스팅에선 ITSM의 허와 실에 대해 아주 주관적인 의견을 적어보고자 합니다.

일단 ITSM이 무엇이고 또 무엇이 좋은지는 대충 저번 포스팅을 통해 눈치챌 수 있습니다.

대부분의 큰 회사나 관공서 등등에서는 ISO 2000인증 및 CMMI 레벨 등을 따기 위해 관련 프로세스 정비와 시스템 도입을 해왔고 또 할 것입니다.

하지만 인증심사만 통과했다고 될 일은 아닙니다. 실재로 ITSM 내재화가 잘 되어야 됩니다. 그리고 인증점검도 1년에 한번 씩 나오기 때문에

드물지만 잘못하면 자격을 박탈당할 수도 있습니다.

근데 ITSM내재화.. 이게 참 어렵습니다.

사실 보통 ITSM을 추진하는 부서나 팀은 실제 개발,운영팀과는 별도로 꾸려져 있습니다.

물론 ITSM추진 부서(혹은 팀)가 개발,운영팀의 업무를 모르는 것은 아니지만

어찌 되었던 프로세스를 만드는 부서와 그 프로세스를 따라가야만 하는 부서로 나뉘어지고

결국 즉 성격은 다르겠지만 갑,을 관계가 만들어 집니다.

여기서 문제가 시작됩니다.

ITSM이란 것이 분명 좋은 것은 맞는데 실제 개발하고 운영하는 사람 입장에서는 여러가지 애로사항이 있습니다.

이해하기 쉽도록 예를 들어 봅시다.

변경에 관해서 살짝 봅시다.

변경관리에 의해 소스의 변경은 반드시 CAB(변경자문위원회)를 통해 승인을 받고

변경을 하고 나면 CRB(변경검토위원회)를 거치게 되어 있습니다.

하지만 아무리 큰 회사도 결국 작은 조직으로 나눠지기 마련인데 그 작은 개발 조직에서 CAB, CRB를 구성해서

변경을 수행하기엔 좀 무리수가 있어보입니다.

그래서 위원회란 이름에 맞지 않게 CAB,CRB를 한 명만 지정하여(관리자급) 해당 기능을 수행하도록 하는 경우가 생깁니다.

만약 한줄만 고쳐서 빨리 릴리즈 되는데 CAB나 CRB를 담당한 분이 부재중이라면,

그럼 상황이 애매해집니다.

더군다나 소스의 릴리즈 내지는 소스를 체크아웃하려면 승인단계를 지나야만 가능하도록 시스템 구현이 되어있기 때문에

(즉 물리적으로 승인이 나지 않으면 소스의 수정 및 반영이 안된다는 이야기..)

개발담당자는 빨리 개발을 해야겠는데 짜증이 날 수 밖에 없습니다.

이런 상황이 자주오게 되면 개발담당자가 자기를 CAB,CRB를 시켜달라고 ITSM주관부서에 요구할 수도 있습니다.

즉 CAB,CRB가 그야말로 형식적으로만 존재하고 개발담당자 본인이 변경을 맘대로 하는 경우도 생깁니다.

이와는 반대로 ITSM주관부서의 애로사항도 있습니다.

보통 SLA계약에서 주요 지표중에 고객요청에대한 납기준수율이란 것이 있습니다.

고객의 요청을 받으면 납기준수일을 정해서 이를 지켜야 된다는 자주 사용되는 지표입니다.

그런데 보통 납기준수율을 거의 99%이상 유지됩니다.

왜일까요? 그만큼 뛰어나게 서비스를 운영하기 때문일까요?

물론 그럴수도 있고 아닐 수도 있습니다.

피터드러커가 말했듯이 측정할 수 없는 건 관리할 수 없다라는 원칙에 따라

고객의 모든 요청은 ITSM에 의거 인시던트로 관리하게 되는데요.

이때 이 정보를 시스템에 입력하게 되어 있습니다.

즉 관련 내용을 ITSM시스템에 입력해야 하는 것인데요.

문제는 납기준수율을 99% 유지하기 위해서 몇가지 꼼수가 가능합니다.

아예 인시던트 등록을 안해서 아예 모수를 낮추는 꼼수가 있을테구요. (물론 이건 CSR처리건수 라는 지표로 보완이 가능할지 모르지만 근본적인 해결책이라 보기는 힘듭니다)

납기준수 날자를 고객과 합의하에 변경을 하는 꼼수가 있습니다. (혹은 합의하지 않고? - 물론 이는 ITSM관리 부서에서 컨트롤해서 잡아내야겠죠)

즉 고객이랑 대화해서 8월2일이 납기인데.. 대화하고 요구사항을 더 듣다 보니 납기준수날자를 8월5일로 미루겠다 그래서 시스템에 납기 날자를 변경하는 것입니다.

이건 당연한거 아니냐? 이게 왜 꼼수냐 할 수 있겠는데요.

보통 고객사와 서비스제공자인 현업개발팀과의 관계가 갑과 을의 관계는 맞지만 서로 같이 일을 많이 하다보면 친해질 수 밖에 없습니다.

그래서 보통 납기준수율을 거의 100%가 될 수 밖에 없는 경우가 의외로 많이 생깁니다.

납기준수율이라는 지표의 존재 이유는 납기준수율이 떨어지면 그 원인을 파악하자는데 있습니다.

인력이 부족한 것이냐? 아니면 요구사항이 너무 많아서 그런 것이냐?

근데 납기준수율은 위의 꼼수들로 인해 거의 99%이상이므로 실제로 인력이 부족하는 등 문제가 생겨도

조기에 발견할 수 없게되고 결국 납기준수율은 별 의미가 없는 지표가 되버린거죠.

이상 두가지의 경우의 예를 들었는데요. 무엇보다 ITSM내재화가 잘 안되고 꼼수가 생기는 이유는

실제로 개발을 진행하거나 서비스를 제공하는 현업개발팀의 이해를 완전히 이끌어내지 못했다는 데 있겠습니다.

무작정 다른 회사들이 한다고 ITSM을 도입하기 전에 충분히 현업개발팀에 대한 교육이 선행되지 않으면

삐걱삐걱될 수 있습니다.

물론 이렇더라도 ITSM도입을 하는 것은 IT관리를 투명화한다는 점에서 적극 추천하고

많은 기업이 이미 시행착오 끝에 지금은 ITSM내재화를 성공적으로 이뤄서 IT서비스 효율이 높아졌다는 것도 사실이지만

위에서 언급한 함정에 빠지지 않도록 노력도 게을리 하지 않아야 겠습니다. :)

변화에 대하여 : http://blog.naver.com/zacra/120197623910

UI/UX에 대한 쉬운 이해 : http://blog.naver.com/zacra/120197578988

대기업 쉽게 취업하는 방법? : http://blog.naver.com/zacra/120126882840

C구조대의 더 많은 정보, 글, 사진은 아래 자밥 스튜디오 페이지에서도 볼 수 있어요 ^^

http://www.facebook.com/zabobstudio

출처 : http://blog.naver.com/zacra/120195678641

ITSM이란 무엇일까?

JaeSoo — Tue, 22 Oct 2013 03:02:30 +0000

혹시 ITSM이라는 것을 들어본 적이 있습니까?

만약 여러분이 IT회사에 다니고 있다면 특히 대기업에 다니고 있다면 대부분 ITSM이란 것을 들어보거나 겪어 본적이 있을 것입니다.

또한 대기업 IT회사를 다니길 희망하는 분이 있다면 ITSM이라는 것을 한 번쯤 짚어보고 넘어가면 참 좋을 것 같습니다 :)

한때 약 4년동안 ITSM을 담당했던 경험을 되짚어보면서 간략히 정리해 보겠습니다.

무엇보다 제가 직접 경험해 본 것을 기반으로 정리하는 것이므로 최신 내용은 아니고 한 3~4년전 내용이라고 생각하시면 되지만

큰 그림을 이해하는 데는 무리가 없을 것이라 판단됩니다.

ITSM이란?

ITSM을 풀어쓰면 IT Servise Management 의 약자입니다. 즉 IT 서비스 관리입니다.

하핫 알고보면 별거 아닙니다. 그냥 그럴듯하게 ITSM이라고 하면 뭔가 있어보이는 그런 것이죠 ㅋ

IT 서비스를 어떻게하면 잘 할 수 있을까? 에 대한 고민을 하자는 이야기입니다.

"뭐야? 고민하기 싫은데?"

걱정하지 마세요 그래서 ITIL 이라는 것이 있습니다.

ITIL은 IT서비스 관리를 어떻게 해야지 좋을까에 대한 고민을 이미 훌륭하신 누군가들이 고민하고 정리해둔 훌륭한한 베스트 프랙티스 모음집인데요.

현재는 ITIL v3가 중점일텐데 4~5년 전에는 ITIL v2였습니다. 실제로 큰 핵심은 v2나 v3나 동일하다고 봅니다.

결론은 ITIL에 의거하여 ITSM체계를 얼마나 잘 갖춰졌느냐가 IT서비스 관리를 잘 하고 있느냐 못하고 있느냐의 판단 기준이 된 것입니다.

그래서 이런 기준으로 인증심사도 있습니다.

ISO 20000 이란 것인데요.

대부분의 대기업이나 관공서등이 이 인증을 많이 받아놓았습니다. 이 인증을 받으면 대외적으로 IT 서비스 관리 체계가 잘 잡혀있다는 것을

증명하는 것이니까요.

그럼 이제 ITSM을 통해 어떻게 서비스를 관리하는지 볼까요?

서비스 딜리버리

일단 IT서비스를 한다는 이야기는 그 서비스를 받는 주체가 있기 마련입니다.

바로 고객입니다.

그럼 고객과 서비스 계약을 해야겠지요?

그 계약서가 SLA 입니다.

Servise Level Agreement 라는 것인데요. 말 그대로 서비스 수준 계약서입니다.

SLA는 이런 내용이 들어가겠죠.

예로 그룹웨어 서비스를 제공한다고 합시다

"그룹웨어 서비스 가용성이 99%이상을 달성해야 한다. 만약 가용성이 떨어지면 패널티 얼마를 물겠다"

말그대로 그룹웨어 접속이 몇일 안되면 SLA위반이 되는 것입니다.

따라서 SLA를 잘 지키기 위해서 이 서비스 수준을 정의하고 잘 관리를 해야 합니다.

이것을 SLM 이라고 합니다. 눈치 채셨겠지만 서비스 레벨 관리 입니다. ㅋ

그래서 SLM은 보통 시스템으로 구축해 두고 각 SLA항목들을 지표로 잘 만들어서 관리를 하고

매년 고객과 협의하에 갱신하거나 유지하게 됩니다.

그렇다면 서비스 레벨을 유지하기 위해서 여러가지 관리체계가 필요하겠지요.

그래서 ITIL v2에서는(v3도 큰 차이는 없습니다) 재무관리, 가용성관리, 용량관리, IT서비스 연속성 관리를 통해

SLM을 지원하도록 되어 있습니다.

재무관리야 돈일테구요,

가용성과 용량 그리고 IT서비스 연속성 관리는 아무래도 서로 연관이 되어있습니다.

이를 ITIL v2에서는 서비스 딜리버리로 칭하고 있습니다.

고객의 요구사항에 맞춰 IT서비스의 내역 및 수준을 정의하고(SLA) 이를 관리하는 것이 핵심입니다.

서비스 서포트

자 그럼 SLM을 통해 SLA를 잘 관리하기 위해서는

실제로 IT서비스를 운영을 잘 해야 할 것입니다.

어떻게 서비스를 지원할 것이냐에 대한 부분이 v2에서는 서비스 서포트 영역이 됩니다.

역시 간단히 정리해 보겠습니다.

일단 IT자원을 어딘가 모아야될 필요가 있습니다.

인력,기기,소스 등 이 모든 것을 CI 즉 구성요소라고 하는데 이를 저장하는 DB가

CMDB라 불리우며 이를 관리하는 것을 형상관리라 합니다.

하지만 상황에 따라 형상관리를 프로그램 소스에 한정되서만 관리하는 경우도 많습니다.

자 그리고 서비스를 지원하려면 가장 먼저 떠오르는게 무엇인가요?

"여보세요?"

그렇습니다. 바로 콜 센터인데요. ITSM에서도 서비스 데스크라는 기능조직이 있습니다.

서비스데스크는 SPOC(Single Poing of Contact) 라고 해서 단일접점을 제공하고 고객의 직접 응대를 담당합니다.

여기서 단일접점이란 고객이 번호하나만 알면 된다는 뜻이기도 합니다.

그럼 서비스데스크 운영요원들은(1선이라고 합니다) 관련 내용을 접수해야겠지요.

고객의 요청이나 장애접수등을 하게되는데요. 이를 인시던트라 합니다.

즉 인시던트 관리를 해야되는데요. 인시던트 관리의 핵심은 가장 빠른 시간 내에 해결하는데 목적이 있습니다.

보통 이미 사전에 쌓인 지식DB등을 통해서 임시방편을 통해서라도 빨리 해결하는데 그 목적이 있습니다.

특히 장애같은 경우.. 그 중에서도 긴급장애 같은 경우는 별도로 프로세스를 마련해서 빨리 대응할 필요성이 있습니다.

또 자주 접수되는 인시던트나 해결책이 보이지 않는 인시던트는 말그대로 문제가 됩니다.

이는 문제관리로 넘어가게 됩니다. 보통 2선에서 처리를 하겠죠 아무래도 1선요원은 전문지식이 2선요원보다는 떨어질테니까요~(인시던트의 경우도 전문지식이 필요하면 그 처리를 1선에서 2선으로 이관하도록 되어있습니다)

문제관리는 인시던트관리에 비해 시간에 쫒기지 않습니다.

문제발생을 최소화 하기위해 근보적인 원인을 찾아야 되는 프로세스가 되겠습니다.

그리고 인시던트나 문제를 해결하기 위해 필연적으로 변경이 뒤따르게 됩니다.

IT서비스관리니 아무래도 소스에 대한 변경이 필요할 수 있겠죠?

그래서 당연히 변경관리가 필요합니다.

그냥 맘대로 변경하는 것이 아니라 엄연히 정해진 변경관리 프로세스를 통해 변경을 수행해야 합니다.

CAB(변경자문위원회), CRB(변경검토위원회)등을 둬서 변경에 대한 승인과 투명성을 증가시키고

적절한 통제로 영향을 최소화시킵니다.

그리고 마지막으로 변경을 다했으면 릴리즈를 해야겠죠.

그래서 릴리즈관리가 들어갑니다.

그리고 서비스 서포트영역 전체는 시스템으로 구현이 되어있습니다.

어때요? 잘 생각해보면 ITSM이라는 것이 그렇게 어려운 개념은 아닙니다.

하지만 IT서비스를 하는데 필요한 요소가 잘 정의되있다는 것을 알 수 있고

한번쯤 시간을 내서 ITSM체계에 대해 공부를 한다면 IT서비스를 운영하는데 큰 도움이 될지도 모릅니다.

정리하면 아래 그림 하나로 설명이 됩니다. (V2 기준입니다)

다음 포스팅에서는 ITSM의 허와 실에 대해 다뤄보겠습니다 ^^

변화에 대하여 : http://blog.naver.com/zacra/120197623910

UI/UX에 대한 쉬운 이해 : http://blog.naver.com/zacra/120197578988

대기업 쉽게 취업하는 방법? : http://blog.naver.com/zacra/120126882840

C구조대의 더 많은 정보, 글, 사진은 아래 자밥 스튜디오 페이지에서도 볼 수 있어요 ^^

http://www.facebook.com/zabobstudio

출처 : http://blog.naver.com/zacra/120195471150

소프트웨어 아키텍처 이론과 실제 > 1부 아키텍처 개요

JaeSoo — Tue, 22 Oct 2013 01:08:45 +0000

본 Post는 서적 "소프트웨어 아키텍처 이론과 실제"에 대한 내용 입니다.

1부 아키텍처 개요

1. 아키텍처 비즈니스 사이클

이책에서는 첫 장에서 소프트웨어 아키텍처의 정의를 아래와 같이 내리고 있다.

"프로그램이나 컴퓨팅 시스템의 소프트웨어 아키텍처는 소프트웨어 구성요소와
그들이 지니고 있는 특성 중에 외부에 드러나는 특성,
그리고 구성요소들의 관계를 표현하는 시스템의 구조나 구조체를 말한다."

위 구문에서 한가지 궁금했던 것은 외부에 드러나는 특성이란 무엇일까?
소프트웨어적인 부분을 정의하고 있기 때문에 내부적으로 구현을 이루고 있는 세세한 특징은 Architecture Core의 역할로 보고 그 보다는 외부에 표현해주어야 할 Interface의 역할 정의가 아키텍처에서 바라보아야 할 것으로 생각된다.

이로써 정의된 Interface를 제공받는 개발자가 1인칭 관점으로 보았을 때의 Software Architecture의 역할 중 하나로 보아야 하겠다.

각각 명확한 목적을 담고 있는 구성 요소를 이루어 내야 할 목표에 맞게 조합하는 구조나 구조체를 공유할 수 있는 수단으로 정의하는 것을 의미할 것으로 본다.

아키텍처의 잘못된 설계의 역사적 예로서 "스웨덴의 전함 바사"를 소개하고 있다.

[이미지 출처: 블로그 "아빠 늑대의 음흉한 둥지"]

바사의 예에서 아키텍트가 놓친 부분은 다음과 같이 정의하고 있다.

아키텍처에 적용 가능한 기술의 사례 확인
아키텍처를 평가할 수 있는 방법
문제점의 빠른 대응을 위한 아키텍처 중심 점진적 개발 기법

위 정의에 대해 아래와 같이 해석해 보았다.

사실, 프로젝트 진입 시 1. 의 경우가 상당히 중요한 작업이다. 예를 들어 DBMS OR-Mapping을 위한 기술을 적용하기 위해 IBatis 를 쓸 것인지 Hibernate를 쓸 것인지를 결정하고 나면 프로젝트 진행 도중에 변경한다는 것은 경우에 따라서는 가늠이 않될 정도의 비용을 초래할 수도 있기 때문에 신중한 결정이 따른다.

이 때, 결정자가 아키텍트가 아니라면 아키텍트는 올바른 결정을 내릴 수 있게 충분한 자료와 사례를 수집 정보화해야 할 것으로 본다. (1.의 정의에 관해)

기술 검토를 토대로 아키텍처가 생성되었다면 이 아키텍처가 우리 모두가 원하는 목표를 충족시킬 수 있을 것인지를 정량적으로 표현할 수 있는 방법을 수립해야 한다. (2.의 정의에 관해)

모두가 수용할 수 있는 아키텍처의 정의가 완성되어 구현에 들어갔을 때 완료시점까지 끊임없이 발생하는 이슈(문제점)들을 아키텍트는 아키텍처가 해결할 수 있는 방법을 제시할 수 있도록 해야 한다.

1.1 아키텍처에 영향을 주는 요인

내가 아키텍트인데 아키텍처를 만드는 작업을 할 때 만들어야 할 아키텍처에 영향, 즉 아키텍처의 결과물에 영향을 주게될 요인들은 무엇이 있을까?

책에서는 아래와 같이 나열하고 있다.

이해관계자
개발 시스템과 관련된 모든 (결과물을 사용할 사용자까지) 사람이나 조직.
이들에게서 요구되는 것들을 아래와 같이 리스트해볼 수 있다.

- Performance
- Reliability
- Availability
- Platform compatibility
- Memory Utilization
- Network Usage
- Modifiablity
- Usability
- Interoperability

책에서는 이와 같은 요구사항을 만족시키기 위한 아키텍트의 작업을 아래와 같이 정의하고 있다.

"아키텍트는 테스트가 가능한 수준까지 작성할 수 있어야 하고, 시스템의 품질속성 간에 상충되는 부분에 대해 합의점을 찾아야 한다."
개발조직
단기사업, 장기 사업, 조직 구성으로 영향을 받을 수 있다.

- 단기적으로 사업을 완성할 수 있는 자산 재 사용성을 고려해야 한다.
- 장기적 목표에도 부합해야 한다.
- 특정 기술을 필요로 하는 하위 시스템 구성을 포함할 수 있는 아키텍처를 수립해야 한다.
배경과 경험
아키텍트의 배경,경험이 수립하려고 하는 아키텍처에 영향을 미친다.

역으로 보자면 아키텍트를 고용하는 사람 입장에서는 가능하면 목표에 부합되는 경험을 가진 아키텍트를 선발하는 것이 위험 부담을 줄일 수 있다는 설명이 되겠다.
기술적 환경
현재 적용하는 시점에서의 업계 표준, SW 공학 기법 등 기술적 환경에 영향 받는다.
기타요인
아키텍트는 다양한 영향 요소들이 상충하여 충돌이 발생할 경우, 이해관계자가 적극적으로 문제해결에 참여할 수 있도록 유도해야 하며, 트레이드오프가 발생할 경우 절충 능력과 협상력, 대화 능력을 갖추어야 한다.
아키텍처의 영향 요인과 순환 관계

-. 아키텍처는 개발 조직 구성에 영향을 미친다.
개발 조직으로부터 피드백을 받게 된다.

- 아키텍처는 개발 조직 목표에 영향을 미친다.

1.2 소프트웨어 프로세스와 아키텍처 비지니스 사이클

아키텍처는 상호간의 피드백 관계를 형성하는데 다음과 같은 수립 확동이 있다.

사업 기회 창출
미래의 요구사항을 포함할 수 있는 아키텍처 수립
요구사항 이해
각종 명세 언어, 현행 유사 시스템과의 비교, 프로토타입의 개발을 통해 시스템의 동작과 인터페이스를 정확히 이해 및 수립되어야 함.
아키텍처 선택 혹은 수립
개념적 통합을 가능케할 시스템 아키텍처 수립.
아키텍처 문서화와 의사소통
모든 이해 관계자가 이해할 수 있도록 명세 수립.
아키텍처 분석과 평가
이해관계자들의 요구사항 반영을 확인할 수 있는 분석 기법을 활용한 평가 결과 수립.
아키텍처 기반 시스템 개발
개발자의 아키텍처 이해 지원 방안 수립.
아키텍처 준수 여부 확인
개발 시스템과 아키텍처 사이의 차이 확인 방안 수립.

1.3 좋은 아키텍처의 조건

어떤 아키텍처도 좋다 나쁘다 평가할 수 없으며, 단 아래와 같은 권고사항으로써 아키텍처를 점검할 수 있다.

1.3.1 프로세스 권고사항

아키텍처는 아키텍트를 통해 수립.
아키텍트는 요구사항 수집,정제,우선순위 수립.
아키텍처는 적어도 하나의 정적뷰,동적뷰를 포함하고 이해하기 쉬운 기호로 문서 기술 되어야 함.
아키텍처는 전체 이해관계자가 배포 받고 검증시 참여되어야 함.
아키텍처는 정량적 성능 품질로 평가되어야 하고 논리적으로 확인되어야 함.
아키텍처는 요구사항을 수용가능한 포함하고 점진적 기능 확장 가능해야 함.
아키텍처는 자원 경쟁 시에 대한 적정 제한을 제시해야 함.

1.3.2 구조적 권고 사항.

아키텍처는 모듈단위로 구분 가능해야 하며, 하부 구조 변경 시 유연하게 대처 가능해야 함.
모듈은 내부 변화(데이터나 행위 자체)를 은닉할 수 있도록 인터페이스를 제공해야 함.
품질 속성은 구체적이고 일반적인 기법으로 정의 되어야 함.
아키텍처는 특정 버전의 제품에 대한 의존도가 없어야 함.
데이터의 생성과 사용 모듈은 구분되어야 함.
병렬 처리 시스템에서 모듈은 하나의 컴포넌트나 커넥터로 표시해서는 않된다.
모든 태스크나 프로세스는 문서화 되어야 함.
아키텍처는 몇 가지(적정)의 단순한 상호작용 패턴을 정해 표시해야 함.

위 권고 사항이 절대적이지 않으나 수립과정 시 문제점을 파악할 수 있는 이정표.

※ 첨부.

아키텍처의 종류

Business Architecture (BA)
Application Architecture (AA)
Solution Architecture (SA)
(Software Architecture 가 아닌가 싶은데 확인이 필요하네요..)
Data Architecture (DA)

아키텍트의 위치

Enterprise Architect (EA)
전체 아키텍처 설계
Solution Architect (SA)
특정 솔루션 아키텍처 설계
Technical Architect (TA)
하드웨어 및 네트워크 아키텍처 설계
Application Architect (AA)
어플리케이션 표준 가이드 및 아키텍처 구조 설계
Data Architect (DA)
데이터 아키텍처 설계
Global Architect (GA) [Optional]
대규모 프로젝트에서 EA의 역할 분담자로 나머지 아키텍트의 통제와 상세 기술 설계 영역을 담당

[참고. 조대협의 블로그 http://bcho.tistory.com/668]

출처 : http://gwpark.blogspot.kr/2012/11/1.html

아키텍트(Architect)의 종류와 역할

JaeSoo — Tue, 22 Oct 2013 01:05:23 +0000

아키텍쳐를 설계 하는 사람은 아키텍트(Architect)라고 한다. 이 아키텍트는 아키텍쳐 설계 프로세스에서 정의한 각 아키텍쳐에 대해서 아키텍쳐를 설계하는 역할들이 정의된다. 계층 구조를 제외하면 아키텍쳐는 5가지로 분리된다.(http://bcho.tistory.com/667 참조) Business Architecture, Application Architecture, Solution Architecture, Data Architecture로 분리되며, 아키텍트 역시 이 5개 분야에 걸쳐서 총 5개의 역할로 정의된다.

Enterprise Architect (EA) Business Architecture를 포함한 전체 아키텍쳐 설계에 대한 책임을 진다. 비지니스 이해를 바탕으로 전체 아키텍쳐에 대한 큰 설계를 담당하며, 비지니스에 대한 이해를 바탕으로 장기적인 IT 전략 수립을 담당한다. EA의 특징중의 하나는, EA의 경우 단일 프로젝트 뿐만 아니라, 해당 회사의 앞으로의 비지니스 전략에 맞춰서 향후 모든 프로젝트에 대한 아키텍쳐에 대한 책임을 진다. 또한 SA,AA,TA,DA에 대한 통제 권한을 가지고 아키텍트 팀을 운용한다. 가끔 CIO와 혼동하는 경우가 있는데, CIO는 회사 내부의 IT 전략을 수립하고, IT 포트폴리오를 정의하고 수행한다는 관점에서 EA와 유사한 면이 있으나, 기술적인 면에서는 CIO와 EA의 부분이 겹칠 수 있으나 경영적인 측면에서는 다르다. CIO는 결정적으로 예산 집행권과 인사권을 가지고 있으며 설계 보다는 경영과 관리에 목적을 두는 반면, EA는 아키텍쳐 설계를 그 목적으로 한다.

Solution Architect (SA) 특정 솔루션에 대한 아키텍쳐를 설계한다. SA의 경우 프로젝트 내에 개발팀이 있을때, 해당 솔루션을 사용하는 모든 팀에 대한 아키텍쳐 설계를 담당한다.

Technical Architect (TA) 프로젝트 전체팀에 대한 하드웨어 및 네트워크 아키텍쳐를 설계한다.

Application Architect (AA) 애플리케이션에 대한 표준 가이드 및 아키텍쳐 구조를 담당한다. 팀 규모에 따라 대규모 팀인 경우 각 개발팀마다 AA를 배치하고, 소규모팀인 경우에는 프로젝트 전체팀에 대해서 애플리케이션 아키텍쳐 설계를 담당한다.

Data Architect (DA) 프로젝트 전체팀테 대해서 데이타 아키텍쳐 설계를 담당한다.

Global Architect (GA) [Optional] 일반적인 프로젝트 팀 구조에서는 잘 존재하지 않는 역할이다. EA의 경우 사내에서 진행중인 모든 프로젝트에 대해서 관여해야 하고, 비지니스 전략 측면에서 접근을 하다보니 경영진과의 커뮤니케이션이나 의사 결정 과정에 참여가 많아지기 때문에 실제 아키텍쳐 설계 과정에 디테일하게 참여하기가 어렵고, 때로는 기술의 이해수준이 아주 디테일 하지 않은 경우가 있기 때문에, GA라는 역할을 둬서 SA,TA,DA,AA에 대한 통제 권한 부여하고 기술 중심의 System Architecture의 설계 하도록 한다. 프로젝트 팀의 PM/PL의 관계를 EA/GA 관계로 보면 된다. EA는 비지니스를 포함한 외부 대응이나 큰 그림에 신경 쓰고, GA는 기술 위주의 아키텍쳐 설계에 집중한다.

출처 : http://bcho.tistory.com/668

기능점수 산출 실전 – 1. 기능점수 소개

JaeSoo — Sun, 20 Oct 2013 22:37:13 +0000

소프트웨어의 규모 측정

이 글을 읽은 사람이라면 대부분 소프트웨어 개발과 관련있는 분일 것이다. 그렇다면, 개발 프로젝트에서 아래와 같은 추산(Estimate) 작업을 어떻게 하고 있는가?

•고객이 원하는 소프트웨어의 가치(금액)은 얼마인가?
•고객이 원하는 소프트웨어를 개발하기 위하여 적정한 기간과 인력은 얼마인가?

위 질문은 프로젝트를 기획하고 진행하는데 반드시 필요한 추산작업이다. 하지만 소프트웨어 개발은 다른 제조공정과 달리 적정 가치와 적정 투입자원을 산술적으로 책정하기에 너무나 애매한 영역이다. 이는 개발이라는 것은 물질적인 것이 아니라 인간의 지적능력을 사용하여 이루이지는 작업이며, 동일한 결과물을 만들어내는 방법도 무한대의 서로 다른 방법을 사용할 수 있기 때문이다. 즉, 아마도 대부분의 회사에서 위 두가지 추산작업은 경험에 의존하여 대략 산출하는 방식을 사용하고 있을 것이다.

소프트웨어의 가치와 소프트웨어 개발에 소요되는 자원을 객관적으로 산출하기 위해서는 소프트웨어의 규모를 정량적으로 표현할 수 있어야 한다. 그리고 그 규모는 명확한 근거에 의하여 서로 다른 사람이 산출해도 거의 동일한 결과를 나타낼 수 있어야 한다.

즉, 기본적으로 제품의 가치와 제품생산에 소요되는 자원의 양은 제품의 크기(규모)에 비례한다고 볼 수 있으므로 소프트웨어의 가치와 투입자원도 이에 따라 소프트웨어의 규모에 의하여 결정하게 되는데, 이 “소프트웨어의 규모”를 정략적으로 측정하는 방식은 시대에 따라 달라져왔다.

•LOC(Line Of Code) : 소프트웨어의 소스코드 라인 수를 측정
•본수 : 소프트웨어의 독립된 기능(물리적기능)의 수를 측정
•M/M(Man Month) : 소프트웨어 개발에 투입되는 인원을 측정
•기능점수 : 소프트웨어의 요구사항(논리적기능)의 규모를 측정

LOC 방식은 현재는 거의 사용되지 않는다. 소프트웨어 규모를 소스코드의 Line 수로 판단할 수 없기 때문이다. (개발을 못하면 규모/가치가 커지는 현상이 발생한다.) 본수개념도 현재는 거의 사용되지 않는다. LOC와 본수는 기본적으로 구현과정이 마친 후에 산출 가능하므로(물리적인 소스에 의존) 프로젝트 기획단계에서의 예산작업 또는 투입자원 산출 시에 적용하기 힘들다. (1990년대 중반만 해도 거의 LOC와 본수로 측정하였다.)

M/M 방식은 아직도 많이 사용중이다. 많은 관공서에서 공공프로젝트 발주시, 투입인력을 최우선시하고, 인건비를 기준으로 프로젝트 예산을 산출한다. (물론 법적으로 기능점수를 권고하고 있지만, 아직은 확실히 정착되지 않고 있다.) 심지어, 기능점수 방식의 소프트웨어 가격근거를 부르짖는 SI 업체조차도 내부적으로 개발자의 성과나 업무량을 근무시간(M/M, 야근을 권장하는)으로 평가한다.

하지만 이 또한 LOC와 마찬가지의 문제를 가진다. 소프트웨어의 규모를 소스코드 Line 수로 판단할 수 없듯이, 개발자의 일한 시간으로 측정하는 것도 불가능하다. LOC와 마찬가지로 일을 못하면 시간이 늘어나기 때문이다.) 또한, LOC/본수/MM 모두 측정자의 관점에 따라 측정치가 천차만별 다르게 나올 수 있다. 즉, 객관적인 측정자료가 되기 힘든 문제가 있다.

기능점수의 출현

많은 S/W 개발회사가 위와 같은 문제로 소프트웨어의 규모를 측정하지 못하여 많은 실패를 하였다. IBM도 예외는 아니었다. IBM은 이러한 실패를 줄이기 위하여 1960년대 소프트웨어 개발 프로젝트에 대해 보다 정확한 예측(규모측정)을 하기 위한 노력을 기울였고, 그 결과 1969년 소프트웨어의 비용산정기법과 도구를 개발하였다. 이 기법은 “업무적 요소”와 “기술적 요소”를 분리하여 규모를 측정하여여 객관적인 측정을 가능하도록 하였다.

1970년대 후반, 보다 객관적인 규모의 측정을 위하여 소프트웨어의 기능을 개발자의 기술과 무관하게 “사용자의 업무적 기능”을 논리적으로 분석하여 점수화하는 방법이 고안되었는데 이것을 “기능점수 분석법”이라고 한다. 소프트웨어 기능을 개발기술과 무관하게 “업무관점에서의 기능 (즉, 고객요구사항)”만으로 측정하는 방식은 “객관적인 규모의 측정”면에서 매우 합리적이다. 기존 규모측정방식의 문제점인 “측정자에 따라 달라지는 규모”문제가 대부분 해결될 수 있기 때문이다. 쉽게 말하자면, “고객의 요구사항이 10개”이면, 개발자가 어떠한 방식으로 개발하더라도 규모는 “10개”로 측정되는 것이다.

이것이 기능점수의 핵심이다. 필자의 경험으로는, 잘못 측정되는 대부분의 기능점수는 바로 “업무기능”을 측정하지 않고 “물리적기능(구현된기능)”을 기준으로 규모를 측정하는 것이다. 이는 대부분의 기능점수가 개발자에의하여 측정되기 때문에 본인의 관점에서 기능을 정의하기 때문일 것이다. 기능점수는 “물리적기능”을 측정하는 것이 아니라 “요구사항”의 규모를 측정하는 방식이다. 이것만 기억하면 기능점수 산출은 쉽다.

이후 기능점수 방식은 지속적으로 개선되어 국제기능점수사용자그룹(IFPUG)에 의하여 표준화되었고, 현재 국제 표준으로 채택되었다.

국내에서의 기능점수 활용

최근 국내에서도 소프트웨어의 제값을 받기 위한 노력이 많이 진행되었다. 국내에서도 2000년대 중반 기능점수가 도입되어 발표되었고, 현재 소프트웨어 견적, 예산의 기준으로 사용되고 있다. 현재 정부에서는 모든 공공사업의 가격근거로 기능점수를 제시하기를 권고하고 있다. 즉, 이제는 국내에서도 소프트웨어의 예산작업, 견적 등에 필수적으로 사용되고 있으므로, 반드시 기능점수의 측정법을 익혀야 하는 상황이 되었다.

내가 근무하는 회사는 주로 공공사업을 대상으로 개발을 하고 있다. 현재 관공서는 기능점수에 근거한 가격산출이 없으면 발주를 낼 수가 없다. 물론 이것이 소프트웨어를 철저히 객관적으로 가치를 산정하여 예산에 반영한다는 의미는 아니다. 아직도 대부분 미리 정해진 예산에 기능점수를 거꾸로 맞추는 식으로 진행되고 있지만, 지속적으로 개선될 것이라고 본다.

기능점수의 활용

기능점수는 소프트웨어의 규모를 객관적으로 측정하는 방식이므로 다양한 분야에 활용될 수 있다. 현재 국내에서는 주로 예산/견적 작업에 활용되고 있지만, 사실 프로젝트 관리 측면에서의 활용도도 상당히 높으며, 사실상 소프트웨어 개발 프로세스의 전영역에서 활용될 수 있다.

1. 소프트웨어 예산/견적 산출

- 가장 많이 사용되는 분야이다. 현재 많은 SI 사업에서 가격산출 근거로 제시되고 있다.

- SI 사업에서 RFP(제안요청서)에 제시된 요구에 대한 적정 가격이란 것은 산출하기 쉽지 않다. 기능점수를 사용하면, 이러한 가격산출을 보다 객관적으로 할 수 있게 한다.

- 또한, 정량적인 규모의 측정은 미리 소프트웨어 개발에 소요되는 원가를 예측할 수 있도록 한다.

물 론, 아직은 국내 현실은 이러한 가격근거에 의하여 예산을 책정하고 있지는 않다. 예산은 대부문 미리 결정되어 진다. 아직은 발주처나 수행처 모두 기능점수에 대한 이해가 부족하여 정확한 가격근거를 산출하지 못하고 소프트웨어의 제값을 책정하는 문화가 정착되지 않고 있다. 예를 들어, “특급기술자” 1MM 투입시 인건비는 월 700-800만원으로 책정되지만, 기능점수에 의거하여 화면 하나를 개발하는 가격을 산출하면 거의 1500만원 선이다.

2. 프로젝트 관리

서두에 말했듯이, 프로젝트의 계획수립을 위하여 투입자원계획과 일정계획은 필수적이다. 기능점수는 “개발규모”에 의거한 계획수립을 가능하게 한다.

즉, 객관적인 규모를 측정하고, 측정된 규모를 개발하기 위해서는 인력이 몇 명 필요한지를 예측할 수 있다. 이는 데이터가 누적될수록 정확해진다. (초기에는 오차가 많겠지만, 데이터가 누적되면, 개발자 1명당 몇점의 규모를 개발가능한지에 대한 통계치가 산출된다.)

즉, 이는 투입자원과 개발기간을 미리 예측할 수 있도록 한다.

3. 개발 관리

기능점수 측정은 Agile의 프로젝트 추정과 계획기법과 매우 유사하다.

Agile에서 추정은 “User Story (요구사항)”에 대한 포인트를 계산하여 규모를 추정하고 이에 따라 자원을 할당한다. 그리고 진척도를 포인트의 완료에 대하여 번다운 차트로 표현한다.

기능점수는 사용자의 요구사항에 대한 측정이므로 User Story와 유사하며, 그 규모를 점수로 측정하는데 이는 User Story의 포인트 측정과 유사하다.

즉, 기능점수를 개발시 활용하면, Agile의 기법을 그대로 적용가능하다.

4. 개발 프로세스 관리

2번과 3번에서 말한바와 같이 기능점수는 개발회사의 각 프로세스에서 유용하게 활용될 수 있다.

이외에도 기존에 소프트웨어의 규모를 측정할 수 있는 객관적인 단위가 없기 때문에 개발조직의 개개인 또는 팀 등의 성과를 측정하기도 힘든데, 이러한 부분에도 기능점수를 활용할 수 있다.

즉, 개발활동에서의 모든 측정단위를 기능점수로 통합할 수 있으며, 이러한 단위의 통합으로 인하여 모든 개발활동의 양을 동일한 단위로 측정하여 활용할 수 있다.

나의 사내 주요 직책 중 하나는 사내 프로세스 개선업무이다. 현재 회사는 표준 개발 프로세스로 기능점수에 의한 진척도 측정법을 표준으로 사용한다. 즉, 기능이 정의 되는 분석단계 말에 도출된 기능에 대한 기능점수를 측정하고, 이에 따라 개발주기계획을 수립한다. 그리고 이 계획에 따른 진척도를 보고하고, 최종적으로 각 개발자와 소속팀의 기여도를 평가한다.

또한 사내 표준 개발방법론에 이를 모두 통합하여 사용하며, 모든 활동의 단위는 “기능(Function or Process)과 기능점수”이다.

즉, 예산수립, 원가측정, 계획수립, 개발진행, 산출물, 평가/성과 등의 모든 측정 기준은 기능점수로 통합되어 있다. 이렇게 하는 경우 돈-사람-일을 모두 일치 시킬 수 있다.

기능점수의 장단점

1. 장점

개발언어, 개발기술과 관계없이 어플리케이션의 복잡도(규모) 계산에 일관성을 제공한다.

(요구사항만으로 측정하므로 실제 구현 방법과 관계가 없다)

조직에 관계없이 규모측정에 일관성을 제공한다.

(객관적인 요구사항만으로 측정하므로 구지 개발팀에서 측정할 필요도 없고, 개발방법과 무관하므로 측정하는 조직과 관계 없이 측정된다.)

소프트웨어 개발 사이클 초기에 이용할 수 있다.

(요구사항만 도출되어 있다면 언제든지 측정가능하므로 초기 예측/추산에 사용될 수 있다.)

개발의 모든 사이클에 기준으로 사용가능하다.

2. 단점

요구사항으로부터 기능을 도출하기 위하여 상당한 분석 능력을 요구한다. 즉, 기능점수를 위한 기능도출의 난이도가 높을 수 있다. 이는 사실 소프트웨어 개발 사이클의 분석단계와 유사한 과정을 요구한다.

기능점수는 사용자가 인지가능한 기능을 측정한다. 따라서 내부로직위주(서버프로세스같은)의 소프트웨어는 측정이 다소 부적합하다.

소프트웨어 대가기준의 표준으로 지정되어 있지만, 아직은 개발자 이외의 집단의 이해도가 낮은 관계로, 원래 취지로 사용되기 힘들다.

출처 : http://rainiac.com/dev/index.php/%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%82%b0%ec%b6%9c-%ec%8b%a4%ec%a0%84-1-%ea%b8%b0%eb%8a%a5%ec%a0%90%ec%88%98-%ec%86%8c%ea%b0%9c/

안전진단의 대안 ISMS의 허와 실

JAESOO — Tue, 28 May 2013 13:21:15 +0000

안전진단의 실효성이 대두되면서 ISMS를 대안으로 대두되었고, 준비가 덜된상태에서 지난해 망법이 통과되었고, 1년 지나 법 적용시기가 되었다.

ISMS 인증 컨설팅 시장이 활황을 누릴거라는 생각이 지배적이였으나 그닥 그렇지만은 아닌것 같다.

일부 기관은 이미 ISMS을 획득하여서 인증 컨설팅을 수행하지 않아도 되고, 2월 17일 이전에 안전진단을 받을 경우 올해 ISMS 인증을 면제 받는 법의 틈새(?)를 이용한 기관은 상당수 존재하고 있다. 또한 ISMS 인증 컨설팅을 수행하지 않고 자체에서 진행하여도 되며, 컨설팅 수행기관이 자격 등이 존재하지 않아 무자격자에 의한 시술이 진행되고 있기도 하다. 인증을 위한 인증이 될 것 같은 느낌마저 들고 있다.

인증을 획득해야 하는 기관에서도 의무화에 대한 대응에 급급하지, 진정 정보보호 체계 수립이라는 본래의 목적을 상실한 듯 보이는 곳이 많다.

과연 ISMS가 정보보호 수준 향상에 도움이 되는가?
- 컨설턴트 입장에서 보면 Yes라고 해야 할것이다. 적어도 인증을 위한 준비를 하다 보면 정보보호 체계가 수립된다.
- 문제는 수검기관의 참여도, 자세가 중요한데 안전진단의 폐혜중하나가 컨설턴트가 모든 것을 수행하였다는 것이다.
- 실제 정보시스템의 안전도를 진단한 것이 아니라 확인서 발급을 위한 보고서 작성에 열을 올렸기에 실효성 문제가 대두되었듯이 ISMS도 인증을 위한 인증으로 간다면, 질문과 같이 정보보호 수준 향상은 기대하기 어렵다고 봐야 한다.
정보보호 자율적으로 가능한가?
- 어느정도 가능하다고 본다.
- 정보노출에 대한 가치를 적절히 평가하고 있으며 보호해야 한다는 의식이 존재한다.
- 삼성전자 같은 경우를 보자. 반도체 핵심 기술 당연히 보호하지 않겠는가? 별의 별 보호조치를 적용하고 있을 것이다.
- 문제는 개인정보보호인데, 개인정보의 유출로 인해 피해를 보는 이는 고객, 국민이기에 회사에서 관리를 허술하게 하는 것이다.
- 강제성이 필요한 대목이다.
ISMS,PIMS,G-ISMS,ISO27001
- 개인적으로 하나만 했으면 좋겠다.
- 정보보호 관리체계, 개인정보보호관리체계, 전자정부 정보보호관리체계, 이게 또 국내, 국제로 나누어져 있다.
- 범위, 대상이 조금씩 틀리지 맥은 같이하고 있다.

이왕 행하는 ISMS 인증 프로젝트 어떻게 진행하면 좋은가?

수검기관에서 직접 수행하는것을 추천한다. 그것이 어려울 경우 전문기관을 찾아야 하는데 가능하면 기간은 길게 잡았으면 좋겠다.

기간의 중요성은 기성복과 맞춤, 템플릿과 현행화 등으로 생각하면 좋겠다.

짧은 기간으로 인해 비용이 적게 들수는 있을 것이다. 인증을 위한 인증을 일을 위한 일, 매년 수검 받을때 마다 일주일 이상 관련자들이 야근을 해야 하는 고된 업무가 된다. 그럼에도 불구하고 정보보호 수준이 향상되었다는 것을 체감하지 못하고 오히여 떨어져 위험에 빠질 수 있다.

충분한 시간, 수검기관의 관련자의 높은 참여도가 진정한 정보보호 수준 향상, 매년 사후관리 시에 업무로드나 없거나 낮게 될 것이다.

다시 정리하면 수검기관의 높은 참여도, 충분한 프로젝트 수행기간 보장이 성공적인 ISMS 인증 프로젝트의 성공요소이다.

출처 : http://blog.daum.net/kdg70i/160

정보보호 안전진단이 왜 사라지나?

JAESOO — Tue, 28 May 2013 13:20:49 +0000

정보보호 안전진단이 왜 사라지나?

여러가지 이유가 있을 것이다.

안전진단의 주체는 정부(정통부, 방통위), 관리기관(통신사, 웹 호스팅 등 정보통신서비스 업자, 안전진단 수행기관이 있다.

각 주체들의 역할, 입장 및 잘못을 찾아 보고 향후 비슷하 업무가 발생 할 경우에 이를 반영하여 보고자 한다.

1. 정부

- 관리기관, 수행기관 지정 및 관리 감독 권한 보유

- 중간에 수행기관 인력에 대한 감독을 강화하여 신분증을 배부하였음

- 아쉬운 점은 수행인력에 대한 자긍심을 고양할 수 있는 프로그램이 부족하였다고 생각 된다.

- 안전진단은 방통위를 대신한 감사 성격이 강하나 을로써 보고서 작성에 치중하도록 되어 버렸다.

- 보안은 자발적으로 하지 못하는 성격이 있다. 이것을 함으로해서 이득이 되는 것이 없다.

- 보험 성격이 강하다. 자동차 책임 보험처럼 강제화 해야 한다. 안전진단 대상은 강제화 하였다.

- 관리기관에 의해 끌려간 느낌이 있다. 그리고 수행기관이 수익기관이라고 생각해서 을의 입장을 유지하도록 유도하였다.

- 이것으로 인해 안전진단 품질저하에 일조하였다. 갑에게 어찌 함부로..^^ 을이라면 이해를 할 것이다.

- 안전진단 필증이 있으면 보안사고가 안 나야 한다는 논리를 편다(국회에 계시는 분들이 특히 그렇다)

- 이론은 맞다. 그러나 여러가지 메터리즘을 살펴보면 안전진단만으로 충분한가 라는 생각이 들것이다.

- 그래서 안전진단을 없애고 ISMS로 전향한것이 아닌가 판단된다.

- 지금 현재 ISMS만 허용하고 있으나 ISO27001도 함께 고려되어야 하겠다.

- 그리고 ISMS 심시기관, 심사원 양성 계획도 빨리 수립해야 할 듯하다.(개인적으로 관심이 많다.)

2. 정보통신서비스 업자

- 기본적으로 보안에 관심이 없는 그룹이다. 매출에만 관심이 있다.

- 안전진단 수수료에만 관심이 있다.(안 그런 기관도 있지만 대부분이 그렇다)

- 수익도 나고, 성과금도 두둑히 주는 기업도 마찬가지다.

- 수퍼갑 행세를 하는데 갑자기 을이 와서 진단을 한다고 하니 어리둥절 어쩔 줄 몰라하면서 그냥 누른다.

- 알아서 잘 해 줘 ^^

- ISMS로 변경되어도 관리기관의 태도에는 차이가 없을 것 같다.

- 그러나 심사원들의 레벨이 수행기관의 수행원과는 다른다.

- 교수, 대기업 간부, 기술사 등 이미 사회적 지위 높고, 정보보호 측면에서 인증을 받은 분들이 심사를 하게 된다.

- 적어도 예전처럼, 을 부리는 것 처럼은 하지 못할 것이다.

- 차츰 정보보호 수준이 향상될 것으로 생각된다.

3. 수행기관

- 범 국가적으로 정보보호 수준 제고를 위한 힘써야 한다는 자긍심이 없는 기관이 존재하였다.

- 예를들어 심사도 수행하지 않고 문서행위만을 수행하는 기관도 있다고 한다.

- 안전진단 단가는 낮고, 업무는 복잡하여 그럴 수도 있으나, 매출에만 관심이 있는 수행기관이 있었던것 같다.

- 20여개의 기관이 상호 경쟁을 하면 품질이 좋아져야 하는데 단가만 내려가고,

- 저가의 인력 투입이 지속적으로 되므로써 안전진단에 대한 필요성이 낮아 졌던것 같다.

- ISMS로 변경되면서 일은 더 많아 질 것으로 판단된다.

- ISMS 인증 대비 컨설팅이 솟아져 나오겠지만 단기적으로 진행되고 지속적인 사업은 되지 못 할 것으로 판단된다.

정보보호 수준 제고에 관심들이 많았으면 좋겠다. 특히 그것을 업으로 하는 수행기관에서 매출에만 관심 두지 않고 좀더 품질 높은 서비스를 제공하였으면 한다. 비용도 제대로 받으면서 말이다. 사구려 물건은 이제 그만~

출처 : http://blog.daum.net/kdg70i/138

2013년도 예산안작성 세부지침 (세부사업유형별,비목별 매뉴얼)

JAESOO — Thu, 02 May 2013 21:58:21 +0000

2013년도 예산안작성 세부지침(세부사업유형별ㆍ비목별 매뉴얼)입니다.

업무에 활용하시기 바랍니다.

2013년도 예산안작성 세부지침 (세부사업유형별,비목별 매뉴얼)-20120501100653314.hwp

출처 : http://www.mosf.go.kr/policy/policy01_total.jsp?boardType=general&hdnBulletRunno=&cvbnPath=&sub_category=&hdnFlag=&cat=&hdnSubject=%EC%98%88%EC%82%B0%EC%95%88%EC%9E%91%EC%84%B1&hdnPage=1&&actionType=view&runno=4013289&hdnTopicDate=2012-05-01&skey=policy

MIS 계획 수립 과정

JAESOO — Thu, 02 May 2013 14:05:08 +0000

MIS 계획 수립 과정

I. 서 론
- 정보기술에 대한 전략적 잠재력에 대한 인식이 고조되면서 최근에는 MIS 계획을 주로 전략적 정보시스템 계획(Strategic Information Systems Planning: SISP) 또는 정보전략계획(Information Strategy Planning : ISP)의 차원에서 논의하는 것이 보통이다.
- MIS 계획이 단순히 정보시스템 담당부서의 시스템 개발계획의 차원에서 벗어나 조직전체의 경영전략적 차원에서 다루어져야 할 필요성이 있음
- 이 장에서는
1) MIS 계획의 목표, 유형 및 영역 등에 관해 살펴보고
2) MIS 계획수립을 위해 기본적으로 거쳐야 할 과정 및 절차를 논의하고
3) 실제 MIS 계획수립시 주로 활용되는 대표적인 방법론들을 소개하고
4) MIS 계획수립과 관련된 제반 문제점 및 성공요인에 관하여 살펴봄

Ⅱ. MIS 계획의 목표, 유형 및 영역
- MIS 계획은 “조직의 정보기술 활용목표를 설정하고 장차 조직에서 실행해야 할 잠재적인 응용시스템을 규명하는 과정.
- 조직에서 정보시스템이 수행해야 할 역할에 관한 미래의 비전에 맞도록 시스템을 개발하기 위한 것으로 정보기술 자체의 급속한 발달: 기술적으로 실현하기 힘들던 일의 실현 가능.

MIS전략및계획.hwp

출처 : http://wizone.co.kr/jdh_mis/1226242

정보시스템 전략과 계획 [ISP,BSP,CSF,EA]

JAESOO — Wed, 01 May 2013 18:10:59 +0000

*ISP 방법론

<Information System Planning -> Information Strategy Planning>

SISP = Strategy Information System Planning.

정의: 조직의 성과를 위해 경영환경을 분석하고, 환경분석, 벤치마킹, 경향분석을 하고 현행업무나 기존의 정보시스템에 대한 분석을 통하여 미래 정보시스템 체계를 정의하고 이행 계획을 수립하는 것.

착수

↓

환경/전략분석[외,내부 기술 경영환경 분석]

-> 업무요건정의[현행/계획 시스템분석 -> 정보요구분석 -> 우선순위선정]

-> 체계정의[업무시스템 체계정의 -> 정보기술체계정의 -> 정보관리 체계정의]

-> 이행계획수립 -> 완료.

*BSP [Business System Planning]

조직의 장단기 정보요구를 분석하고자 하는 구조적기법.

*CSF [Critical Successful Factors]

기업간의 경쟁관계에서 경쟁우의를 갖기위한 성공적인 중요한 것들을 보장해주는 특정한 요인.

* EA [Enterprise Architecture]

전사적 아키텍쳐

아키텍쳐 - 건물의 설계도, 지도등과 같이 대상의 특징들을 추상화한것.

EA<ITA 정보기술자원의 획득, 구현 관리를 체계적으로 지원해주는 표준, 정책, 지침 등의 집합

조직의 정보화구성요소를 통합적으로 분석, 이들 간의 관계를 구조적으로 정리한 체제, 이를 바탕으로 정보시스템을 효율적으로 구성.

4가지 구성요소,

업무 아키텍쳐,

데이타 아키텍쳐,

응용 아키텍쳐,

기술 아키텍쳐

지원도구,

참조모델

표준프로파일

출처 : http://sweetstar111.blog.me/130048854128

윈백(win back)이란?

JaeSoo — Wed, 20 Feb 2013 15:00:59 +0000

‘윈백(Win Back)’은 경쟁사의 시스템을 들어내고 자사의 시스템으로 교체하는 비즈니스를 의미한다. 윈백을 하는 업체 입장에서는 경쟁사와 비교해 자사가 우위에 있다는 점을 입증하는 사례로 마케팅 자료의 단골 메뉴다. 불과 1, 2년 전만 해도 윈백 사례는 컴퓨팅업계에서 핫이슈였다. 그러나 지금은 웬만한 윈백은 뉴스거리도 아니다.

특히 최근 들어 윈백은 서버에 국한되지 않고 운용체계(OS) 간의 싸움은 물론 스토리지, 데이터베이스관리시스템(DBMS)이나 전사자원관리(ERP) 시스템 등 이른바 기업의 핵심 업무로 사용되는 애플리케이션 영역에서도 드러난다. 마치 일상적인 영업 행위로까지 받아들여지는 분위기다. 일부 기업은 윈백 전담팀을 가동하고 별도의 영업 목표를 세우기도 해 말 그대로 윈백 전성시대를 맞고 있는 분위기다.

◇왜 윈백인가=윈백은 단순히 프로젝트에서 경쟁사를 제쳤다는 것 외에도 경쟁사 시스 템이나 솔루션을 들어냈다는 점에서 효과가 만만치 않다.
출처: 전자신문

세상은 이렇게 먹고 먹히는 관계이며 비지니스 세계에서는 냉혹함을 알게 된다. 이러한 정글에서 살아 남기 위해서는 남의 것을 드러내고 내것이 우위에 있다는 사실을 알리고 입증을 해야 한다.

출처 : http://www.sis.pe.kr/1428

행정안전부가 각 부처 소관 복지사업 실시내역을 취합ㆍ관리하는 데이터베이스를 구축할 수 있는지 여부(「전자정부법」 제54조제2항 등 관련)

JaeSoo — Wed, 12 Sep 2012 16:15:54 +0000

행정안전부가 각 부처 소관 복지사업 실시내역을 취합ㆍ관리하는 데이터베이스를 구축할 수 있는지 여부(「전자정부법」 제54조제2항 등 관련)

[법제처 10-0348, 2010.12.16, 행정안전부 복지정보연계추진단]

【질의요지】

행정안전부가 복지업무 효율화 및 복지급여의 중복수급 방지 등을 위하여 각 부처의 복지사업 실적정보를 연계할 수 있도록 「전자정부법」 제54조제2항을 근거로 복지급여 지급대상 및 개인별 지원내역 등 각 부처 소관 복지사업 실시내역에 대한 정보를 취합·관리할 수 있는 데이터베이스를 구축할 수 있는지?

【회답】

행정안전부가 복지업무 효율화 및 복지급여의 중복수급 방지 등을 위하여 각 부처의 복지사업 실적정보를 연계할 수 있도록 「전자정부법」 제54조제2항을 근거로 복지급여 지급대상 및 개인별 지원내역 등 각 부처 소관 복지사업 실시내역에 대한 정보를 취합·관리할 수 있는 데이터베이스를 구축할 수는 없습니다.

【이유】

  먼저, 「전자정부법」 제2조제11호에서는 행정기관 등이 보유한 행정정보나 행정정보의 수집·가공·검색을 위해 구축한 정보시스템 등을 정보자원이라고 규정하고, 같은 법 제54조에서는 행정기관은 해당 기관이 보유한 정보자원의 현황과 통계자료를 체계적으로 작성·관리하며(제1항), 행정안전부장관은 중앙행정기관의 정보자원에 대한 공동이용 등을 위하여 정보화 수요를 조사하고 정보자원의 통합기준 및 원칙을 수립하여 정보자원을 통합적으로 구축·관리할 수 있도록 규정하고 있고(제2항), 이에 따라 「전자정부법 시행령」 제66조제2항에서는 정보자원 통합기준에 포함될 수 있는 것으로 ‘정보시스템의 규모·용량, 정보시스템의 기술표준’ 등의 내용을 규정하고 있는바, 「전자정부법」 제54조제2항에 따른 정보자원의 통합·구축관리란 정보시스템의 기술표준 등이 각 행정기관별로 상이하여 향후 활용이 원활하지 못한 것을 방지하고자 같은 조 제1항에 따라 중앙행정기관이 관리하는 정보자원의 현황 및 통계자료를 「전자정부법 시행령」 제66조제2항에서 제시된 것과 같은 정보시스템의 규모나 용량, 기술표준과 같은 통합기준을 수립하여 행정안전부장관이 관리하도록 하려는 의미라고 보아야 할 것이지, 각 기관이 고유 업무를 수행하면서 수집·관리하고 있는 정보를 행정안전부가 특정의 정보시스템을 구축하여 취합·관리하는 것까지 의미하는 것으로 볼 수는 없다고 할 것입니다.
  또한, ‘중앙’행정기관의 정보자원 통합관리에 관한 「전자정부법」 제54조제2항에 이어 같은 법 제55조에서는 ‘지방’자치단체의 정보자원의 관리에 관하여 규정하면서 지방자치단체의 정보자원의 효율적 관리와 통합추진 등을 위한 지역정보통합센터의 설립에 대하여 규정하고 있고, 「전자정부법 시행령」 제67조에서는 이러한 지역정보통합센터의 업무로 정보자원의 ‘통합 및 유지·관리’(제1호), 정보통신망 ‘구축·관리’(제4호)를 규정하고 있으며, 2010년 2월 전부개정된 「전자정부법」 입안 당시 행정안전부의 조문별 제개정이유서에서도 중앙정부의 정부통합전산센터에 대응하는 지역정보통합센터를 설립하기 위하여 「전자정부법」 제55조의 규정을 도입한 취지 등을 설명하고 있는바, 지역정보통합과 대응을 이루는 조문의 구조 및 지역정보통합과 관련된 같은 법 시행령의 규정을 종합적으로 고려하여 보면, 「전자정부법」 제54조제2항은 ‘중앙행정기관’의 ‘정보시스템 기술표준 등의 관리’ 등에 관한 사항을 규정한 것으로 보이고, 각 부처에서 보유·관리하고 있는 정보를 하나의 정보통신망 또는 정보관리체계로 취합하고 이를 처리·가공할 수 있도록 하려는 근거조문으로 보기는 어렵다고 할 것입니다.
  특히, 정부에서 제출한 전자정부법 전부개정법률안에 대한 2009년 2월 국회 검토보고서에 따르면 정보자원 통합관리의 효과로 ‘전산장비 구축비를 절감’하여 행정업무의 생산성이 제고될 수 있다고 한 내용에 비추어 볼 때, 정보자원 통합관리의 중점이 전산장비 등 외형적이고 기술적인 측면에 있음을 알 수 있고, 「전자정부법」 제54조는 ‘전자정부’의 기반에 관한 장(章)에 규정된 것으로서 정보자원의 체계적인 보호 필요성과 정보기술아키텍처의 도입 등에 따라 규정된 것으로 전자정부 추진방향 등에 대한 일반적인 근거조문 중 하나라고 할 수 있으며, 그 밖에 현행 「전자정부법」에서 다른 기관의 정보이용에 관한 행정정보 공동이용의 내용을 별도의 장(章)으로 규정하여 사전·사후 관리대책과 그 이용절차 등에 관한 자세한 규정을 두고 있는 점 등을 고려할 때, 「전자정부법」 제54조제2항을 행정기관이 보유한 정보의 표준화 또는 규격화를 위한 기술적인 접근 이외에 실질적인 정보의 취합이나 데이터베이스 구축의 근거규정으로 보기는 어렵다고 할 것입니다.
  한편, 「공공기관의 개인정보보호에 관한 법률」(이하 “개인정보보호법”이라 함) 제3조의2에서는 공공기관의 장이 개인정보를 수집하는 경우에는 그 목적을 명확히 하고, 수집된 개인정보를 목적 외의 용도로 활용하지 않도록 규정하고 있으며, 같은 법 제4조에서도 개인정보의 수집 대상이나 원칙에 관하여 엄격한 규정을 두고 있는바, 각 부처에서 고유한 목적사업을 위하여 보유·관리하고 있는 자료 중 이름, 주민등록번호 등 개인정보와 관련된 것을 행정안전부에서 정보통신망 또는 정보관리체계를 구축하여 취합하는 것은 단순히 정보를 기술적으로 표준화 또는 규격화하는 등의 문제를 넘어 각 부처에 분산된 개인정보를 보유기관 외의 기관인 행정안전부가 ‘수집’한다는 의미에 가깝다고 할 것이고, 이는 당초 개인정보를 수집하거나 보유하고 있는 기관이 아닌 행정안전부가 각 부처의 시스템을 통하여 수집된 개인정보를 다시 취합·저장하거나 가공하는 경우로서 개인정보 보유기관 외의 자가 개인정보를 취급하는 경우에 해당한다고 보아야 할 것입니다.
  그런데, 개인정보보호법 제10조제1항에서는 다른 법률에서 인정하는 경우를 제외하고는 보유기관 외의 자 등에게 ‘보유목적 외’로 개인정보를 이용하게 하거나 제공하지 못하도록 규정하고 있고, 예외적으로 같은 조 제3항에서 정보주체의 동의 등이 있는 경우에만 제공할 수 있도록 규정하고 있는바, 각 부처에서는 「정부조직법」에 따라 분장된 권한을 바탕으로 소관 개별 법률들에 근거하여 여러 복지사업을 실시하고 있고, 개별 복지사업은 모두 그 목적과 지향하는 점, 수급대상자 및 정책적 기대효과 등이 상이하다고 할 것이므로, ‘복지 관련’이라는 일반적이고 추상적인 목적을 근거로 각 부처가 보유한 개인정보를 ‘동일한 보유목적’에 따른 개인정보라고 보아 행정안전부가 구축한 정보통신망 등을 통하여 취합할 수 있는 것으로 보기는 어렵다고 할 것입니다.
  또한, 개인정보보호법 제10조제1항에 따라 정보 보유기관이 보유기관 외의 자에게 개인정보 파일을 제공할 수 있는 근거가 되는 ‘다른 법률’이란 개별 법률에서 개인정보를 보유목적 외의 목적으로 보유기관 외의 자가 사용할 수 있도록 구체적으로 규정한 경우 등을 말한다고 할 것인바, 「전자정부법」 제54조제2항과 같이 전자정부 추진이나 정보시스템 구축을 위한 일반적이고 추상적인 규정만으로는 ‘다른 법률’에 의하여 개인정보를 ‘보유기관 외의 자’가 ‘보유목적 외’로 이용하거나 제공하도록 한 근거로 보기도 어렵다고 할 것이므로, 행정안전부에서 각 부처의 복지사업 관련 실시결과 정보를 취합·관리하는 시스템을 구축하는 것은 개인정보보호법 제10조의 규정에 비추어 타당하다고 보기 어렵습니다.
  그렇다면, 「전자정부법」 제54조제2항은 조문의 취지나 개인정보보호법 등과의 관계에서 행정안전부가 복지급여 지급내역 등 각 부처 소관 복지사업 실시내역에 대한 데이터베이스를 구축하여 정보를 취합·관리할 수 있는 근거가 되기는 어렵다고 할 것이므로, 이를 근거로 행정안전부가 각 부처간 복지급여 지급실적 정보를 연계할 수 있도록 복지급여 지급대상 및 개인별 지원내역 등 각 부처 소관 복지사업 실시내역에 대한 정보를 취합·관리할 수 있는 데이터베이스를 구축할 수는 없습니다.

출처 : http://www.law.go.kr/expcInfoP.do?mode=0&expcSeq=75908

[노임단가] 2011년도 적용 SW기술자 노임단가 공표

JaeSoo — Tue, 28 Feb 2012 03:38:51 +0000

2011년도 적용 SW기술자 노임단가 공표

소프트웨어산업진흥법 시행령 제16조(SW기술자의 등급별 노임단가)의 규정에 의한 소프트웨어사업의 대가기준에 적용할 소프트웨어기술자 일 노임단가를 통계법 제23조에 의거 다음과 같이 공표합니다.

【2011년 공표임금: 일 급여 기준】

(단위: 명, 원)
구 분	2011년 조사인원	노임단가			전년대비 증가액
구 분	2011년 조사인원	2009년도	2010년도	2011년도	전년대비 증가액
기술사	313	356,999	358,777	369,995	11,218
특급기술자	9,736	314,773	333,226	340,973	7,747
고급기술자	8,266	228,833	239,085	251,772	12,687
중급기술자	10,305	190,248	188,139	208,943	20,804
초급기술자	14,932	141,761	146,620	162,862	16,242
고급기능사	420	126,106	140,918	138,613	-2,305
중급기능사	640	109,777	110,637	107,288	-3,349
초급기능사	530	86,961	90,599	93,127	2,528
자료입력원	758	67,032	69,680	76,887	7,207

* 본 2011년 노임단가는 인원가중평균치임.

* 상기결과는 일급여기준이며, 기본급여+제수당+상여금 등을 모두 포함한 결과임.

* 자료입력원 노임단가의 기본급여는 2010년 58,795원, 2011년 65,685원으로 조사됨.

* 2011년의 월평균 근무일수는 21.5일로 조사됨.

* SW기술자 공인노임단가는 2010년 대비 평균 5.5% 증가함.

<시행일> 2011년 9월 1일부터

2011년 8월 30일

한국소프트웨어산업협회장

출처 : http://dw.sw.or.kr/pds/view.asp?idx=5336&masteridx=28

[사업대가] 2011년 소프트웨어사업대가의 기준 해설서

JaeSoo — Tue, 28 Feb 2012 03:37:26 +0000

소프트웨어사업 대가의 기준 고시(지식경제부고시 제2009-102)의 해설서입니다.

첨부된 파일 참조 부탁드립니다.

감사합니다.

출처 : http://dw.sw.or.kr/pds/view.asp?idx=5258&masteridx=27

[사업대가] SW사업 대가산정 가이드

JaeSoo — Tue, 28 Feb 2012 03:36:28 +0000

SW사업대가기준 고시 폐지에 따라 새로 적용되는 SW사업 대가산정 가이드입니다.

첨부된 파일 참조 부탁드립니다.

감사합니다.

출처 : http://dw.sw.or.kr/pds/view.asp?idx=5605&masteridx=27

기능점수 측정 가이드

JaeSoo — Fri, 02 Dec 2011 18:41:32 +0000

본 자료는 일전에 회사에서 사용하던 것으로써 기능점수의 실전사례를 체험해 볼수 있기에, 이론적인 공부를 마치고 실전에 적용을 준비중인 분들에게 도움이 되시라고 공유합니다.

1. 측정개요

측정 목적에 부합하는 Application Boundary내에서 Transaction Type(EI, EO, EQ)과 DATA Type(ILF, EIF)을 구분하여 각각을 식별하고, 각 기능(EI, EO, EQ, ILF, EIF)별로 RET & DET, FTR & DET를 계수하여 복잡도(Complexity)에 따른 UFP를 계산함.
시스템의 일반적 특성(기술, 품질, 성능) 등 14개 항목을 조사하여 총영향도(TDI)를 구하고, 이를 보정계수를 구하는 수식에 적용하여 VAF(Value Adjustment Factor)를 산출함.
UFP와 VAF를 곱하여 최종적으로 해당 시스템의 기능점수(Function Point)를 구함.

2. 측정절차

2.1 측정 타입결정
측정 타입은 측정목적에 따라 다음의 3가지 항목으로 구분됨.

개발 프로젝트(Development) : 신규 어플리케이션 개발규모 추정 및 개발 후 규모측정시
프로젝트성 개발경우로 신규구축,customized포함
개선 프로젝트(Enhancement) : 어플리케이션 개선시, 개선할 업무규모 측정시
추가,변경,삭제되는 모든 기능을 포함하여 측정
운영 (Application) : 운영중인 어플리케이션이나 패키지의 규모측정시

2.2 측정범위와 Application Boundary 정의

측정목적을 분명히 하면 측정범위는 자동으로 결정됨.
측정범위내 개별 어플리케이션 범위 역시 측정 목적에 따라 구분됨.
중복성을 배제하기 위함
기술적,시스템적 관점이 아니라 사용자의 관점에서 데이터의 그룹이 유지되는 범위를 구함.

출처 : http://blog.naver.com/jtum?Redirect=Log&logNo=50085388985

BTL, BTO 민간투자사업의 이해

JaeSoo — Tue, 12 Apr 2011 19:19:36 +0000

최근 민간투자사업 방식의 하나인 BTL사업에 대한 투자자들의 관심이 커지고 있
다. BTL사업에 대한 직접투자는 물론, 투자신탁 및 인프라펀드를 통한 간접투자도
확대되고 있는 것으로 파악된다.
BTL사업이란 민간사업자가 사회기반시설 준공과 동시에 소유권을 정부에 이전한
후 정부로부터 임대료 형태로 투자비를 지급받는 민간투자사업 추진방식을 말한다.
BTL사업의 투자메리트는 투자비 회수 원천이 정부신용도에 연계된 반면, 사업수익
률은 국고5년 + α(50~150bp)로 위험 대비 수익률이 높다는데서 찾을 수 있다.
BTL사업을 비롯한 민간투자사업에 대한 투자방법은 민간사업자에 대한 대출, 민간
사업자가 발행하는 채권 매입, 출자 등의 직접투자방식과 사회기반시설투융자회사
(인프라펀드)를 통한 간접투자 방식으로 나눠볼 수 있다.
각각의 투자에 있어서 투자위험분석은 민간투자사업에 대한 이해를 전제로 한다.
이를 위해 본고에서는 민간투자사업의 대표적인 추진방식인 BTO, BTL방식을 중심
으로 민간투자사업과 관련한 기본개념들을 살펴보고자 한다.

차례

1. 민간투자사업의 기본개념
- 민자사업의 추진 배경 및 사업추진방식(BTO, BTL)에 대한 소개
2. 민간투자사업의 투자모델
- BTO, BTL사업의 투자비 회수 구조
3. 민간사업자의 자금 조달 및 투자
- 민자사업에 대한 직접투자(출자,대출,SOC채권) 및 간접투자(인프라펀드) 소개

BTO / BTL / BOT / BOO

JaeSoo — Mon, 04 Apr 2011 16:55:57 +0000

사회기반시설공사와 관련된 다양한 방법

*** 어떠한 방법이든 민간자본을 가지고 사회기반시설을 건설한다는 의도인데,
*** 반 강제적인 외상공사라는 생각이 드는건 나뿐일까?

BTO(Build-Transfer-Operate)

사회기반시설의 준공과 동시에 당해 시설의 소유권이 국가 또는 지방자치단체에 귀속되며 사업시행자에게 일정기간의 시설관리운영권을 인정.

BTL(Build-Transfer-Lease)

  사회기반시설의 준공과 동시에 당해 시설의 소유권이 국가 또는 지방자치단체에 귀속되며, 사업시행자에게 일정기간의 시설관리운영권을 인정하되, 그 시설을 국가 또는 지방자치단체 등의 협약에서 정한 기간동안 임차하여 사용 ? 수익하는 방식.

BOT(Build-Own-Transfer)

  사회기반시설의 준공후 일정기간동안 사업시행자에게 당해시설의 소유권이 인정되며 그 기간의 만료 시 시설소유권이 국가 또는 지방자치단체에 귀속되는 방식.

BOO(Build-Own-Operate)

  사회기반시설이 준공과 동시에 사업시행자에게 당해시설의 소유권이 인정되는 방식.

출처 : http://concept.egloos.com/1058252

SI, SM, ERP, EIP, EAI, CMMS, CRM, SCM, GW, KMS 란?

JaeSoo — Wed, 22 Apr 2009 18:19:28 +0000

1. SI (System Integration)
시스템 구성 요소들을 순차적으로 결합하여 하나의 전체 시스템을 구축하는 과정으
로 일반적인 전산 시스템 개발을 말합니다. 요즘은 Java나 .net 등을 많이 이용
하지요.

2. SM (System Management)
이미 만들어진 시스템을 유지보수 하는 일을 말합니다. 프로그램 수정이나 신규
프로세스를 구현하고 데이터 관리등 많은 일을 하게 됩니다. 쉽게 말해서 일반적
인 회사 전산실에서 하는 업무입니다.

3. ERP (Enterprise Requirement Planning)
조직 전반의 관리를 할 수 있도록 만든 시스템 이구요. 그 발전 과정과 내용은
아래의 링크에서 확인 하십시오.
http://kin.naver.com/browse/db_detail.php?dir_id=10102&docid=458280

Any software system designed to support and automate the business processes
of medium and large businesses. This may include manufacturing, distribution,
personnel, project management, payroll, and financials.
ERP systems are accounting-oriented information systems for identifying and
planning the enterprise-wide resources needed to take, make, distribute, and
account for customer orders. ERP systems were originally extensions of MRP II
systems, but have since widened their scope. An ERP system also differs from
the typical MRP II system in technical requirements such as relational
database, use of object oriented programming language, computer aided
software engineering tools in development, client/server architecture, and
open system portability.

4. EIP (Enterprise Information Portal)
쉽게 생각해서 아침에 출근해서 PC 켜서 특정 홈페이지에 들어가면 우리 회사에
관련된 모든 프로세스 중에 나와 관련된 프로세스를 한눈에 파악할 수 있도록
만든 프로그램이라고 생각하시면 됩니다.
자세한 사항은 아래의 링크를 참조하세요.
http://kin.naver.com/browse/db_detail.php?dir_id=113&docid=1273

In today's competitive and ever-growing market, it takes more than just
having various applications in the right place. To carry business
successfully, the most essential and needed element is to bring multiple
resources of enterprises and people together making them responsible,
accountable and traceable. Enterprise information portals connect multiple
types of users with differentiated and personalized access to applications,
functions, and information depending on the relationship they have with the
enterprise.

5. EAI (Enterprise Application Integration)
보통의 회사에서 전산실을 가보면 여러가지 시스템들이 운영되는것을 쉽게 볼 수
있습니다. 회계 시스템, 생산 현장 관리, 홈페이지, 외부 조달 구매 등등 이런 시
스템 들을 서로 연결 시켜 주는 시스템이라고 생각하시면 됩니다.
가운데 EAI 라는걸 두고서 서로 연결하는거지요.
자세한 사항은 아래의 링크를 참조하세요
http://kin.naver.com/browse/db_detail.php?dir_id=113&docid=3

05907

The use of middleware to integrate the application programs, databases,
and legacy systems involved in an organisation's critical business processes.

6. CMMS (Cumputerized Maintenance Management System)
설비관리시스템의 진보된 형태로 생각하시면 됩니다. 단순히 설비효율관리나 자재
관리만 하는것이 아니라 설비에 관련되어 경영현황에서 파악해야될 모든 내용을
담고 있는 시스템이라고 생각하시면 됩니다.
자세한 사항은 아래의 링크를 참조하세요
http://www.emaintec.com/business/business_02_2.html

7. CRM (Customer Relationship Management)
고객들의 성향이나 우리 회사와의 관계등을 관리하여 향후에 잘 활용하고자 만든
시스템입니다. 쉬운 예로 우리가 홈쇼핑에서 물건을 사기 위해서 전화를 화면 콜
센터 담당자의 컴퓨터 모니터에 자동으로 전화건 사람의 과거 구매이력과 반품
이력등이 뜨게 되어 있습니다. 그렇게 해서 고객 대응도를 향상 시키고 충성도를
높일 수 있지요.
자세한 사항은 아래의 링크를 참조하세요
http://kin.naver.com/browse/db_detail.php?dir_id=408&docid=4853

Enterprise-wide software applications that allow companies to manage every
aspect of their relationship with a customer. The aim of these systems is to
assist in building lasting customer relationships - to turn customer
satisfaction into customer loyalty.

8. SCM (Supply Chain Management)
직역을 하자면 공급망관리 입니다. 즉, 회사의 구매와 판매에 관련된 모든 내용을
정리하고 그 연관관계를 정립하여 관리함으로서 최적의 공급망 조건을 산출해 내어
비용을 절감하고 고객 만족을 최대로 하기 위해서 만들어진 시스템입니다.
자세한 사항은 아래의 링크를 참조하세요
http://www.supply-chain.org/

The term supply chain refers to the entire network of companies that work
together to design, produce, deliver, and service products. In the past,
companies focused primarily on manufacturing and quality improvements within
their four walls; now their efforts extend beyond those walls to encompass
the entire supply chain.

9. GW (Groupware)
쉽게 생각해서 회사 게시판과 전자 결재등을 하는 시스템입니다.
즉, 특정 Group 내의 커뮤니케이션을 원할히 하는 시스템이라고 할 수 있습니다.
요즘은 Groupware에서 좀 더 진보시켜 KMS로 팔고 다니는걸로 알 고 있습니다.

Software tools and technology to support groups of people working together on
a project, often at different sites.

10. KMS (Knowledge Management System)
지식관리시스템이라고 불려저서 뭔가 어려운 것이라 생각됩니다만, 간단히 축약
하면 회사에서 만들어지 문서들을 체계적으로 잘 불류해서 정리 할 수 있도록
하는 시스템이라고 할 수 있습니다.
언제 어디서 뭘 할려고 하는데 전에는 어떻게 했는지... 어떤 문서가 있었는지를
찾을 수 있도록 하는것이지요.
기존에는 DM (Document Management)라는 이름으로 불리우다가 GW의 기능을 흡수하
고 몇가지 철학을 보태서 KMS라고 불리웁니다.
http://kin.naver.com/browse/db_detail.php?dir_id=409&docid=17063

A distributed hypermedia system for managing knowledge in organisations.
KMS is a commercial system from Knowledge Systems, Inc. running on
workstations, based on previous research with ZOG at Carnegie Mellon
University.

출처 : http://blog.naver.com/hound9/3952640

핵심성과지표 (KPI: Key Performance Indicator)

JaeSoo — Sun, 26 Oct 2008 23:10:11 +0000

KPI에 대해

1. KPI란?

KPI란 Key Performance Indicator의 준말로서, 기업 내부의 핵심 성과 지표를 의미한다.

신규 거래선 개척 건수, 수입 검사 LOT 불합격율, 부품 Return 불량율, 연구 성과 대비 연구 비율, 연구소 경비/투자/인건비율, 고객 Claim 건수, 납기 준수율, 장기 계약 체결 건수/금액 등 업무의 분야별 성과를 말한다.

이러한 업무 성과는 과거에도 측정되어 왔던 것이지만 최근 KPI라는 단어가 자주 등장하게 된 것은 Robert Kaplan 및 David Norton이라는 사람이 BSC(Balanced Scorecard)라는 개념을 기업에 소개하면서 그 도구 중 하나로 KPI를 소개하고 있기 때문이다.

BSC는 국내 기업에도 이미 도입되고 있는데 기업의 전략을 단위 조직의 업무에 까지 전개하여 소기의 기업 목표를 달성하자는 기법이다. 이 방법으로서 단위조직의 業務 성과를 KPI라는 지수로 표현하게 하고 측정하는 것이 된다(ABB의 전 회장인 퍼시 바네빅은 ‘측정하지 않으면, 행해지지 않고 고쳐지지도 않는다’고 말한 적이 있다. 이는 기업, 부서, 개인의 성과 개선을 위해 활동 결과를 측정하는 것이 얼마나 중요한가를 강조한 말이다. 측정하지 않고서는 최종 성과가 어떤 수준인지, 성과에 문제가 있다면 무엇 때문인지, 그리고 이를 어떻게 개선할 것인지를 파악하는 것이 근본적으로 불가능하다. 그러나 여기에 많은 관리자들의 고민이 있다. 즉, 무엇을 측정할 것인가 -What to manage-의 문제 때문이다).

● 기존의 대표적인 성과 지표와의 차이점

많은 기업에서 이제까지의 주된 성과 지표는 매출, 비용 등 명확한 재무 성과 위주였다. 이는 물론 측정 가능성을 고려한 결과이며, 또한 재무 성과의 측정은 향후에도 필요하다. 하지만 정량적으로 측정할 수 있는 것이 재무적 성과만은 아니다. 특히 재무 성과 위주로 측정하는 것은 몇 가지 문제를 가지고 있다. 첫째, 재무적 성과는 과거 활동의 성과이다. 측정의 목적은 과거를 평가하는 것뿐만 아니라 미래 성과를 예측하는 것도 있다. 따라서 미래 성과를 예측/반영하지 못하는 재무적 지표는 바람직한 측정에 한계가 있다. 둘째, 재무 성과 지표는 최종 활동의 결과만을 보여 줄 뿐, 어떠한 활동/과정을 통해 성과를 달성할 것인지에 대한 정보를 전혀 주지 못한다.

재무 성과 지표 위주의 측정에 문제가 있음을 인식한 일부 기업의 경우, 재무적 지표 외에 가능한 한 많은 지표를 활용하여 측정하기도 한다. 그러나 이러한 측정 방식 역시 문제를 가지고 있다. 즉, 측정은 회사가 원하는 방향으로 구성원들의 사고/행동을 유도하는 데에도 목적이 있다. 따라서 많은 지표를 활용한다는 것은 구성원들의 사고/행동의 초점을 불명확하게 하고, 궁극적으로 구성원들의 의욕 저하를 초래할 수도 있다. 이러한 현상이 발생하는 것은 무엇을 측정할 것인지에 대해 확신이 없기 때문이나, 그 실질적인 원인은 성과 지표에 반영되어야 할 사업 성공 요인에 대한 공유된 인식 부족, 그리고 사업 성공 요인과 성과 지표간의 인과 관계에 대한 이해가 부족하기 때문이다.

2. 기업체에서의 KPI 수립 효과

A. 활동 성과에 대한 투명성 요구

IMF이후, 사회 전반적으로 활동 성과를 투명하게 공개하여야 한다는 인식이 확고히 자리잡고 있다. 이는 기업 단위 뿐만 아니라 기업 내부의 임원, 단위 조직 및 개인 단위까지 확대될 필요가 있다. 이는 국내 투자를 원하는 국제 사회의 경제계의 요구이며 우리나라가 선진 경제로 진입하는 데에 필수적인 과제이다. 실제 활동 성과를 있는 그대로 공개/평가될 수 있는 기반을 마련한다는 것은 기업 내적으로도 매우 효율적인 이윤 창출의 기반이 된다.

B. 성과주의 보상의 필요성

사실 우리 기업들은 그 동안 성과 평가의 중요성을 그다지 크게 느끼지 않았다. 기업전체의 양적 성장을 중요시 하는 분위기 하에서 기업 내부 조직 단위의 활동 성과 파악에 해서는 그다지 큰 관심을 둘 여력이 없었을 뿐 아니라, 연공 서열 위주의 인사 관리 시스템으로 인해 성과 평가를 통한 차별 관리가 어려운 점이 있었기 때문이다. 그러나 경영 활동의 효율화 및 종업원의 동기부여를 위해 기업 내부 하위 조직 단위의 성과 파악이 매우 중요해지고 있으며, 성과중심의 급여 시스템이 도입되면서 활동성과를 있는 그대로 나타낼 수 있는 KPI의 재정립 필요성이 높아지고 있다.

3. KPI 도입 목적

A. 임직원에 대한 동기 부여

KPI를 정립하는 외형적인 목적은 물론 활동 성과를 제대로 평가하는 데에 있다. 그러나 이를 KPI의 궁극적인 활용 목적이라고는 할 수가 없다. 왜냐하면 기업 활동의 목적이 평가 활동 자체가 아니기 때문이다. 그러면 평가는 왜 하는가? 평가는 업무를 수행하는 구성원들과 정기적으로 커뮤니케이션 하는 수단이며, 이를 통해 구성원들로 하여금 보다 높은 성과를 창출하도록 동기 부여하는 데 그 궁극적인 목적이 있다.

결국 KPI를 도출하고, 활용하는 궁극적인 목적은 구성원들을 기업이 원하는 방향으로 동기 부여하는 데에 있는 것이다.

따라서 KPI를 도출할 때 가장 중요하게 고려되어야 할 원칙은 바로 KPI 활용을 통해 구성원들을 동기 부여할 수 있느냐의 여부이다. 특히 바람직하지 못한 KPI를 활용할 경우에는 구성원들의 사고/행동의 초점을 잘 못된 방향으로 이끌게 되며, 이는 궁극적으로 구성원들의 의욕 저하를 초래하고, 기업 전체의 성과 저하도 초래하는 결과를 가져올 수 있음을 명심할 필요가 있다.

4. KPI 도입시의 고려 사항

KPI 도출 시에는 관리 중요성, 통제 가능성, 그리고 측정 가능성을 고려하여야 한다. 그렇지 못한 KPI는 구성원을 동기 부여하지 못하는 등 그 활용에 있어 한계를 지닌다.

A. 관리 중요성

관리 중요성이란 경영 활동을 대표할 수 있는 핵심 요인 중심으로 성과 지표를 선정하는것을 의미하며, 이를 통해 업적 평가의 타당성(Validity)을 높일 수 있다. 특히 관리 중요성이 높은 지표를 KPI로 활용함으로써 구성원들로 하여금 회사 전체의 성과 향상을 위해 스스로가 중요한 역할을 담당하고있다는 인식을 줄 수 있기 때문에, 관리 중요성은 구성원들을 동기 부여하는 데에 매우 중요한 요인이다.

관리 중요성을 기준으로 KPI를 도출할 경우, 기업이 추구하는 전략 방향이 먼저 고려되어야 한다. 기업이 추구하는 전략 방향이란 일반적으로 기업의 성장 단계에 따라 달라진다.

예를 들어 기업이 성장기, 성숙기, 수확기 등 어떠한 라이프 사이클 단계에 있는가에 따라 KPI 개발의 초점이 달라져야 한다.

성장기에 있는 기업의 경우, 생산 설비의 건설 및 확장, 운용 역량의 구축, 고객과의관계 설정을 중심으로 KPI를 개발하는 것이 필요하며, 반면

성숙기에 있는 기업의 경우,현 시장 점유율 유지 및 향상, 투하 자본으로부터의 수익 극대화 등과 같은 방향에 의거하여 KPI를 개발하는 것이 필요하다.

사업 성공 요인을 잘못 파악한 상태에서 KPI를 도출/활용할 경우, 부정적인 결과를 초래할 수 있다. 그 대표적인 사례로서 미국의 어떤 패스트푸드 업체를 들 수 있다.

동사의 경우, 비용 절감을 위해 운용비중 가장 많은 부분을 차지하는 재료비의 삭감에 초점을 두고, 점포의 성과를 평가하는 핵심 지표로서‘치킨 효율성 (Chicken Efficiency)’을 도입하였다. 이는 고객이 실제 주문하기 전에 매장에서 사전 조리를 함으로써, 팔리지 않고 버려지는 원재료의 낭비를 줄이자는 취지에서 였다. 이러한 지표를 점포의 평가 지표로 도입하자마자, 점포 종업원들은 고객에게 제공되는 음식을 사전에 준비하지 않게 되었으며, 당연히 재료비는 원래 목적대로 줄어들게 되었다. 하지만 이는 사업 성공에 있어 가장 중요한 요인인 고객을 고려하지 않는 결과를 초래하였다. 예를 들어 고객들은 주문 후, 15 ~ 20분을 대기하여야만 했고, 이는 고객 불만족으로 연결되었다.

결국 잘못된 KPI를 선정함으로써 기존자사의 핵심 고객마저 잃어버리는 결과를 초래하였고, 이는 기업을 도산 직전까지 몰고 갔다.

● 관리 중요성을 고려한 KPI 도출 방식 2가지:
1) 성과트리 방식, 2) 성과 동인간의 인과관계도 작성 방식

1) 성과트리 방식

기업의 전략 방향을 반영, 관리할 중요 지표를 선정하는 방식으로는 크게 두 가지를 고려할 수 있다. 그 하나의 방법은 성과 트리의 작성을 통해서 이다. 특히 성과 트리의 작성은 기업이 관리하여야 하는 활동이나 지표를 체계적으로 파악할 수 있다는 장점이 있다.

그러나 성과 트리 방식을 활용할 경우,몇 가지 점에서 주의가 요구된다.

첫째, 성과 트리 작성 시의 출발점은 기업이 지향하는 가치나 방향이 되어야 한다는 것이다.

둘째, 성과 트리의 작성 시에는 기업 내에서 수행되고 있는 활동들이 빠짐없이 포함되어야 한다.

셋째, 지표와 성과 동인 활동에 대한 구분 인식이 필요하다. 예를 들어‘EVA 제고’라는 활동은 EVA 절대 금액, 전년 대비 EVA 증가율, 경쟁사 대비EVA 개선율 등과 같이 다양한 KPI로 연결될 수 있기 때문에, 성과 동인을 KPI로 연결시키기 위해서는 또 다른 작업 과정이 필요하다는 것을 이해할 필요가 있다.

2) 성과 동인간의 인과관계도 작성 방식

기업의 전략적 방향을 고려하여 중요지표를 선정하는 두 번째 방법은, 사업 성공요인에 영향을 미치는 성과 동인간의 인과관계도(Cause-and-Effect Map)를 작성하는 것이다.

인과 관계도의 작성 시에도 물론 기업이 지향하는 전략 방향을 고려하여 작성해야 하며, 이를 보면 기업의 전략적 의도를 알 수 있을 만큼 구체화하는 것이 필요하다. 기업 특유의 상황을 반영한 성과 트리나 인과 관계도를 활용하여 KPI를 도출할 경우, 전사적인 지향 가치와 하위 활동간에 인과 관계를 추정하는 것이 가능하다.

B. 통제 가능성

KPI를 구성원들의 업무 방향 제시 및 동기부여 요인으로 활용하기 위해서 도출된 KPI는, 구성원들이 자신의 업무 권한 범위 내에서 직접 통제할 수 있는 것이어야 한다. 자신이 직접 통제할 수 있는 KPI가 아닐 경우,구성원들의 의욕 저하를 가져올 수밖에 없기 때문이다.

특히 우리 기업들이 과거에 활용하였던 지표를 보면, 통제 가능성이 낮은 지표를 많이 활용해 온 경향이 있다. 이는 과거 우리 기업에서 하위 조직 단위에 성과 지표를 부과하는 방식이 일반적으로 탑-다운 방식이었으며, 탑-다운 방식으로 할당된 성과 지표에 대해서는 자신이 통제 가능한지, 그렇지 않은지에 대해 논란을 벌이는 것이 허용되는 분위기가 아니었기 때문이다.

또한 우리 기업들의 조직 운영 방식이 수평 조직(Horizontal Organization)과 같이 해당 프로세스와 관련된 업무를 통합 수행하는 것이 아니라, 각 기능별로 업무를 분화해서 수행하는 체제였기 때문에 지표의 통제 가능성 측면에서 문제가 발생하기 쉬웠다.

● 통제 가능성을 고려한 KPI 도출 방식

통제 가능성을 고려하여 KPI를 도출하고자 할 때에는 다음 몇 가지 점을 고려하는 것이 필요하다.

첫째, 전사적인 조직 운영 방식에 대한 고려가 필요하다. 예를 들어 전사적인 조직운영 방식이 협조적인 업무처리방식을 강조하고있는가, 아니면 각 부문간의 경쟁적 업무 처리 방식을 강조하는가에 따라 KPI의 관리 책임 부여 방식이 달라져야 한다.

통제 가능성을 고려하여 KPI를 도출하고자 할 때의 둘째 고려 요인은 미션과 업무 분장표에 의해 관리 책임을 부여한다는 것이다. 이는 회사 내부의 공식적인 규정에 의해 작업하는 것이기 때문에 적용에 무리가 없다는 장점이 있으나, 실제 우리 기업의 경우 미션이나 수행 업무 분장이‘위인설관식으로 자주 변화되기 때문에 엄격하게 적용하기 어렵다는 단점이 있다.

셋째 고려 요인은 업무 담당자와의 컨센서스를 중요시하여야 한다는 것이다. 아무리 과학적이고 합리적인 방식으로 KPI를 개발하였다 하더라도, 개발된 KPI를 업무 담당자가 수용하지 않으면, 아무런 소용이 없기 때문이다.

C. 측정 가능성

측정하지 않으면, 행해지지 않고 고쳐지지도 않는다’라는 말이 있다. KPI로 활용되기위해서는 기본적으로 측정 가능하여야 한다. 측정하지 않고서는 최종 성과가 어떤 수준인지, 성과에 문제가 있다면 무엇 때문인지, 그리고 이를 어떻게 개선할 것인지를 파악하는 것이 어렵기 때문이다.

측정 가능성을 고려한 KPI를 개발할 경우, 여러 가지의 성과 동인을 종합적으로 반영한 통합 지표를 개발하는 것이 바람직하다.

예를 들어 품질의 다양한 요인에 대해서는 고객 특성별로 중요도를 달리 적용한 종합 품질 지수(OQI : Overall Quality Index)를 개발하여 활용하거나,

고객 만족의 개별 지표는 고객 만족 지수(CSI :Custom er Satisfaction Index)로, 그리고

구성원 만족도와 관련된 개별 측정치는 구성원 만족 지수(ESI : Employee Satisfaction Index)로 종합하여 활용하는 것이 바람직하다. 또한 측정 방식의 개선을 통해서 관리 중요성이나 통제 가능성을 개선할 수 있기 때문에 측정 방식에 대한 정교한 정의도 매우 중요하다.

금융업체의 KPI 개발 사례

● 배경

동사는 유럽에 위치한 소규모 은행으로서 약 1200여명의 직원으로 구성되어 있었다. 설립 초기부터 지역 중심의 영업과 고객 충성도가 높은 고객집단을 기반으로 영업을 전개하였다.

그러나 지역 경쟁 은행들의 신상품 제공 등 치열한 경쟁으로 인하여 동사는 자사의 고객 및 시장 점유율을 지속적으로 잃어가고 있었다. 특히 운영과 관련된 비용이 지속적으로 높아지고 있다는 점은 자사의 수익을 개선하는데 큰 장애 요인이 되고 있었다. 이러한 상황하에서 회사의 경영진은 생존을 위한 근본적인 개선이 필요함을 공통적으로 인식하고 있었다.

● 사업 성공 요인에 대한 재정의

회사가 처한 외적 상황 및 자사의 운영 현황 등을 종합적으로 분석한 후, 동사의 경영진들은 자사의 전략적 방향을 2가지 측면에서 근본적으로 변화시킬 필요가 있음을 확인하였다. 그 첫째는 원가 경쟁력(Cost Leadership)을 갖춘 은행으로의 개선이었다. 이를 위해서는 특히 운영 비용을 낮출 필요가 있었으며, 운영 비용 증가의 주요 요인이 되는 인력 및 업무의 자동화율을 개선할 필요가 있었다.

둘째는 채널의 변화가 필요하였다. 즉 자사의 핵심 고객인 나이가 많은 고객 층에서도 고객 자신의집 근처 영업점을 찾기보다는 텔레폰 뱅킹이나 인터넷을 활용하는 비중이 늘어나고 있었기 때문이다.

● 핵심 역량 확보 방식의 재정의

사업 성공 요인에 대한 재정의를 바탕으로 하여, 동사는 각 부문의 핵심 인력을 중심으로 전사적인 역량 확보 방식에 대한 논의를 전개하였다. 즉, 원가 경쟁력이 있는 은행, 고객에게 쉽게 접근할 수 있는 은행을 기본적인 전략 방향으로 하여, 이를 달성해 나갈 수 있는 세부적인 요인들을 점검하였다. 이러한 논의는 기본적으로 인과 관계도(Cause-and-Effect Map)의 작성을 통해 이루어졌다.

● 측정 방식에 대한 재정의

전사적인 사업 성공 요인과 이를 위한 핵심 역량 확보 방식에 대한 인과 관계도를 작성한 후, 이를 바탕으로 구체적인 지표 및 지표의 목표 수준을 설정하였다. 예를 들어 운영비 2 5 % 감소, 매출 10% 이상은 새로운 영업 채널을 통해 달성한다는 것과 같은 방식 이었다.

유통업체의 KPI 개발 사례

● 배경

동사는 네덜란드의 유통업체 중 시장을 리드하는 선도 기업으로서, 약 16,000여명의 직원으로 구성되어 있었다. 특히 동사의 주력 사업 분야인 수퍼마켓 사업은 고객들에게 높은 수준의 서비스 및 상품으로 좋은 평가를 받고 있었으며, 이로 인해 고객들은 다른 수퍼마켓보다 조금 가격이 비싼 상품에 대해서도 기꺼이 수용하는 모습이었다.

그러나 최근 들어 소규모 업체를 중심으로 IT를 사업 운영에 도입하여 보다 높은 고객 만족을 달성하는 경쟁사 출현 등 자사의 성과가 조금씩 하락하는 조짐을 보이게 되었다.

● 사업 성공 요인에 대한 재정의

동사의 경영진들은 기존 고객에 대한 충성도 재확보 및 신규 고객을 보다 적극적으로 개척하는 것이 필요하며, 이를 위해서는 기존의 전략 방향인‘유통 및 판매 중심의 조직(Distribute and Sell Organization)’을, 보다 고객 중심적으로 변화시켜야 한다는 판단을 하게 되었다. 즉, 보다 높은 고객만족을 위해서는‘인지 및 대응의 유통 업체 (Sense and Respond Retailer)’로의 조직 운영 방향의 전환이 요구되었다.

● 핵심 역량 확보 방식의 재정의

사업 성공 요인에 대한 재정의를 바탕으로 5개 점포에서 핵심 역량 확인을 위한 파일럿 테스트가 수행되었다.이러한 테스트를 거쳐, 새로운 전략 방향 추진에 필수적인 요인들이 구체화되었다. 각 점포로부터의 제출된 핵심 요인들은 전사적인 워크숍을 통해 보다 구체적인 핵심 역량 인과 관계도로 종합 작성되었다.

● 측정 방식에 대한 재정의

전사적인 사업 성공 요인과 그에 관련된 핵심 역량 확보 방식에 대한 인과 관계도를 작성한 후, 이를 바탕으로 구체적인 지표 및 지표의 목표 수준을 설정하였다. 예를 들어 매년 매출 5 % 증가, 인력 운영비의 최고 10% 감소, 재고 비용의 5 % 감소, 구성원 교육5 0 % 증가 등과 같은 지표를 설정하였다. 끝.

- 드림힐 고객사의 KPI 개발에 참고한 내용 중의 하나로서
삼성경제연구소(SERI) KPI 연구모임 글에서 발췌하였다-

출처 : http://eq21.net/cgi-bin/technote2002/read.cgi?board=ts_word&y_number=61

엔터프라이즈아키텍처(EA)/정보기술아키텍처(ITA)

JaeSoo — Tue, 23 Sep 2008 16:54:33 +0000

최근 1~2년새 주요 대기업과 공공기관을 중심으로 엔터프라이즈아키텍처(EA) 프로젝트가 활발하게 진행되고 있습니다.

일부에서는 정보기술아키텍처(ITA)라는 개념을 쓰기도 합니다. 최근에 등장한 EA는 아직까지 진화중인 개념으로 볼 수 있습니다.

전문가들에 따라 EA에 대한 정의는 제각각이지만,

일반적으로 `조직 및 업무 활동, 정보기술간의 관계에 대해 현재의 모습과 향후 추구해 나갈 모습을 정의해둔 청사진'이라고 정의할 수 있습니다.

◇왜 EA를 주목하는가=기업의 경쟁환경이 갈수록 복잡해지고 있는 만큼 기업의 최고정보책임자(CIO)들은 외부환경에 실시간으로 대응할 수 있는 IT인프라와 전략을 확보하고 있어야 합니다.

개별 기업이 처한 환경에 따라 여러 가지 목표가 있을 수 있겠지만, CIO들의 공통된 IT화두로는 단순성, 적응성, 재사용성 등 크게 3가지를 들 수 있습니다. 가급적 기업의 정보 관련 자원을 단순하게 하고, 기존 IT자원의 재사용성을 최대한 높임으로써 변화에 신속하게 대응할 수 있는 기반을 갖추자는 것입니다.

이같은 전략을 추구하기 위해서는 당연히 조직내 정보화 현황과 추구하는 목표에 대한 밑그림을 확보하고 있어야 합니다. EA를 얘기하면서 청사진이니, 설계도니 하는 표현을 쓰는것도 이 때문입니다.

따라서 EA는 정보화 밑그림에 포함되는 각종 요소, 즉 비즈니스아키텍처 애플리케이션아키텍처 데이터아키텍처 기술아키텍처 등에 대한 정보를 잘 파악하는 것이 핵심과제라고 할 수 있습니다.

여기에서 더 나아가 이들 요소간의 관계를 잘 정의해 특정 요소가 변화할 경우 다른 요소에 미치는 영향을 체계적으로 파악하고 관리할 수 있어야 합니다. 예를 들어 비즈니스 환경이 변화할 경우 당연히 애플리케이션이나 데이터 등 시스템에도 영향을 미치게 되는데, 이런 변화를 잘 파악하고 관리할 수 있어야 한다는 것입니다.EA를 도입하면, 몇가지 효과를 거둘 수 있습니다.

우선 각종 표준을 잘 준수할 수 있습니다. 또 내부시스템의 통합작업을 효율적으로 추진할 수 있을 뿐만 아니라 외부 시스템과의 호환성을 높일 수 있습니다. 표준을 잘 준수하게되면 제반 IT비용을 절감할 수 있습니다. 중복된 시스템을 제거하고, 업무 프로세스가 개선되는 효과도 거둘 수 있죠.물론 이같은 효과들은 단순히 EA를 도입한다고 자동적으로 주어지는 것은 아닙니다.

EA를 제대로 도입하고, 잘 활용해야 거둘 수 있는 것입니다. 건물의 설계도나 도시계획의 청사진을 확보하고 있다고 해서 건물의 준공이나 리모델링시, 혹은 도시계획을 추진할 때 기대한 만큼의 고품질이 무조건 보장되는 것은 아니라는 점을 보면 잘 알 수 있습니다.

◇국내 EA현황과 과제=국내에서는 지난해부터 금융기관의 차세대시스템 구축 계획 수립, 공공기관이나 대기업의 IT전략 계획 수립 등에 EA가 활발하게 접목되고 있습니다.

특히 정보통신부가 주도하고 있는 ITA법이 국회를 통과함에 따라 앞으로 공공부문의 EA 프로젝트는 더 활발해질 전망입니다.하지만 국내에서 EA를 도입한 기업이나 기관들의 성과를 평가하기에는 아직 이르다는 것이 전문가들의 일반적인 평입니다. 앞서 언급했듯이 단순히 청사진을 확보하는 것 뿐만 아니라 내부적으로 모든 IT활동에 EA를 적용해 나가는 것이 더 중요하기 때문입니다. 국내 EA 수준은 이제 IT인프라나 IT추진계획에 대한 초보적인 청사진을 확보한 수준에 불과합니다.그런 점에서 우리가 EA 도입을 위해 가장 많이 참조했던 미국 연방정부의 EA 활동은 많은 교훈을 주고 있습니다.

미국은 지난 96년 정보기술관리혁신법(ITMRA)을 도입해 연방정부 부처들이 의무적으로 EA를 도입하도록 했습니다. 하지만 지난 10년간 EA를 추진해 온 미국의 정부부처들도 EA 성숙도 측면에서는 여전히 초기단계인 `레벨1' 수준에 머물고 있습니다. 이는 미국 연방정부도 인정하듯이 목적 없이 아키텍처를 작성하는 데만 열중했기 때문입니다.EA는 잘못하면 각종 도형이나 지침으로 이뤄진 문서로만 남을 수도 있습니다.

효과적인 정보화 투자 및 정보자원의 관리를 위해 EA를 어떻게 활용할 것인가 하는 점을 경영진부터 현업관리자에 이르기까지 충분히 공감하고, 활용하는 것이 무엇보다 중요합니다.

우리도 EA를 무슨 만병통치약으로 생각할 것이 아니라 효과적인 정보관리를 위한 첫 출발로 인식하는 자세가 필요합니다. 모든 개선 및 혁신활동이 그렇듯이 공감대와 지속적인 추진노력 없이는 결과도 없는 것입니다.

박서기기자@디지털타임스

출처 : http://blog.naver.com/hongjig/150001681169

델파이 기법 개요

JaeSoo — Fri, 08 Aug 2008 10:40:13 +0000

1. 델파이기법

1) 개념

델파이기법은 한 나라의 연구수준이나 미래의 특정시점을 예측하는 경우, 특히 현재의 상태에 대한 일반화, 표준화된 자료가 부족한 경우 전문가적인 직관을 객관화하는 예측의 방법으로 많이 사용되어지는 기법이다. 다시 말하면 본 연구의 예측조사의 방법으로 사용되는 델파이기법은 내용이 아직 알려지지 않거나 일정한 합의점에 달하지 못한 내용에 대해 다수의 전문가의 의견을 자기기입식 설문조사방법이나 우편조사방법으로 표준화와 비표준화 도구를 활용하여 수회에 걸쳐 피드백(feedback)시켜 그들의 의견을 수렴하고 합의된 내용을 얻는, 소위 전문 집단적 사고를 통하여 체계적으로 접근하는 일종의 예측에 의한 정책분석 방법이라고 볼 수 있다. 델파이기법과 똑같지는 않지만 의도적인 면에서 비슷한 방법으로 이루어지는 브레인스토밍이 있다.

2) 어원 및 대두

델파이기법의 어원은 고대 그리스 아폴로 신전인 델파이 신전에서 나왔다. 델파이 신전은 그 시대 가장 존경받는 성지이었으며, 아폴로는 젊음과 완벽한 미로 유명하며, 미래를 통찰할 수 있는 능력을 가진 신으로 알려져있다. 델파이라는 말은 미국 RAND 연구소의 철학자 Kaplan에 의해 고안되었고, 1950년 대 Helmer, Dalkey와 Douglas사의 Gorden 등이 국방성의 요청에 따라 미국에 대규모 원자탄 공격이 가해졌을 경우 예상되는 효과를 평가할 목적으로 델파이기법을 개발하였다. 델파이기법은 전통적인 회의식기법이 갈등이 심하고 토의 분위기에 영향을 받아 주관적 판단을 흐리게 된다는 비판위에서 대두되었다.

3) 발전

1950년에서 1963년까지 14개의 델파이 연구가 진행되었으나 연구가 군에서 이뤄짐으로써 그 결과는 베일에 가려져있었다. 1963년 처음으로 델파이법을 기술한 논문이 발표되었고, 1964년 Gordon과 Helmer에 의해 "장기예측에 관한 연구보고서(Report on a long-range forecasting study)"가 출간되면서 델파이기법은 전세계적인 관심을 불러 일으켰다.

델파이기법은 1960년대 중반부터 산업계의 기술발전을 예측하는데 광범하게 활용되기 시작하였고, 그 후 미래예측뿐만 아니라 조직의 목표설정 및 정책수립에 이르기까지 적용 영역이 확대되었으며, 정부나 기업, 학술 연구 등에서 가장 대표적인 비계획적 예측방법으로 널리 활용되고 있다.

4) 의의

델파이기법은 논리적이고 체계적인 분석보다는 전문가의 의견에 따라 정책결정이 이루어지는 경우가 대부분인 현실의 상황에서 볼 때, 그 어떤 방법보다도 논리적이며 객관적으로 체계적인 분석을 수행하고, 수차례에 걸쳐 피드백 시킴으로써, 다수의 전문가들의 의견을 종합하여 보다 체계화객관화시킬 수 있는 매우 유용한 기법이다.

5) 특징

델파이기법은 각 전문가들에게 개별적으로 설문서와 그 종합된 결과를 전달, 회수하는 과정을 거듭함으로써 독립적이고 동등한 입장에서 의견을 접근해 나갈 수 있도록 하려는 것이다. 따라서 설문서의 응답자는 철저하게 익명성이 보장되므로 외부적인 영향력으로 결론이 왜곡되거나 표현이 제한되는 예가 매우 적다. 또한, 통제된 피드백(feedback) 과정을 반복하기 때문에 주제에 대한 계속적인 관심과 사고 촉진종합된 의견의 전달은 질문서에 대한 답을 집계하는 형식으로 이루어지게 된다. 따라서 통계적으로 의견을 처리하여 제시함으로써 그룹 내의 의견 차이 정도를 보여주고, 강한 소수의견에 대해서도 내용을 파악할 수 있도록 해준다. 하지만 질문서에 의지하는 경향이 나타나므로 질문서 자체가 잘못되면 델파이조사 자체가 잘못될 수 있는 결정적인 문제점도 가지고 있다.

6) 내용

(1) 델파이기법의 종류

① 전통적인 델파이기법: 일반 델파이라고도 한다. 미지의 값을 예측하는 델파이기법으로써 특정 사안이 야기될 시점이나 그것이 성취될 수 있는 가능성을 조사하는 수량적 델파이기법과 가깝다. 이와 같은 델파이기법의 주요 목표는 어떤 사안에 대해 수량적 예측을 최대한 구체화하는 것이다.

② 정책 델파이기법: 델파이기법의 기본 논리를 이용하여 정책문제 해결을 위해 정책대안을 개발하고 정책대안의 결과를 예측하기 위해서 전문가나 정책결정자가 심각하게 생각하지 못했거나 미처 생각하지 못한 것들을 주관적인 입장에 있는 정책관련자에게 서로 대립되는 의견을 표출하게 하고 점검하는 방법이다. 그리고 정책델파이기법은 정책이나 의사결정을 위한 메카니즘이 아니라 정책이슈를 분석하기 위한 도구이며 의견개진을 위한 방법이다. 따라서 전통적인 델파이기법과는 많은 차이를 보인다.

③ 의사결정 델파이기법: 어떤 현실을 보기 위한 것이 아니라 현실을 창조할 목적으로 이루어지는 의사결정의 도구로써 활용되는 델파이기법이다.

* 전통적(일반) 델파이기법과 정책 델파이기법의 차이점

구분

- 전통적(일반) 델파이기법

- 정책 델파이기법

개념

- 일반 문제에 대한 예측

- 일반 델파이를 정책문제에 도입한 것

대상자

- 일반 전문가를 대상자로 선정

- 정책전문가와 정책관계자를 대상자로 선정

익명성

- 철저한 격리성과 익명성 보장

- 선택적 익명성 보장 (중간에 상호교차 토론 허용)

분석 방법

- 의견의 평균치(중간치) 중시

- 극단적이거나 대립된 견해도 존중하고 이를 유도

(2) 전문가의 선정기준

델파이기법에 있어서 전문가 선정에 대한 문제는 매우 중요한 문제이다. 원래 델파이기법이 전문가적 직관을 객관화된 수치로 나타내는 방법이기 때문에 조사에 참여한 전문가의 자질은 매우 중요시 될 수밖에 없는 것이다. 이에 따라, 전문가의 선정 기준으로는 다음과 같은 기준들이 제안되고 있다.

① 전문가들은 응답을 하는 데에 필요한 필수적 지식을 적어도 평균적인 수준 이상을 갖고 있어야 한다.

② 조사에 참여하는 전문가들은 지리적으로 골고루 퍼져 있어야 한다.

③ 전문가들은 합리적이고 객관적이며 편향되지 않은 사고를 할 수 있어야 한다.

④ 전문가들은 조사에 열성적으로 참여하여야 한다.

⑤ 전문가들은 델파이 과정에 소요되는 수 주일간의 시간을 낼 수 있어야 한다.

(3) 델파이기법의 단계

① 관련 분야 전문가 집단 구성: 알고자 하는 내용에 대해 가장 잘 알고 있으리라고 믿어지는 전문가를 30명에서 최고 100명까지 선정하여 패널을 구성한다.

② 1차 질문: 구성된 패널을 통해 개방형 질문을 하여 그들의 견해를 모두 나열함으로 가능한 많은 자료를 수집분석하여 항목으로 구성, 폐쇄형 질문지를 만든다.

③ 2차 질문: 이 폐쇄형 설문지를 동일 대상자에게 보내는 2차 질문을 실시한다. 이 때는 문항에 점수를 주거나 중요도를 측정하여 일정수의 중요 문항을 선택하게 한다.

④ 3차 질문: 수집된 결과를 항목별로 종합하여 전문가 전체의 항목별 도수, 평균, 또는 표준편차 등을 제시하여 다시 동일 집단에게 보내어 중요 문항을 선택하게 한다.

⑤ 4차 질문피드백: 셋째 단계의 결과를 가지고 면담을 실시한다. 이와 같은 방법으로 전문가들 사이에 어떤 합의점을 찾을 때까지 여러 차례의 설문을 통하여 최종 결과로 얻는다.

7) 장점 및 한계

(1) 장점

① 편향된 토의에 쏟는 시간과 노력의 낭비를 줄일 수 있다.

② 연구자에 의해 통제되기 때문에 초점에서 크게 빗나가지 않는다.

③ 시간적경제적(회의비체제비여건비 등)으로 절약할 수 있다.

④ 협의회 보다 시간빈도 등이 덜 제약 받는다.

⑤ 다수의 전문가 의견을 수렴, 피드백(feedback) 할 수 있다.

⑥ 익명성이 있고 독립적이기 때문에 자유롭고 솔직한 전문가의 의견을 들을 수 있다. ⑦ 몇몇 사람의 의견이나 분위기에 말려 휩쓸리지 않는다. 또한 체면이나 위신에 의해 다른 결정을 하지 않는다.

(2) 한계

① 질문지 조사방법 자체에 결함이 있을 수 있다. 또한 문제가 참여자들에게 맡겨 만지기 때문에 문제의 확실한 속뜻을 알기가 어렵다.

② 다른 질문지와 마찬가지로 회수율이 높지 않다. 조사가 1234 반복되어감에 따라 회수율은 점점 낮아지게 된다.

③ 반복적 조사이기 때문에 조사를 끝내려면 장기간이 필요하다. 단기간의 조사는 용이하지 않다.

④ 문제와 처리 결과를 직접 주고받을 수 없다.

⑤ 통계적 처리 결과에 무의식적으로 따라갈 수 있다.

⑥ 현재성을 중시하는 현대인에게 미래에의 무관심을 나타내게 할 수 있다.

⑦ 한두 가지의 확신만을 가지고 미래를 볼 경우, 미래를 단순화 할 수 있다.

⑧ 전문가들이 과도한 확신으로 환상적이거나 체제 전체를 판단 못하게 할 수 있다.

⑨ 조작적 가능성도 가지고 있다.

⑩ 참여 전문가들이 설문에 대하여 신중하지 못할 수 있다.

⑪ 델파이조사에 의한 예측 연구는 불확실한 상황을 연구대상으로 삼고 있다는 기본적인 한계를 가지고 있다.

※출처 : http://blog.naver.com/vkskwm/120013954846

BPR의 모든것

JaeSoo — Fri, 08 Aug 2008 10:39:36 +0000

BPR의 등장배경

단어의 뜻에서 알수 있듯 BPR(Business Process Reengineering)은 ‘기업의 업무 프로세스를 혁명적으로 고치자’는 것을 의미한다. 쉽게 말해, 회사에서 벌어지는 모든 일들의 처리과정을 A에서 Z까지 한꺼번에 고쳐서 그 개선효과를 극대화하자는 의미이다.

BPR의 등장배경은 ‘미통일된 기업업무 처리방식의 혼선 때문’이라고 보면 된다. 말은 이렇게 하지만 ‘컴퓨터가 기업의 업무처리에 도입되면서부터’ 누적되기 시작한 ‘업무의 중복 및 혼선’이 BPR의 등장배경이라고 보는 것이 맞다.

더 쉽게 설명을 하자면 불과 2, 30여년 전만 하더라도 우리 나라는 말할 것도 없고 미국의 기업에서 조차 ‘타자기’를 사용하는 구닥다리 업무방식이 전부였다. 종이 서류에 내용을 적어서 상급자에게 결재를 올리고 최종단계에서 사장이 싸인을 하면 다시 아래로 전달이 되어 실제로 일이 진행이 되는 그런 ‘단계’를 거쳐야 했다는 말이다. 하지만 컴퓨터가 회사의 업무에 도입되면서 회사원들의 일이 매우 간편해지기 시작했다.

그래서 기업들은 앞을 다투어 ‘업무 전산화’에 나서게 되었다. 불행히도 거기에서부터 BPR의 필요성이 싹을 트게 된다. 기업 내부에서도 부서별로 사용하는 컴퓨터 체제가 다른 경우들이 나타나게 된 것입니다. 예를 들면 전산실에서는 유닉스, 비서실에서는 도스, 영업부에서는 매킨토쉬 등을 사용하는 그런 경우가 된다. 문제는 이들 각각의 컴퓨터 시스템은 매우 훌륭하지만 ‘호환성이 떨어진다’는 결정적인 약점이 드러나기 시작했던 것이다.

이를테면 2003년 10월 전산실과 영업부의 보고서를 취합해서 갖고 오라는 사장의 지시가 떨어졌을 때, 문제가 복잡해 진다는 얘기가 된다. 유닉스 문서와 매킨토쉬 문서를 도스 환경에서 재작업을 해야하는 문제점이 나타나게된 것이다. 편리하자고 들여놓은 컴퓨터가 오히려 업무를 더디게 만들어 버린 역설에 빠진 것이다. 그래서 ‘이래서는 안되겠다. 업무효과를 향상시키자고 들여온 컴퓨터 때문에 문제가 생겼으니 기업 전산 시스템을 통일시켜 이 참에 아예 업무 처리 과정 자체를 뜯어고치자’는 움직이 나왔고 그것을 ‘BPR’이라고 부르게 된 것이다.

개념

"할 수 있는 것"에서 "해야하는 것"으로의 혁신적인 사고 전환을 통해 회사 업무 처리 프로세서를 목적추구형, 병렬처리형 등으로 혁신시킴은 물론 이와 관련된 Infrastructure 및 Technology, Organization을 동시 에 혁신 시켜 기업의 경쟁력을 세계 초일류 수준으로 끌어올리는 기법이다.

BPR의 목표

BPR은 기업활동을 부가가치의 창조를 위한 프로세스로 파악하는 것이며 이 프로세스란 고객의 주문부터 제품의 인도까지 이익을 실현하는데 핵심이 되는 활동들의 연결고리를 말한다. 기업은 모든 조직 및 활동을 이 프로세스에 집중시키기 위해 불필 요한 부분을 모두 제거, 기업의 효율을 극대화시킨다는 것이 BPR의 목표가 되고 있다.

BPR에서 말하는 프로세서란 개인이나 특정부서의 업무가 아니고 여러 부서간에 수행되고 있는 프로세스(Process)이다. 여기 에서 말하는 프로세스란 “내부 또는 외부의 고객을 위하여 유용한 제품이나 서비스를 전달하기 위하여 반복적이며 측정가능한 과업(Task)의 연 결”을 의미한다. 즉, 조직 내의 연계된 프로세스를 고객입장에서 서서 경쟁자보다 월등한 성과를 내야 한다는 관점의 변화를 요구한다. 고객들은 자신이 원하는 가격의 제품이 원하는 시간에 원하는 품질로 원하는 서비스에 의해 제공되는가에 관심이 있지, 어떤 부서들이 어떤 과정을 거쳐 일을 하는가에는 전혀 관심이 없다.

따라서 비지니스 리엔지니어링은 내부 또는 외부의 고객요구사항을 접수하여 최종적으로 전달되는 일련의 과정을 하나의 프로세스로 설정하여, 경쟁사보다 월등한 성과를 내기 위해 시도하는 프로세스 혁신운동이라고 할 수 있다.

BPR의 향후 전망

BPR의 향후 전망은 크게 ‘독자 개발 적용 방식’과 ASP 서비스와 같은 ‘위탁 처리방식’으로의 세분화가 정착될 것으로 예상해 볼 수 있다.

그리고 ‘물리적 적용범위’에서 본다면 기존의 BPR이 ‘같은 건물내’에 국한되기도 했던 것에 비해 인터넷과 같은 통신망의 발달에 의해서 ‘공간 개념을 넘어선 BPR’을 예상할 수 있다. 이를테면 삼성그룹에서 사용한다는 전용 전산망 ‘싱글’은 전 세계 어느 곳에 있는 삼성 그룹내 회사에서도 동시에 이용이 가능하다고 한다. 또한 이러한 BPR의 공간 개념 탈피는 대기업에만 적용되는 것은 아니다.

자료출처 : http://blog.naver.com/kohseiuk?Redirect=Log&logNo=130017052489

건설교통기술평가원 - 내부인건비 지급 사유

JaeSoo — Tue, 06 May 2008 16:46:12 +0000

- 질문

현재 정부출연연구기관, 특정연구기관, 비영리법인(전자부품연구원, 자동차부품연구원, 포항산업과학연구원, 고등기술연구원 등)은 내부인건비를 지급 받고 있는 것으로 알고 있습니다.

건설교통기술연구개발사업운영규정상 별표 2의 내부인건비관련 내용이

※당해 연구개발과제에 직접 참여하는 연구인력에 대한 비용으로 다음에 해당하는 소속기관으로부터 인건비를 지급받지 않는 것이 명백한 경우 참여율에 따라 내부인건비 현금지급이 가능

▪제4조1항제2호에 의한 정부출연연구기관

▪제4조1항제3호에 의한 특정연구기관

▪ 국가과학기술경쟁력강화를위한이공계지원특별법 제18조 및 동법 시행령 제17조제1항제2로의 규정에 따라 연구와 개발을 지원하는 연구개발서비스업자(기술개발촉진법 시행령 제15조제7항에 해？老求？ 법인에 한함)

이므로 정부출연연구기관과 특정연구기관은 내부인건비를 지급받는 것은 이해가 되나 비영리법인(전자부품연구원, 자동차부품연구원, 포항산업과학연구원 고등기술연구원 등)은 어떠한 절차나 증빙을 하면 내부인건비를 지급받을수 있는지가 궁금합니다.

저희도 비영리기관이므로 절차, 승인, 증빙등의 방법을 통하여 비영리법인이 내부인건비를 받을수 있다면 적용을 하고싶어 문의드립니다.

참고자료로 산업기술평가원에서 공고하는 과제의 경우 내부인건비에 대한 기준은

1. 정부출연연구기관

2. 특정연구기관

3. 비영리연구기관에 지급이가능토록 되어 있어,

비영리법인이며, 사업자등록증의 업종이 연구로 되어있는 경우에는 내부인건비를 지급 받을수 있다는 의견을 받았습니다. 부처별로 틀린 기준이 있는 것 같아 더욱 궁금합니다.

질문에 대한 답변이 다른 질문목록은 보면 빠르지 못한것 같습니다. 빠른 답변 부탁드립니다.

-답변

먼저 저희 기관에 관심을 가져주셔서 감사드립니다.

질의하신 내용에 대하여 간단하게 답변을 드리겠습니다.

현행 건설교통기술연구개발사업운영규정은 내부인건비와 관련하여 [정부출연연구기관, 특정연구기관, 연구개발서비스업자에 대하여 소속기관에서 인건비를 지급받지 않는 것이 명백한 경우에 내부인건비를 지급할 수 있다]는 취지로 규정하고 있습니다.

위 규정의 내용 중 [원소속기관으로부터 인건비를 지급받지 않는 것이 명백한 경우]라 함은 원 소속기관이 인건비를 기 확보하여 지급하지 않는 기관으로서 PBS(Project Base System) 방식에 의하여 운영되는 기관을 의미합니다.

즉, 비영리기관이라고 하여 모두 내부인건비를 지급받을 수 있다는 의미는 아닙니다.

또한, 위 규정에 열거된 정부출연연구기관, 특정연구기관 등은 예시적인 규정으로서 위 기관들에 해당하지 않더라도 PBS방식에 의하여 운영되는 기관인 경우에는 내부인건비를 지급받을 수 있습니다.

질의하신 내용 중 포항산업과학연구원 등의 기관은 PBS방식에 의하여 운영되는 기관이고, 그에 따라 내부인건비가 지급되고 있습니다.

따라서 귀 기관이 PBS방식에 의하여 운영되는 기관이라는 점을 증명한다면 내부인건비를 지급받을 수 있을 것입니다.

참고로, 내부인건비 지급기준에 관하여 현재 가장 상위규정으로 「국가연구개발사업의 관리 등에 관한 규정」(이하 [공동관리규정]) 별표 2가 있는데, 공동관리규정에서 정하고 있는 인건비 지급기준은 앞서 설명드린 바와 같이 PBS 방식에 의한 기관에 대하여 인건비를 지급한다는 의미로 해석하고 있습니다.

다만, 위 규정을 적용하는 과정에서 각 중앙부처마다, 사업의 특성을 고려하여 일부 다르게 적용을 하는 경우가 있습니다.

따라서, 산업기술평가원에서 공고하는 과제에서 비영리법인에 대하여 내부인건비를 지급한다고 하더라도, 그러한 기준을 건설교통기술 연구개발사업에 그대로 적용할 수는 없는 것입니다.

답변을 보시고, 의문사항이 있을 때에는 아래의 번호로 전화를 주십시오. 성실하게 답변하여 드리겠습니다.

담당자 : 오영탁

전 화 : 031 - 389 - 6488

출처 : http://www.kictep.re.kr/app/qna/view.jsp?_idx=298&_sno=1&_pid=qna1&_div=1&_mid=M030200&skey=&stype=1&es=&um=&st=&pnum=4

2008년 건설교통기술연구개발사업 2차 시행 공고(U-Eco City사업단 핵심과제 및 제안공모과제)

JaeSoo — Fri, 11 Apr 2008 21:43:52 +0000

U-Eco City사업단 핵심과제 및 제안공모과제 공고

U-Eco City사업단 핵심과제 및 제안공모과제 공고를 아래와 같이 실시하오니 적극적으로 참여하여 주시기 바랍니다.

                                             - 아 래 –

1. 대상과제 : U-Eco City사업단 핵심과제 2건 및 제안공모과제 6건
2. 사업설명회 : ’08. 4. 18(금), 14:00(장소 : 한국건설교통기술평가원)
3. 접수일정
   - 연구인력사전등록기간 : ’08. 4. 11(금) ~ ’08. 4. 29(화)
   - 인터넷 입력기간         : ’08. 4. 14(월) ~ ’08. 5. 13(화)
      ※ 연구인력사전등록 및 인터넷 입력은 핵심주관기관 응모에 한함
   - 신청서 접수               : ’08. 5. 14(수) 16:00시까지
      ※ 단, ‘U-City 법제도 및 지원정책’과제는 ’08. 4. 25(금) 16:00시까지 접수 마감
3. 접수장소 : 한국건설교통기술평가원

                                                                           자세히 보기 ->클릭

2008년 건설교통기술연구개발사업 2차 시행 공고

건설교통기술의 연구개발을 통하여 건설교통분야 미래신성장동력 창출 및 국민의 삶의 질을 향상시키기 위해 수립된「2008년 건설교통기술연구개발사업 시행계획」에 따라 첨단도시개발사업의 U-Eco City사업단내 핵심주관기관 및 제안공모과제 공모를 아래와 같이 공고하오니 적극적으로 참여하여 주시기 바랍니다.

1. 사업추진 근거

￭ 건설기술관리법

￭ 국가연구개발사업의관리등에관한규정 및 국가연구개발사업의관리등에관한규정시행규칙

￭ 건설교통기술연구개발사업운영규정

2. 지원내용

￭ 첨단도시개발사업

- U-Eco City사업단」핵심주관기관 공모

구분	핵심과제명	세부과제명	개발기술	1차년도 정부출연금 (백만원)
1핵심과제	U-City 인프라 구현기술	인프라 핵심기술 개발	U-Eco City를 위한 차세대 인프라 기술 개발	512
			인프라 표준체계 연구개발
4핵심과제	U-Eco City Test Bed 구축	테스트베드 구축방안 수립	테스트베드 대상지 및 적용기술 선정	50
			테스트베드 구축계획 수립
		테스트베드 구축 평가 및 유지관리	테스트베드 구축
			테스트베드 모니터링 및 평가
			테스트베드 시설물 유지관리
소 계				512

- U-Eco City사업단」제안공모과제 수행기관 공모

구분	과제명	개발기술	1차년도 정부출연금 (백만원)
총괄 과제	미래도시 전략/지원정책 개발 및 총괄지원	U-City 미래비전과 중장기 전략	700
		U-City 법제도 및 지원정책	1,350
		U-Eco City 도시마케팅전략	700
소 계			2,750

구분	핵심과제명	세부과제명	제안공모과제명	1차년도 정부출연금 (백만원)
1핵심과제	U-City 인프라 구현기술	U-City 통합운영센터 관련 기술개발	U-City 통합운영센터 관련 기술개발	330
		인프라 핵심기술 개발	U-Eco City 서비스 비즈니스모델 플랫폼	322
		인프라 핵심기술 개발	U-Eco City 인프라 통합보안기술 개발	194
소계				846

￭ 핵심과제 및 제안공모과제 연구내용, 기간 및 연구비 등 상세내용은 금번 2차 공고 안내서의 과제제안요구서(RFP)를 참조

※ 핵심과제 및 제안공모과제의 연구내용, 연구비 등 세부내역은 별첨2 과제제안요구서 및 첨부된 상세기획연구보고서 참조

3. 선정평가 절차 및 방법

￭건설교통기술연구개발사업운영규정, 건설교통기술연구개발사업사업단운영관리지침, 건설교통기술연구개발사업관리지침 및 2008년 건설교통기술연구개발사업 2차 공고 안내서에 수록된 선정평가 절차 및 방법에 따라 평가

￭ 가점 및 감점 사항

- 연구수행 형태에 따른 가점 : 1점 ~ 2점

- 총연구비에 대한 연구신청기관의 연구비 부담비율에 따른 가점 : 1점 이내

- 연구개발과제의 최종평가결과 등에 따른 가․감점 : 2점 ~ -3점

※ 총괄과제내 제안공모과제는 연구수행 형태 및 연구비 부담비율에 따른 가점 기준 미적용(기타 자세한 사항은 금번 2차 공고안내서 참조)

4. 연구개발비 지원기준

￭ 기업이 참여하는 경우 정부출연금 출연기준

- 대기업 : 총 연구개발비의 50퍼센트 이내

-중소기업 : 총 연구개발비의 75퍼센트 이내

-참여기업이 2개 이상이고 이중 중소기업의 비율이 3분의 2 이상인 경우

: 총 연구개발비의 75퍼센트 이내

-그 밖의 경우 : 총 연구개발비의 50퍼센트 이내

￭ 기업이 부담하는 연구개발비 중 현금부담 기준

-대기업 : 부담금액의 15퍼센트 이상

-중소기업 : 부담금액의 10퍼센트 이상

※ 총괄과제는 정부의 연구개발비 출연기준 및 R&D사업 참여실적에 따른 PQ가점제도 미적용

5. 신청자격 및 참여제한

￭ 신청자격 : 건설교통기술연구개발사업운영규정 제4조에 의한 기관

- 단, 연구인력사전등록 기한내에 등록한 자에 한하여 연구책임자(주관, 협동, 위탁)로 신청가능

※ 신청자격 및 연구인력사전등록에 대한 상세내용은 금번 2차 공고안내서 참조

￭ 연구책임자 및 기관의 참여 제한

- 건설교통기술연구개발사업의 사업단장, 연구단장 및 핵심연구책임자 또는 2개 이상의 과제를 수행하는 연구책임자. 다만, 수행중인 과제가 접수 마감일을 기준으로 3개월 이내에 종료될 경우는 과제 수에서 제외

- 연구개발계획서 신청 마감 전일까지 건설교통기술연구개발사업 참여제한 기간이 만료되지 않은 자 또는 기관

- U-Eco City사업단과제 상세기획시 전문가 그룹의 위원장은 핵심과제 및 제안공모과제의 연구책임자(주관, 협동, 위탁)로 참여할 수 없음

※ 기타 자세한 사항은 금번 2차 공고안내서 참조

6. 신청서 교부 및 접수

￭ 신청서 제공 : 한국건설교통기술평가원 홈페이지(http://www.kictep.re.kr)에 게재

￭ 연구인력사전등록 : 한국건설교통기술평가원 연구관리시스템(http://rnd.kictep.re.kr)

￭ 접수방법 : 신청서 마감일 16:00시까지 평가원에 방문하여 신청서류 접수

※ 인터넷 입력기간 내에 인터넷(http://rnd.kictep.re.kr)을 통해 연구개발계획서를 입력(Upload)한 후 입력로그 상세내역을 방문시 제출해야 함(최초 입력로그는 인터넷 입력기간 마감일 18:00까지만 유효). 단, 연구인력사전등록 및 인터넷 입력은 핵심주관기관 응모에 한함

￭ 공고기간 : ’08. 4. 11(금) ~ ’08. 5. 14(수)

※ 단, ‘U-City 법제도 및 지원정책’과제의 공고기간은 ’08. 4. 11(금) ~ ’08. 4. 25(금)까지임

￭ 사업설명회

- 일시 : ’08. 4. 18(금),14:00

- 장소 : 한국건설교통기술평가원 2층 4,5 통합회의실

￭ 신청서 접수일정

- 연구인력사전등록기간 : ’08. 4. 11(금) ~ ’08. 4. 29(화)

- 인터넷 입력기간 : ’08. 4. 14(월) ~ ’08. 5. 13(화)

※ 연구인력사전등록 및 인터넷 입력은 핵심주관기관 응모에 한함

- 신청서 접수 : ’08. 5. 14(수) 16:00시까지

※ 단, ‘U-City 법제도 및 지원정책’과제는 ’08. 4. 25(금) 13:00~16:00시까지 접수함

￭ 접수장소 : 경기도 안양시 동안구 관양동 1600번지 신창빌딩 2층 한국건설교통기술평가원

7. 문의 및 기타

￭ 문의 : 한국건설교통기술평가원 (031-3896-내선번호, Fax : 031-476-8857)

- U-Eco City사업단 관련 : 건설1실 (464, 465)

- 전산 시스템 관련 : 정보관리실 (408, 409)

- 국제협력 관련 : 대외협력팀 (329)

￭ 기타 자세한 사항은 한국건설교통기술평가원 홈페이지(http://www.kictep.re.kr), 2008년 건설교통기술연구개발사업 2차 공고 안내서, 건설교통기술연구개발사업운영규정, 건설교통기술연구개발사업 사업단 운영관리지침 및 건설교통기술연구개발사업관리지침 참조

2008년 4월 11일

국 토 해 양 부

한국건설교통기술평가원

첨부화일			1. 시행공고문.hwp

첨부화일			2. 2008년 건설교통기술연구개발사업 2차 공고안내서.hwp

첨부화일			3. 연구개발계획서 양식(핵심과제용).hwp

첨부화일			4. 연구개발계획서 양식(제안공모과제용).hwp

첨부화일			5. 연구인력_사전등록_방법.hwp

첨부화일			6. 인터넷입력안내서.ppt

첨부화일			7. 중소기업관련서식.zip

첨부화일			8. U-Eco City 사업단과제 관련 유사과제 목록 및 내용정리(1핵심_4핵심).pdf

첨부화일			9. 총괄과제 상세기획보고서.pdf

첨부화일			10. 1핵심과제 상세기획보고서.pdf

첨부화일			11. 2핵심과제 상세기획보고서(안).pdf

첨부화일			12. 3핵심과제 상세기획보고서(안).pdf

첨부화일			13. 4핵심과제 상세기획보고서.pdf

휴.. 겨우겨우 금욜 오후까지 작업해서 공고 띄웠다..
단장님 휘하 U-Eco City 사업단분들 다들 고생 많으셨습니다~

출처 : http://www.kictep.re.kr/app/notice/view.jsp?_pid=techrnd&_idx=1618&_mid=M020101

SOA (Service Oriented Architecture)

JaeSoo — Wed, 26 Mar 2008 19:14:07 +0000

1. SOA의 정의
- 표준 기반의 공동 사용 가능한 서비스들의 관계를 느슨한 결합으로 모델링하여 소프트웨어의 서비스화를 지향하는 아키텍쳐

2. SOA의 필요성
- 분산 컴포넌트 방식이 현재 기업에서 유용하게 활용되지 못하는 단점을 가지고 있고, 기업 구조를 반영하지 못하는 단점이 대두됨
- 네트워크 인프라의 발달로 인하여 통합 문제에 대한 필요성의 대두와 빠르게 변화하는 기업환경에 대한 즉각적인 대응력이 요구됨

3. SOA의 기본 조건

요건	설명
Well-defined 인터페이스	서비스의 기능과 서비스 호출 규칙을 수립하는 계약
개방형 표준지향	합의된 기준
느슨한 결합	서비스를 특정 서비스 소비자와 완전히 분리
서비스 입도	의미있는 비즈니스 로직/프로세스 단위

4. SOA와 각 분야와의 관계

가. SOA & Enterprise Architecture 관계
- SOA는 Business 관점의 BA와 IT 관점의 TA/AA 사이의 격차 해소 또는 Alignment 최대화를 위한 수단이며, EA는 SOA 기반을 전사 확대하기 위한 기준 아키텍쳐임
- SOA는 EA의 IT 기능을 비즈니스 지향 서비스로 적용하는 방법임
- EA는 SOA의 전사 확대 지원 표준 및 비즈니스부터 어플리케이션, 기술 아키텍쳐까지 S/W의 서비스화를 위한 기반 아키텍쳐를 제공함

나. SOA & Web Service 관계
- SOA는 웹 서비스의 소프트웨어 아키텍쳐 개념/관점/접근 방법임
- SOA는 협업적 웹 서비스 및 Shared service를 위한 아키텍쳐임
- 웹 서비스는 SOA의 개념을 구체화 시킨 구현 기술임

다. SOA & BPM 관계
- SOA는 비즈니스 프로세스 구현 로직 단위 및 기준을 제공하며, BPM은 서비스 관점의 관리, 오케스트레이션, 통합 서비스 기능 등을 제공함
- SOA BPM에서 프로세스는 서비스의 인터페이스를 정의할 뿐 서비스의 내부 조직이나 환경에 영향을 받지 않음
- SOA는 표준에 근거한 BPM의 비즈니스 프로세스 구현 로직 단위 및 기준 제공
- BPM은 SOA의 서비스(비즈니스 프로세스) 관리 체계임

라. SOA & ESB 관계
- SOA는 메시징 버스 인프라의 확장성 및 유현성을 기반을 제공하며, ESB는 서비스 처리시 필요한 신뢰성, 비동기성, 내용기반 라우팅 등을 제고함
- ESB는 SOA의 서비스 처리시 필요한 신뢰성(전달보장), 비동기성, 메시지 변화, 내용 기반 라우팅을 제공함

출처 : http://megabrain.tistory.com/entry/SOA

SPC(Special purpose company) : 특수목적회사

JaeSoo — Tue, 26 Feb 2008 17:13:02 +0000

1.1. 개념

1.1.1. SPV(Special Purpose Vehicle) 하나의 유동화 계획만을 위하여 설립하였다가 그 목적이 달성되면 해산하는 명목회사 형태. 회사의 형태를 띄면 SPC

1.1.2. 특수목적회사는 자산보유자의 파산으로 부터 영향을 받지 않아야 하며, 그 자신도 파산할 위험이 없어야 함

1.2. 주요내용

1.2.1. 자산유동화법상 유동화전문회사는 유한회사로 설립. 회사의 정관 또는 자산유동화계획에서 정한 사유가 발생한 때나 유동화 증권의 상환이 전부 완료된 때에는 해산

1.2.2. 업무

1.2.2.1. 유동화 자산의 양수, 양도 또는 다른 신탁회사에의 위탁

1.2.2.2. 유동화 자산의 관리, 운용 및 처분

1.2.2.3. 유동화 증권의 발행 및 상환

1.2.2.4. 자산유동화계획의 수행에 필요한 자금의 일시적인 차입

1.2.2.5. 여유자금의 투자

1.2.2.6. 기타 위의 업무에 부수하는 업무

1.2.3. 통산 자산보유자가 제3의 투자자에게 직접 자산을 담보로 한 증권을 구조화하고 이를 매각하는 것은 아님

1.2.4. 우선 해당 금융자산을 유동화하기 위하여 그 매개체로서 특수목적기구가 매각하고 이 기구 혹은 회사가 발행기관이 되는 형태

1.2.5. 특수목적회사는 증권발행구조를 조성하는데 필수 불가결한 존재로서 법률, 회계, 세무 등 모든 면에서 발행구조가 부합되도록 신용보전기관, 신용평가기관, 수탁기관과도 면밀히 협력

출처 1. SPC(Special purpose company) : 특수목적회사|작성자 쭌

유동화전문회사(SPC: Special Purpose Company)

SPC는 금융기관에서 발생한 부실채권을 매각하기 위해 일시적으로 설립되는 특수목적회사이다. 채권매각과 원리금상환이 끝나면 자동으로 없어지는 일종의 Paper Company 이며, 자산을 유동화하기 위한 매개체 또는 수단으로 이용되는 회사 또는 법인을 말한다. SPC 는 자산보유자의 파산위험으로부터 완전히 분리된 유동화자산만을 소유하도록 함으로써 자산보유자 또는 국가의 신용등급보다 높은 신용등급을 얻도록 하기 위해 설립된다. 또한 자산보유자로부터 자산을 매입하여 이를 토대로 자산담보부증권 (ABS)을 발행하는 당사자이며, 자산유동화법에서는 유동화전문회사, 신탁업법에 의한 신탁회사(신탁업무를 겸영하는 은행 포함) 및 자산유동화업무를 전업으로 하는 외국인법에 대하여 유동화전문회사 등이라고 규정하고 이들을 통한 자산의 유동화만을 자산유동화로 인정하고 있다. SPC는 자산관리의 자산매각 등을 통해 투자원리금을 상환하기 위한 자금을 마련하는 작업이 끝나면 자동해산 된다.

출처 유동화전문회사(SPC: Special Purpose Company)|작성자 양군

특수목적법인(SPC)

Ｓpecial Ｐurpose Ｃompany의 약자. 특수한 목적을 수행하기 위해 일시적으로 만들어지는 일종의 유한회사. 민간투자사업의 경우 사업기간(건설기간 및 운영기간) 동안 존속하며 별도법인을 설립하는 이유는 대주단 입장에서는 별도의 자금계정을 통해 자금흐름의 투명성을 확보하고, 출자자의 입장에서는 부외금융의 효과를 통해 모기업의 재무건전성을 확보할 수 있다는 장점이 있음

SPC(특수 목적 법인)

Special Ｐurpose Ｃompany
특수한 목적을 수행하기 위해 일시적으로 만들어지는 일종의 유한회사
민간투자사업의 경우 사업기간(건설기간 및 운영기간) 동안 존속하며 별도법인을 설립하는 이유는 대주단 입장에서는 별도의 자금계정을 통해 자금흐름의 투명성을 확보하고, 출자자의 입장에서는 부 외 금융의 효과를 통해 모 기업의 재무건전성을 확보할 수 있다는 장점이 있음

~A와 B사이의 회사는 공동의 목적을 위하여 하나의 프로젝트를 진행할 경우가 있고,

이런 경우에 제 3자인 C라고 하는 SPC 법인을 설립하여,

C 법인의 경영, 특히 모든 자금을 투자 회사에 위탁을 통한 공정 운영으로,

A와 B사이에 분쟁이 생길 소지를 전부 제거하고 C를 통하여 깨끗이 시작할 수 있다는 것

출처 특수목적법인(SPC)|작성자 수노기

특수목적회사(SPC)

특수목적회사 SPC(Special Purpose Company)는 금융기관에서 발생한 부실 채권을 매각하기 위해 일시적으로 설립하는 일종의 페이퍼컴퍼니를 말한 다. 채권 매각과 원리금 상환이 주요 업무이며 부실채권 처리 업무가 끝 나면 자동으로 사라지게 된다.

SPC는 금융기관의 거래 기업이 부실하게 돼 대출금 등 여신을 회수할 수 없게 될 경우 이 부실채권을 인수해 국내외의 적당한 투자자들을 물 색해 팔아넘기는 중개기관 역할을 담당하게 된다. 이를 위해 외부 평가 기관을 활용, 부실채권을 현재가치로 환산하고 이에 해당하는 자산담보 부채권(ABS)을 발행하는 등 다양한 방법을 동원한다.

SPC가 발행한 ABS는 주간사와 인수사를 거쳐 기관과 일반 투자자들에게 판매된다. 투자자들은 만기 때까지 채권에 표시된 금리만큼의 이자를 받 고 만기에 원금을 돌려받는다. 자산 관리와 매각 등을 통해 투자원리금 을 상환하기 위한 자금을 마련하는 일련의 작업이 끝나면 SPC는 자동 해 산된다.

최근 다중채무자를 비롯한 신용불량자가 크게 늘어나면서 산업은행 LG 증권 등 국내 금융기관들은 개인들의 부실채권을 전문적으로 처리하는 회사(SPC)를 설립하는 방안을 논의 중이다. 금융기관이 SPC를 통해 부실 채권을 헐값에 사들인 뒤 자칫 떼일 수 있는 돈을 받고 신용불량자의 채 무를 일부 탕감하거나 상환기간을 조정해주는 방식이다. 정부도 국내의 신용불량자 중 3분의 2가 다중채무자인 만큼 SPC 설립이 불가피하다는 입장이다. SPC는 8월 말께부터 가시화될 전망이다.

출처 : [기타] http://free.taegu.ac.kr

건설교통부 지식정보사이트

JaeSoo — Thu, 10 Jan 2008 14:36:47 +0000

건설산업지식정보
http://www.kiscon.net/
주관부서-건설경제팀
운영기관-국토연구원
건교부가 건설산업에 관련된 종합정보를 DB화하여 구축된 사이트

토석정보공유시스템
http://www.tocycle.com/
주관부서-투자심사팀
운영기관-국토연구원
토석자원의 활용과 거래

해외건설종합정보서비스
http://www.icak.or.kr/
주관부서-해외건설팀
운영기관-해외건설협회
해외건설 수주현황, 금융, 건설통계, 자재 등 해외 건설에 관련된 종합자료

건설인허가민원전자처리시스템
http://www.cpermit.go.kr/
주관부서-기술정책팀
운영기관-건설기술연구원
건설인허가 민원업무 전자처리체계의 신청, 작성, 처리현황등 업무처리지원

건설교통전자정보관
http://www.codil.or.kr/
주관부서-건설환경팀
운영기관-건설기술연구원
건설교통 정보(논문, 웹진, 학ㆍ협회지, 연구개발정보 등)

건설공사기준정보시스템
http://www.codil.or.kr:8080/newcodil/kti_search/ConStdCatLib.jsp
주관부서-건설환경팀
운영기관-건설기술연구원
정부 또는 공공기관에서 규정한 표준시방서, 전문시방서, 설계기준 자료

건설신기술정보마당
http://ct.kicttep.re.kr/
주관부서-기술정책팀
운영기관-한국건설교통기술평가원
건설에 관련된 신기술 지정 및 보호기간 연장 신청 후 진행사항확인

건설교통감사.기술정보
http://www.kict.re.kr/tech/info/main.asp
주관부서-감사팀
운영기관-건설기술연구원
건설교통분야의 감사 및 건설기술정보

건설V.E시스템
http://www.kict.re.kr/tech/ve/
주관부서-건설환경팀
운영기관-건설기술연구원
건설관리시스템

CM적용사례성과분석시스템
http://www.cmcasestudy.or.kr/
주관부서-건설환경팀
운영기관-한국건설관리학회
건설공사의 전과정(기획, 타당성조사, 설계, 시공, 유지관리)의 방식 소개

새집증후군 종합정보제공마당
http://iaenv.kict.re.kr/
주관부서-주거환경팀
운영기관-건설기술연구원
새집에서 발생하는 환경의 실태, 기준, 측정법 자료

시설물정보통합관리시스템
http://fms.kistec.or.kr/
주관부서-안전기획팀
운영기관-시설안전기술공단시설물정보센터
시설물의 안전 및 효율적인 관리할 수 있는 정보

국토포탈
http://www.land.go.kr/
주관부서-국토정책팀
운영기관-토지공사 토지정보센터
국토정보(현황, 통계, 정책), 여행정보 검색

산업입지정보시스템
http://industryland.or.kr/
주관부서-산업입지팀
운영기관-산업입지정보센터
산업입지에 필요한 시도별 단지, 매물정보 및 법률정보

국가지리정보유통망
http://www.ngic.go.kr/
주관부서-국토정보기획팀
운영기관-건설교통부
전자지도 서비스 및 유통

토지종합정보망
http://lmis.moct.go.kr/
주관부서-국토정보기획팀
운영기관-한국토지공사
토지종합정보시스템 소개

출처 : http://www.gunnet.co.kr

[2005.08.23~2007.12.20] 토지공사 U-City 관련 입찰공고 자료 모음

JaeSoo — Thu, 03 Jan 2008 15:11:22 +0000

[2005-08-23] 국토이용정보체계(UPIS)구축사업 감리용역
[2005-09-12] 국토이용정보체계(UPIS)의 활용도 제고방안 연구용역
[2005-10-24] 국토이용정보체계(UPIS)의 활용도 제고방안 연구용역
[2006-03-27] 용인흥덕 U-City 주변도로(흥덕-구갈간) 개설공사 강교구조물 부분책임 감리용역
[2006-04-27] 화성동탄 U-City 도시통합정보센터 착공식행사 용역
[2006-05-24] 행정중심복합도시 u-City 구축을 위한 실행방안 및 기본설계용역
[2006-06-19] 화성동탄 U-City 구축사업 감리용역[2006-06-19] 화성동탄 U-City 구축사업 감리용역
[2007-02-07] 성남판교 U-City구축사업 실행방안 및 실시설계용역
[2007-05-10] 용인흥덕 U-City 조성공사(1공구) 지구외관로 부분책임감리
[2007-08-24] 화성향남지구 U-City 실시설계용역용역
[2007-08-27] 김포양촌(장기)지구 U-City구축 설계용역
[2007-09-04] 인천청라지구 경제자유구역 U-City구축 설계용역
[2007-11-16] U-Eco City 사업 타당성 조사 및 예산 적정성 검토
[2007-12-18] U-세종 건설을 위한 1단계 실시설계용역
[2007-12-20] 도시 기반시설물 관리를 위한 U-City 서비스 모델 연구용역

그냥 말 그대로 비교하고 찾아보기 편하도록 정리..
추후 주택공사 및 KT등에서 발주한 관련 사업도 정리 해야할듯..

아직 정리중..

자료출처 : http://www.lplus.or.kr

[2003.02] 차세대 유무선 통합망(NGcN) 발전방안에 관한 연구 - 전산원

JaeSoo — Wed, 26 Dec 2007 10:41:27 +0000

연 구 책 임 자 : 신상철 (한국전산원 국가정보화센터 단장, 2003.1.8 - 현재)
윤병남 (한국전산원 지식정보기술단 단장, 2002.11.7 - 2003.1.7 )
공동연구책임자 : 서창진 (개방형컴퓨터통신연구회, 숭실대학교 컴퓨터학부 교수)
참 여 연 구 원 : 허정회 (한국전산원 정보화표준부 수석연구원)
정희창 (한국전산원 국가망기획부 연구위원)
박진석 (한국전산원 국가망기획부 전임연구원)
나영인 (한국전산원 국가망기획부 주임연구원)
최병익 (한국전산원 국가망기획부 주임연구원)
장승원 (한국전산원 국가망기획부 주임연구원)
김종표 (한국전산원 국가망기획부 연구원)
세부연구책임자 : 김광훈 (경기대학교 정보과학부 교수)
김기천 (건국대학교 컴퓨터공학부 교수)
연 구 조 원 : 장재수 (숭실대학교 컴퓨터학부 석사)
장인수 (숭실대학교 컴퓨터학부 석사)
원재강 (경기대학교 정보과학부 박사)
강현식 (건국대학교 컴퓨터공학부 석사)
김민정 (건국대학교 컴퓨터공학부 석사)

제 1 장 서 론
제1절 NGcN의 개요
1. NGcN의 정의
2. NGcN의 범위
제2절 연구 개발의 필요성
제3절 연구 개발의 목표 및 내용
1. 연구 개발의 목표
2. 연구 개발의 내용 및 범위

제 2 장 NGcN 네트워크 인프라 고도화
제1절 all-IP 관련 기술
1. 이동성 관리 기술
2. 네트워크 관리 기술
3. 네트워크 통합 기술
제2절 NGcN 네트워크 구조
1. NGcN 네트워크 특징
2. 유무선 통합망 계층 구조
3. 세션 및 미디어 관리 네트워크 계층 구조
4. 통합 서비스 관리 계층 구조
제3절 NGcN에서의 QoS
1. 유무선망에서의 QoS적용
2. QoS 적용 문제점 및 치유방안

제 3 장 NGcN 서비스 고도화
제1절 NGcN 서비스 고도화 요구 분석
1. 유선, 무선, 인터넷 특성
2. Parlay/JAIN 기술
제2절 NGcN 서비스 QoS 조건
1. QoS 필요성
2. QoS 표준화
3. 서비스 특성별 QoS 기술 개발
제3절 NGcN 진화단계별 서비스 지도
1. NGcN 기술 지도
2. NGcN 3 단계 기술 지도

제 4 장 NGcN 발전현황 및 표준화
제1절 NGcN의 발전현황
1. 국외 현황
가. 네트워크 서비스 업체
나. 네트워크 장비 업체
다. 표준화 기구
2. 국내 현황
가. 네트워크 서비스 업체
나. 네트워크 장비 업체
다. 연구소
제2절 최신 표준화 동향
1. ETSI
2. ITU-T
3. IETF
4. 3GPP/3GPP2

제 5 장 연구의 활용방안

제 6 장 결론

참고 문헌
약어표

1. 제 목

차세대 유무선 통합망(NGcN) 발전방안

차세대 유무선 통합망(NGcN)은 유선과 무선, 인터넷, WLAN을 대상으로 IP를 기반으로 통합되어야 한다. 차세대 유무선 통합망(NGcN)
은 제 3 네트워크 서비스의 공급이 활성화 될 수 있도록 모듈화된 구조를 갖추어야 하며, 차세대 유무선 통합망(NGcN)의 QoS는 서비스 특성
별로 차별화하여 제공되어야 한다. 본 연구에서는 국내외 NGcN의 서비스 업체와 장비업체의 개발현황과 개발방안 및 표준화를 조사하고 이들의 안
을 종합하여 개발된 NGcN 기술 지도에 따라서 NGcN을 3 단계로 구분하여 개발한다.

2. 연구개발의 목적 및 중요성

이 보고서는 유선과 무선망이 통합되어 회선 및 패킷 교환기능을 갖춘 차세대 유무선 통합망을 성공적으로 발전시키기 위하여 NGcN의 서비스 측면
을 고려하고 유무선 통합방안과 업체 및 표준단체의 현황 및 발전추세를 연구한다.

첫째, 서비스에 대해서는 유무선 통합망에서 서비스 인프라 구축에 필요한 요소기술을 소개하고, 사용자가 만족하는 NGcN 서비스를 제공하기 위한
QoS를 정립하며, 정립된 QoS를 실현하기 위하여 10년 간에 걸친 3단계 서비스 기술 지도를 완성하는 방법으로 NGcN을 망 이용자측면에서
조명하여 NGcN의 전개시기를 조절한다.

둘째, 유무선 통합방안은 유무선을 통합하는 핵심방안인 all-IP를 연구하여 향후 전개될 무선통신서비스가 어떠한 접근방법으로 유선망과 통합하는지
를 알아보며 이 과정에서 관련되는 네트워크 장치들이 어떠한 구조를 가지며 어떠한 신호체계로 동작하는지 조사한다.

셋째, 업체와 표준단체의 현황을 조사하여 NGcN에 필요한 장비를 모델링 하는데 참고하며 NGcN의 진화방안을 수립하고 국내표준안을 만들기 위
한 기초자료로 사용한다. 이러한 노력은 NGcN의 관련 시장을 선점하는 효과를 나타낼 것이다.

3. 연구개발의 내용 및 범위

연구 개발 내용 및 범위는 다음과 같이 세 부분으로 나뉘어 진행된다.

NGcN 서비스 고도화
- 제 3 서비스 제공자 인터페이스 분석
- NGcN QoS(Quality of Service)를 위한 표준 기술 분석
- 2003년부터 2012년까지의 NGcN 서비스 기술 지도 개발

NGcN 인프라 고도화
- NGcN 인프라 구조에 대해서 알아보기 위해서 NGcN의 하부 인프라를 이루는 서로 다른 망들의 특징 및 요소 프로토콜의 기술을 조사한다.
- 이러한 하부 인프라를 통합하는 핵심 개념인 all-IP를 연구한다.
- 통합 시그널 처리와 미디어 통합에 관여하는 기술요소 및 상위 계층의 서비스 제공 기술 요소를 알아본다. 특히 이러한 NGcN서비스에서의 전
송 QoS는 NGcN의 성공을 좌우하는 중요한 사안이므로 QoS을 지원하기 위한 고려사항을 알아보고 이에 따른 QoS지원 시나리오를 제시한다.

NGcN 발전현황 및 표준화
- NGcN을 선도하고 있는 국외의 네트워크 서비스 업체 및 장비 업체, 표준화 기구에서 제시하고 있는 NGcN 모델 및 발전단계를 조사한다.
- 국내의 네트워크 서비스 업체와 장비 업체 및 학교, 연구소에서 진행중인 NGcN의 구조와 진화방향을 알아본다.
- NGN과 관련하여 가장 구체적인 내용들을 다루고 있는 유럽연합의 ETSI에서 추진중인 최신 표준화 동향을 살펴보고 국제 표준화 기구인
ITU-T 및 IETF에서 진행중인 NGN 관련 표준화를 파악한다.

4. 연 구 결 과

NGcN 서비스 고도화
NGcN 서비스 고도화를 위한 제 3 서비스 제공자 인터페이스 분석에 대한 연구 결과는 PARLAY와 JAIN(Java APIs for
Integrated Network)에 대한 표준 기술의 분석에 대한 내용이며, 수직적 구조에서 수평적 구조로 네트워크를 형성할 수 있도록
PARLAY와 JAIN에 의한 서비스 제공 방안을 제시하였다.

NGcN QoS(Quality of Service)를 위한 표준 분석에 대한 연구 결과는 ITU-T, ETSI 표준화 기구에 대한 표준 기술을
분석하였으며, 분석한 결과를 토대로 서비스 응용 분야에 따른 QoS 요구사항을 정립하였다.

향후 10년 간 펼쳐질 NGcN 서비스 개발 지도에 대한 연구는 2003년부터 2012년까지 3단계로 구분하여 기술 지도를 제시하였다. 특히,
각 단계에서는 서비스 계층, 제어 계층, 전송 계층, 단말 계층으로 구분하여 기술 지도를 완성시켰다.

차세대 통합 망 서비스 고도화 분야는 다음과 같이 구분하여 연구되었다.

- NGcN 개방형 서비스
NGcN에서는 제 3 서비스 제공자가 Parlay/JAIN 등의 API를 이용하여 사용하는 네트워크의 세세한 구현 기술과 독립적으로 사업을 추진
할 수 있도록 환경이 변화되어 자유로운 경쟁이 이루어질 수 있고 이로 인하여 서비스가 다양해진다. Parlay/JAIN API에 의해 제 3 서
비스 제공자 환경 인프라가 구축되어 유선과 무선, 인터넷, WLAN을 망라하여 서비스가 가능한 고도화된 서비스가 등장할 것이다.

- NGcN QoS
본 연구에서는 Signalling(CCS No.7, eSCM Workflow Transaction), Conversational(음성정보),
Streaming(영상정보), Interactive(웹브라우징), Background(이메일) 등으로 구분하여 QoS 요구사항을 정의하였다.
NGcN 서비스가 고도화됨에 따라 워크플로우 트랜잭션(Workflow Transaction)에 대한 QoS는 매우 중요한 응용 요소로 등장할 것
이다. 또한, QoS는 네트워크 전송속도와 패킷 손실에 대한 QoS 위주에서 네트워크 생존성을 위한 QoS로 변화가 요구되고 있다.

- NGcN 서비스 지도
NGcN 서비스 기술 지도를 3 단계로 구분하여 정의하였다. 단순 음성이나 텍스트 브라우져(Browser)에서 데이터의 가치가 한층 높아진 전자
상거래 워크플로우 트랜잭션을 제공하는 NGcN 기술이 최종 목표로 개발될 것이다. 네트워크 기반아래 누구든지, 언제나, 어디서든지 원하는 모
든 것을 할 수 있다는 개념을 실현한 유비퀴터스((Ubiquitous) 환경을 구축하는 핵심 원천 기술은 NGcN 요소 기술 개발에 의해 실현
될 것이다.

NGcN 인프라 고도화
NGcN 네트워크 구조와 관련해서는 NGcN의 5계층 중에서 유무선 통합 패킷망 계층과 세션 및 미디어 관리 계층에 대하여 연구하였다. 유무선
통합 패킷망 계층은 all-IP기반의 통합망을 기반으로하고 있으므로 all-IP에 관련된 기술 요소들에 대하여 연구하였다. 유무선 통합에 따른
이동성 지원에 관한 기술인 Mobile IP v4/v6, 마이크로 이동성 지원기술에 관한 연구 및 이동통신망을 비롯한 접속망의 특징을 알아보았으
며 이와 같은 환경에서 단일 단말의 원활한 이질망간 로밍(Roaming)을 위한 이질 접속망 통합방안을 제시해 보았다.

세션 및 미디어 관리 계층에서는 대표적인 시그널 프로토콜 및 미디어 통합 기술 요소 인 SIP 및 MEGACO에 대해서 알아보았다. 또한 유무
선 통합 패킷망 계층과 연관지어 통합망에서의 세션 및 이동성 지원방안의 기술적 현황에 대해서 알아보았다. 또한 NGcN의 최상위계층인 서비스 제
공 계층에 대해서도 기술적인 현황을 알아보았다.

특히 NGcN에서는 다양한 서로 다른 망들을 통합하고 그 위에서 이동성을 제공하는 기반망으로 단일한 서비스 품질을 제공하는 것은 매우 힘들다.
이를 이루기 위해서는 하나의 고정망과 같은 형태의 서비스 품질 방안을 적용할 수 없으며 현재 서비스 제공받고 있는 망의 형태에 따라 가변적으로
적용되어야 한다. 이러한 가정 하에 NGcN에서 적용이 가능한 QoS적용 시나리오와 적용 프레임워크(Framework) 기술들에 대해서 연구하였
다.

NGcN 발전현황 및 표준화
단계적으로 도입될 NGcN의 수립계획을 만들기 위한 기초자료로 다음과 같은 조사가 이루어졌다.

첫째, 외국의 서비스 제공업체의 사례를 알아보았다. 미국 유선 네트워크 업체인 AT&T가 제안하는 SoIP(Service over IP) 구조
와 ECLIPSE(Extended Communications Layerd on IP - Synthesis Environment)로 명명된 차세
대 플랫폼(Platform)에 대해서 알아보고 WorldCom의 자체 IP 망을 이용한 NGN 구조를 파악한다. NGN 개발 및 도입이 활발한
유럽 BT와 FT에서의 NGN 도입방안과 NGN 구조를 조사하고 아시아권인 일본 NTT의 히카리 소프트(Hikari-soft) 서비스와 유비퀴터
스 구조 및 소프트스위치(Softswitch) 개념인 ‘Clearinghouse' 서비스에 대해 알아본다. 또한 미국 1위의 무선 네트워크 서비
스 업체인 버라이존 와이어리스(Verizon Wireless)의 무선통신업체의 관점에서 본 NGN 도입방안에 대해 알아보고 영국의 MmO2와 일
본의 NTT 도코모(Docomo)의 NGN 서비스 현황을 알아본다.

둘째, 국외 네트워크 업체 사례에 대해서 알아보았다. NGN 통합 솔루션을 제공하고 있는 알카텔(Alcatel)의 NGN 진화 6단계에 대해서
살펴보고 IP망 위주의 NGN을 제안하고 있는 시스코(Cisco)의 IP 멀티서비스 솔루션과 통합 NGN 솔루션인 ENGINE을 제안하는 에릭
슨(Ericsson)의 경우를 조사하였다.

셋째, 국내 NGN 현황을 소개하였다. 가장 NGcN 분야에서 앞서고 있는 KT의 NGcN 진화단계를 알아보고 무선망 위주의 NGcN 전략을 세
우고 있는 SKT와 LGT의 NGcN 관련 서비스 개발 현황을 파악 및 인터넷 서비스 업체인 하나로 통신의 NGcN 도입에 대해서도 알아보았
다. 또한 정통부가 주관하여 마련한 ‘차세대 정보통신통합망(NGcN) 발전계획(안)’은 현재 세계적으로도 가장 앞선 계획을 수립하고 있으며 국
내 장비 업체는 NGN 통합 솔루션은 아직 제공하지 못하고 있지만 소프트스위치의 개발은 대기업 및 중소기업체들 모두 활발히 진행중이다.

넷째, 표준화 동향은 ETSI에서 2002년 11월 발표된 NGN 보고서의 버전 4를 위주로 표준화 진행 상황을 파악해보고 ITU-T의 하부 작
업그룹인 SG13에서 2002년 6월에 ‘NGN 2004 Project'에 발표한 사항을 조사하였다. NGN과 관련된 프로토콜의 표준화를 진행중
인 IETF의 2002년 7월 미팅을 내용으로 각 하부 WG(Working Group)의 NGN 관련 활동사항을 파악하였다.

5. 활용에 대한 건의

본 NGcN 서비스 고도화 연구에서 도출된 연구 결과는 향후에 전개될 유선, 무선, 인터넷, WLAN에서 매우 중요하게 사용될 것이다.
NGcN은 4개의 네트워크에 대한 구조가 변경되는 사업이기 때문에 외국의 원천 기술을 도입하여 국내에서 조립만 하는 단기적인 연구 개발보다는 장
기간의 연구가 필요한 핵심 원천 기술을 개발하는 방향으로 전개하여야 한다. 본 연구의 결과를 이용하여 NGcN 서비스 고도화를 위한 제 3 네트
워크 서비스 제공자에 대한 개방화 기술 개발에 활용할 수 있다. 또한, NGcN 서비스 별 QoS를 세부 척도를 정의하는 데 기준으로 활용할
수 있다. 마지막으로, NGcN 기술 지도는 NGcN 개발 계획 및 전략 수립에 활용할 수 있다.

NGcN인프라 고도화는 향후 국내 NGcN망 구축지 기초 모델로 활용이 가능하다. 특히 이러한 NGcN의 실 서비스에 있어서 차등화된 서비
스(QoS) 제공에 대한 연구를 병행하였으므로 QoS 지원방안에 있어서 기술적인 기초자료로 활용할 수 있다.

NGcN의 발전현황 및 표준화를 통하여 현재 세계적으로 NGcN이 진화되는 상황을 파악할 수 있었고 이를 바탕으로 합리적인 국내안을 도출할 수
있으며 우리나라가 NGcN을 주도할 수 있는 기초자료로 활용할 수 있다.

6. 기 대 효 과
NGcN 서비스 고도화 연구 결과로 인하여 유선과 무선, 인터넷, WLAN에 대한 통합 서비스의 제공이 가능해지며 PARLAY 및 JAIN에 의
한 제 3 네트워크 서비스 제공은 침체 국면에 있는 네트워크 산업을 활성화할 수 있다. 특히, NGcN QoS는 NGcN 사업 성공을 위한 중요
한 척도를 제시하며 본 연구에서 제안한 NGcN 기술 지도는 2003년부터 2012년까지 구축될 NGcN 3 단계 사업 수립에 기준을 제공할 것
이다.

NGcN인프라 고도화 연구는 NGcN을 구축하는 단계에서 중요한 기술적, 정책적 토대가 될 수 있으며 국내의 all-IP관련 제반 기술을 축적시
켰다. 또한 NGcN에서의 QoS지원 시나리오는 NGcN서비스 활성화에 대한 토대를 마련할 것이다.

한국이 CDMA의 선점을 통해서 현재 세계적인 무선단말기 생산국이 되었고 초고속 인터넷의 급속한 성장으로 세계 최대의 IT 인프라 국가가 된 것
처럼 NGcN 시장에서도 모험적인 연구 및 투자로 큰 선점효과를 얻을 수 있기를 희망한다.

출처 : http://www.ipc.go.kr/ipckor/policy/policy_view.jsp?num=888&gubun=sub0&topic=105&mstcd=&group=105001&fn=&req=&pgno=6&part=&partnm=

ps : 흠 장재수 연구원 참여 -_-; 작성당시에는 고생고생 해서 쓴거 같은데..
지금 보니 미흡한점이 막 보이는.. ㅠㅠ

2007년도 광대역통합망(BcN) 구축 사업계획

JaeSoo — Mon, 24 Dec 2007 17:16:40 +0000

2007년도 광대역통합망(BcN) 구축 사업계획

1. BcN 신규서비스 개발 및 사업자망간 상호연동

□ 2단계 2차년도 BcN 시범사업 추진

o BcN 신규서비스 모델 발굴 및 기 개발 서비스에 대한 상용화 지원
- u-Home(가정) 분야 등을 대상으로 신규 서비스 모델 추가 발굴
- IPTV, 양방향DCATV(HD급) 등 기 개발 서비스의 고도화 및 상용화 지원

o 수도권 및 5대 광역시도의 시범가구를 대상으로 시범서비스 제공 및 이용행태 분석 실시

□ BcN 사업자망간 상호 연동 추진

o BcN 사업자망간 효율적 상호 연동 기술 연구
- 국내·외 사업자망간 트래픽 상호교환 기법 및 기술 연구
- 119 긴급데이터 등에 대한 장애 대응 및 품질보장 기법 연구

o BcN 서비스별 상호호환성 확보 추진
- 사업자간 상호호환성 확보를 위한 핵심 요구사항 도출 및 항목별 기술규격 마련

2. BcN 품질관리기반 구축

□ BcN 서비스(무선 등) 품질관리 기준 및 품질측정기법 마련

o 유선 음성서비스(고품질급 BcN전화) 품질관리 기준 마련

o 무선 서비스(Wibro) 품질관리 기준 설정 및 측정/평가기법 연구
- 국제 표준화(ITU-T, 3GPP 등) 연구를 통한 무선 서비스(Wibro) 품질관리 지표/기준 설정
- BcN 주요 단말기를 활용한 무선 환경 품질측정 시험을 통한 지표/기준 타당성 검증
- 무선 서비스(Wibro) 품질측정/평가 기법 및 기술개발(구조, 기술스펙 등) 방안 연구

□ BcN 서비스 품질측정⋅평가체계 공공망 선도적용 추진

o 전자정부통신망, 공공정보통신망(NIS) 등을 대상으로 품질관리 기능(Agent, Probe) 도입 추진
- 시범 적용 및 평가 결과 분석, 의무화 방안(이용약관 반영 등) 마련

o 상용망 품질관리 의무화를 위한 품질보증제도(SLA) 방안 마련 및 이용제도 개선 연구
- 서비스별 품질지표/개통지연/장애처리 등 항목별 품질기준 설정
- 관련 품질수준 측정 평가관리 및 보상체계 방안 마련 등

o BcN 서비스 품질관리시스템 및 기반시설 운영

□ BcN 서비스 품질측정시스템 고도화

o 이용자참여형 품질측정시스템 구축·운영 및 VoD, 영상전화 서비스 품질측정 기능 확대 적용

o VoIP 장비용(IP-PBX 등) 품질측정 S/W 기능(Agent) 확대 개발

□ 기타 품질관리기반 구축 여건 조성

o BcN 품질측정관리협의회 및 워크샵 개최 등 행사/홍보 활동 추진

o 품질지표/기준 등에 대한 국내외 표준화 지원(ITU-T, TTA) 등

3. BcN 개방형서비스 개발·시험환경 구축·운영

o 통신·방송 융합형 개방형서비스 개발 환경 구축 및 유무선 통합형 개방형서비스 사업화 모델 시범서비스 상용화 개발 지원
- IT 응용개발자, 3rd party 개발 촉진의 통신·방송 환경 구축·운영
- 온라인 개발환경 이용 및 지원 환경 구축 운영
- 총체적 u-인프라 산업간 융합형 개방형서비스 적용 방안 도출

o 개방형서비스센터 중심의 다양한 개방형서비스 모델 발굴·육성지원
- 온라인(지방 육성)/오프라인 교육 프로그램개발 및 양성
- 온라인 가상 실습·체험등 다양한 서비스 개발자 양성
- 개방형 서비스 사업화 커뮤니티 활성화/협회 운영

o 개방형서비스 발굴 경진대회 개최 및 홍보 시행
- 서비스 발굴을 촉진하는 경진대회용 이벤트 및 프로그램 개발
- 사업화에 필요한 기술적ㆍ제도적 지원체계 운영 및 서비스 사업화 검증 DB 체계 개발 및 운영
- 국내외 한국형 BcN/개방형서비스 보급 연동 전략 수립

o 개방형서비스 통신·방송 융합형 서비스 활성화 정책 도출
- 통신·방송 융합형 개방형서비스 신규 자원 표준인증 및 제도 연구
- 3rd Party 서비스 사업자의 보호법 및 법제도(안) 도출

4. BcN 표준모델 개발 및 보급

o BcN 표준모델 보완 개발
- 상용망 구축 방향 및 시범사업 결과, 기술개발 결과 등의 반영을 통한 단계별 망 구조 보완
- 표준모델협의회의 활발한 운영을 통해 상용망 구축의 참조모델로 활용 가능한 표준모델 개발

o BcN 표준모델 활용 추진
- 주요 기술 항목별 활용 체계 도출 및 적용 추진
- 표준화 추진대상 항목을 도출하고 표준모델 결과를 국내·외 표준화에 적극 반영 추진

5. BcN 구축 여건 조성

□ BcN 서비스 활성화를 위한 이용제도 연구

o BcN 서비스(BcN 음성/영상전화 등) 활성화를 위한 이용제도 연구
- 기존 서비스 이용제도 분석 및 신규 BcN서비스 이용환경 연구
- 이용제도, 번호체계, 상호접속, 규제 등을 포함한 제도적 방안 수립 및 관련 효과성 분석

o BcN 인프라, 단말, 서비스 등의 특성/규격 등에 대한 객관적인 정의 마련

□ BcN 기반 인프라 인증제도 운영 및 개선

o 초고속정보통신건물 인증제도 사무국 운영 및 제도 확산 연구
- 인증제도 사무국 운영(인증위원회, 워킹그룹, 홈페이지 등)

o FTTH 구축 관련 경제적⋅산업적 파급효과 분석 및 이용활성화 연구

o BcN 구내망 정보통신설비 관리를 위한 교육프로그램 등 인력육성 방안 연구

□ BcN 시장 전망 및 산업 활성화 연구

o BcN 구축 촉진을 위한 핵심서비스별 국내외 시장 조사

o 기술발전 방향 및 산업계 요구에 기반한 단계별 요구사항 도출을 통한 산업 활성화 연구

o BcN 관련 행사 개최 지원, 홈페이지 개선 및 운영 지원(www.bcn.ne.kr)

□ u-Work 서비스 활성화 지원

o u-Work 응용서비스 발굴 및 u-Work 도입 가이드 개발
- u-Work 아이디어 공모전 개최 등을 통한 응용서비스 발굴
- 공공/민간등 기관특성별 u-Work 이용활성화를 위한 도입 가이드 개발

o 기타, u-Work 이용활성화를 위한 행사개최 및 홍보 등

□ BcN 구내망 정보통신설비 구축⋅관리 방안 마련

o 공동주택(APT단지중심) 정보통신설비 운영 및 유지보수 방안 연구
- 정보통신 서비스/장비/네트워크 구성 현황 조사 및 해외사례 연구
- 초고속인증제도, 주택법, 정보통신공사법 등 제도적 개선 방안 도출
- 공동주택 구내통신망 유지보수 사업자 육성 등 관련 산업 육성 방안 연구 등

o 공동주택(APT단지중심) 기반의 u-Zone/Community 서비스 발굴

o 홈네트워크 기기 동향 조사·분석 및 인증방안 연구, 행사 개최 지원 등

□ 기타 BcN 구축 지원

o BcN 구축관련 각종 협의회 개최 및 행사/홍보 추진
- BcN구축추진협의회, BcN시범사업추진협의회, BcN워크샵 등 개최
- u-인프라통합워크숍, IT인프라엑스포 등에의 행사 참여

o BcN 기반구축 사업관리, 정책 개발 지원 및 통계/지표 관리 등
- u-Work 기본계획 수립 지원, 가입자수 등의 각종 통계지표 관리
- BcN 관련 주요 활동 및 동향 파악을 위한 「BcN 동향 2007」 발간 등

출처 : http://www.ipc.go.kr/index.jsp

U-Eco City 사업단 사전기획연구 보고서

JaeSoo — Tue, 11 Dec 2007 15:05:59 +0000

U-Eco City 사업단 추진에 앞서 수행된 사전기획연구보고서를 업로드하오니 참조하시기 바랍니다.

- 100 페이지의 표 오류를 수정하였습니다. (7.26)

제 1 장 U-Eco City 사전기획 연구의 필요성
1.1 U-Eco City 사업의 추진 필요성
1.2 사전기획 연구 목표 및 내용
1.3 연구 추진전략 및 방법
제 2 장 국내외 U-Eco City 기술 현황 및 여건 전망
2.1 U-City 기술 현황 및 여건 전망
2.1.1 국내 U-City 관련 기술의 현황
2.1.2 국외 U-City 관련 기술의 현황
2.1.3 U-City 관련 정부지원정책 현황
2.1.4 U-City 관련 특허동향 분석
2.1.5 국내외 U-City 관련 여건변화와 시장전망
2.2. Eco-City 기술 현황 및 여건 전망
2.2.1 국내 Eco-City 관련 기술의 현황
2.2.2 국외 Eco-City 관련 기술의 현황
2.2.3 Eco-City 관련 정부 정책 현황
2.2.4 Eco-City 관련 특허동향 분석
2.2.5 국내외 Eco-City 관련 여건변화 및 시장전망
2.3 U-Eco City 기술경쟁력 분석
2.4 핵심과제 도출
2.4.1 U-Eco City 추진현황
2.4.2 핵심과제의 도출
2.4.3 U-Eco City 관련 개선항목 도출 및 기대효과
제 3 장 U-Eco City 사업단의 비전 및 목표
3.1 U-Eco City 사업단의 비전 및 목표
3.2 U-Eco City 기술개발 방향
3.3 U-Eco City 사업단 추진전략
3.4 U-Eco City Test Bed 구축방안
제 4 장 핵심과제별 U-Eco City 기술개발 추진계획
4.1 핵심과제 개요
4.2 핵심과제 추진 로드맵
4.3 핵심과제별 세부계획
제 5 장 핵심과제별 투자계획
5.1 투자계획
5.2 투자재원 조달방안
제 6 장 U-Eco City 사업단 기술개발 추진체계
및 운영방안
6.1 U-Eco City 기술개발 추진체계
6.2 U-Eco City 사업단의 운영방안
6.3 U-Eco City 사업단의 성과관리 방안
제 7 장 U-Eco City 기술개발의 기대효과
7.1 U-Eco City 기술개발의 기대효과
제 8 장 사업단장 공모기준
8.1 사업단장 임무
8.2 사업단장의 임무에 따른 자격 요건
8.3 사업단장 공모 및 평가 기준
8.4 사업단장 공모 양식

출처 : http://www.kicttep.re.kr/web/bod.bod?mode=TF&bNo=36&iNo=6&pNo=0

(정통부) 2007 정보화에 관한 연차 보고서

JaeSoo — Wed, 05 Dec 2007 18:01:35 +0000

목 차
제1편 선진한국을 위한 정보화 추진
제1장 정보화 추진경과 및 성과
제1절 정보화 추진경과 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙3
제2절 분야별 정보화 추진성과 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙6
제3절 우리나라의 정보화 수준 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙10
제2장 정보화 추진 및 평가체계
제1절 정보화 추진체계 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙15
제2절 국가정보화 평가체계 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙25
제3장 정보화 관련 법체계 정비
제1절 정보화촉진기본법 및 관련 법령 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙26
제2절 법제 정비 추진경과 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙28
제3절 주요 법령 정비현황 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙31
제4절 법∙제도 개선을 위한 추진방향 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙36
제2편 정보화 비전과 정책 방향
제1장 IT 기반 미래사회 대응
제1절 미래사회 연구 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙43
제2절 u-KOREA 기본계획∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙46
제3절 ACE IT 전략의 수립∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙50
Ⅰ
목 차
제2장 분야별 정보화 추진방향
제1절 기본방향 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙54
제2절 주요 내용 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙55
제3편 유비쿼터스 IT인프라 고도화
제1장 광대역통합망(BcN) 구축
제1절 목표 및 추진방향 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙63
제2절 광대역통합망 시범사업 추진 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙66
제3절 광대역통합망 구축기반 마련 및 여건 조성 ∙∙∙∙∙∙∙∙∙∙∙∙∙69
제4절 주요 사업자의 BcN 구축 동향 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙73
제2장 RFID/USN 기반 조성
제1절 목표 및 추진방향 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙75
제2절 핵심기술 개발 및 인력 양성 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙77
제3절 u-IT 클러스터 구축 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙79
제3장 차세대인터넷 프로토콜(IPv6) 구축
제1절 목표 및 추진방향 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙82
제2절 유∙무선 통합 상용기술 개발 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙84
제3절 IPv6 시범사업 추진 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙87
제4절 표준화 및 시험∙인증제도 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙90
Ⅱ
목 차
제4편 유비쿼터스서비스 전면화
제1장 u-City 건설
제1절 국내 추진현황 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙97
제2절 u-City 정책 추진방향 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙99
제2장 RFID/USN 활용서비스
제1절 국내∙외 추진현황 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙103
제2절 시범사업 및 확산사업 추진 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙106
제3절 생활 속의 IT 확산 추진 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙109
제3장 텔레매틱스서비스
제1절 국내∙외 추진현황 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙113
제2절 전국 교통정보 통합∙배포시스템 구축 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙115
제3절 텔레매틱스 관련 기술 개발 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙117
제4장 홈네트워크서비스
제1절 국내 홈네트워크 시장 전망 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙120
제2절 홈네트워크 보급 활성화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙122
제5장 유비쿼터스 선도서비스
제1절 u-Defense ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙125
제2절 u-Payment ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙128
제3절 u-Health ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙130
제4절 u-Farm ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙133
Ⅲ
제5편 지식정보사회 기반 확충
제1장 국가 정보자원 관리 혁신
제1절 정부통합전산센터 구축 및 고도화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙139
제2절 전자정부통신망 고도화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙144
제3절 범정부 정보기술아키텍처(ITA) 적용 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙149
제4절 지식정보 활용 제고 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙153
제5절 국가정보화평가 및 성과관리 강화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙158
제2장 인터넷 이용환경 고도화
제1절 신규 온라인 비즈니스 활성화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙159
제2절 인터넷서비스 이용환경 개선 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙161
제3절 인터넷서비스 기반 고도화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙163
제3장 IT 신성장동력 기반 구축
제1절 IT 신성장동력 추진경과 및 성과 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙169
제2절 정보통신인력 양성 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙172
제3절 혁신형 IT중소기업 성장 지원 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙180
제4절 소프트웨어 및 디지털콘텐츠 산업 육성∙∙∙∙∙∙∙∙∙∙∙∙∙∙184
제5절 IT부품∙소재산업 육성∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙188
Ⅳ
목 차
Ⅴ
제6편 따뜻한 디지털세상 구현
제1장 개인정보보호 강화
제1절 개인정보보호 법ㆍ제도 개선 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙193
제2절 사전적 대응 수단 정비 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙196
제3절 개인정보보호 환경조성 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙199
제4절 개인정보 관리실태 점검 및 모니터링 강화 ∙∙∙∙∙∙∙∙∙∙∙∙201
제2장 건전한 인터넷 이용환경 조성
제1절 불법ㆍ유해정보 유통 방지 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙205
제2절 정보통신윤리교육 및 건강한 정보문화운동 ∙∙∙∙∙∙∙∙∙∙∙∙207
제3절 스팸대응 강화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 210
제4절 인터넷중독 현황 및 대책 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙215
제3장 안전한 사이버환경 구축
제1절 해킹 대응시스템 고도화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙219
제2절 정보보호산업 경쟁력 강화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙225
제4장 디지털기회 확대
제1절 취약계층의 정보접근권 보장 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙228
제2절 취약계층 정보활용능력 제고 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙235
제3절 참여와 나눔의 IT문화 확산 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙238
Ⅵ
목 차
제7편 글로벌 IT 리더를 향한 국제협력 강화
제1장 동북아 IT 허브국가로의 도약
제1절 한∙중∙일의 긴밀한 협력관계 구축 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙243
제2절 아세안∙중동 등과의 협력 강화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙248
제2장 글로벌 리더십 구축
제1절 국제기구에서의 주도적 역할 수행 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙250
제2절 지역간∙국가간 유기적 협력체제 구축 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙254
제3절 국제 정보격차해소 지원 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙256
제4절 남북 IT 교류협력 기반 구축 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙261
제5절 국제 IT 인프라 구축 확대 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙269
제3장 IT산업의 글로벌화
제1절 IT산업의 수출경쟁력 강화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙274
제2절 해외진출 활성화를 위한 지원체제 확립∙∙∙∙∙∙∙∙∙∙∙∙∙∙280
제3절 외국인 투자 유치 및 글로벌 연구개발센터 설립 ∙∙∙∙∙∙∙∙∙∙283
제4절 해외진출 기반 강화 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙287
부록
1. 주요 기관 홈페이지∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙293
2. 용어사전 ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙297

출처 : http://mic.go.kr

(정통부) 2006 정보통신 백서

JaeSoo — Wed, 05 Dec 2007 17:49:28 +0000

목 차
제1장 총 론 1
제1절 2005년도 정보통신정책 추진성과
1. 지능기반사회 선도
2. IT 산업 육성
3. 통신․전파방송 서비스 고도화
4. 글로벌 IT 협력 강화
5. 우정서비스 혁신
제2절 2006년도 정보통신정책 추진성과
1. 2006년 추진 정책목표
2. 지능기반사회 선도
3. IT산업 경쟁력 강화
4. 통신․전파방송 서비스 고도화
5. 글로벌 IT협력 강화
6. 국민의 사랑 우정서비스 구현
제2장 정보화 31
제1절 선진한국을 위한 정보화 추진
1. 정보화 추진 경과 및 성과
2. 정보화 추진 및 평가체계
3. 정보화 관련 법체계 정비
제2절 정보화 비전과 정책 방향
1. u-KOREA 기본계획 수립
ⅱ 목 차
2. 분야별 정보화 추진 방향
제3절 유비쿼터스 인프라 고도화
1. 광대역통합망(BcN) 구축
2. RFID/USN 기반 조성
3. 차세대 인터넷 프로토콜(IPv6) 구축
제4절 유비쿼터스 서비스 활성화
1. u-City 건설
2. RFID/USN 활용서비스
3. 텔레매틱스 서비스
4. 홈네트워크 서비스
5. 유비쿼터스 선도서비스
제5절 따뜻한 디지털 세상 구현
1. 안전한 디지털 환경 조성
2. 개인정보보호 강화
3. 정보격차 해소
4. 건강한 디지털문화 확산
5. 정보보호 산업의 전략적 육성
제3장 IT 산업
제1절 국내 IT 산업 동향
1. 정보통신서비스산업
2. 정보통신기기산업
3. 소프트웨어산업
목 차 ⅲ
제2절 9대 신성장동력 육성
1. 차세대 이동통신/텔레매틱스 기기
2. 광대역/홈네트워크 기기
3. 디지털 TV/방송 기기
4. 차세대 컴퓨팅/주변기기
5. 지능형 로봇
6. IT SoC/융합부품
7. RFID/USN 기기
8. 임베디드SW
9. 디지털콘텐츠/SW솔루션
제3절 SW, 디지털콘텐츠산업 경쟁력 제고
1. SW산업 육성 및 경쟁력 강화
2. 디지털콘텐츠산업 활성화
제4절 IT부품․소재 산업의 전략적 육성
1. IT부품․소재 산업의 현황
2. IT부품․소재 산업의 기술개발 성과 및 육성 계획
제5절 IT 역량 및 체질 강화
1. IT 중소․벤처기업의 건전한 생태계 재조성
2. IT R&D 및 표준화 역량 강화
3. 첨단․맞춤형 IT 인력 양성
제4장 통신서비스
제1절 통신서비스 동향
1. 통신서비스 현황과 전망
2. 통신서비스 추진성과 및 정책방향
ⅳ 목 차
제2절 신규 통신서비스 활성화
1. 와이브로(휴대인터넷) 상용화 여건 조성
2. W-CDMA 서비스 조기 안정화
3. 인터넷전화(VoIP) 활성화
제3절 통신시장 공정경쟁체제 구축
1. 통신망 상호접속제도 개선
2. 이동통신단말기 보조금 정책방향 마련
3. 보편적 역무 제도 개선
4. 전기통신사업 회계제도 정비
5. 통신시장 경쟁상황평가 제도 개선
6. 결합판매 제도 개선
7. 통신․방송 융합에 적극 대응
제4절 통신 이용자보호 및 안전성 제고
1. 기간통신사업자 허가 및 M&A 제도 개선
2. 통신서비스 이용자 보호 강화
3. 휴대폰 불법복제 방지대책 수립
4. 통신재난관리체계 기반 재정비
제5절 통신사업자 및 통신서비스 현황
1. 통신사업자 현황
2. 정보통신서비스산업 현황
제5장 전파방송
제1절 전파방송 동향
1. 전파․방송분야의 동향과 전망
2. 전파방송 정책과제의 추진성과
목 차 ⅴ
3. 조직 체계
제2절 u-Korea 건설을 위한 스펙트럼 환경조성
1. 차세대 이동통신을 위한 전파자원 확보
2. 유비쿼터스 사회 건설을 위한 전파환경 구축
3. 주파수 이용관련 제도 정비
4. 주파수 이용효율화 기술 개발
5. 스펙트럼 관리 과학화로 주파수 분배 최적화
6. 위성주파수 및 궤도 확보 추진
제3절 디지털방송의 생활화, 세계화 추진
1. 디지털방송의 전국망 구축 완성
2. 지상파 및 위성DMB 서비스 도입
3. DMB 국제표준화 및 해외시장 개척
4. 방송 수신환경 개선 추진
제4절 신규방송 서비스 활성화
1. 데이터방송 활성화 기반 구축
2. 디지털 양방향 CATV 활성화
제5절 전파․방송 규제개혁 및 진흥기반 조성
1. 시장친화적 전파방송 법제도 개선
2. 소속기관 정보통신분야 평가제도 실시
3. 이용자 중심의 전파이용제도 개선
4. 기지국 공용화 제도 개선
5. 전파방송분야 중소기업 지원
6. 차세대 전파방송 핵심기술 개발
7. 전파방송 전문인력 양성
ⅵ 목 차
8. 전파방송 핵심 국제표준 활동
제6장 정보통신 국제협력
제1절 세계 정보통신 동향
1. 세계 정보통신 동향과 정책방향
2. 글로벌 IT협력 주요정책
제2절 IT산업 수출 및 해외진출 촉진
1. 정보통신산업 해외진출 동향
2. 정보통신산업 해외진출 지원
제3절 IT분야 외국인투자 활성화
1. 정보통신분야 외국인투자 현황
2. 글로벌 IT기업 R&D센터 설립 지원
제4절 IT 통상협상 대응 강화
1. 다자간 통상협상 대응
2. 양자간 통상협상 대응
제5절 글로벌 IT협력 강화
1. 글로벌 지역협력 기반 확충
2. 국제기구활동의 내실화
제6절 남북 IT 교류협력 촉진
1. IT분야 남북경제협력사업의 추진
2. 남북간 통신연결 추진
3. 민간 IT교류협력 활성화 지원
4. 남북 IT교류협력 기반조성
목 차 ⅶ
5. 새터민 정보화교육 및 남북한 정보격차해소사업의 추진
6. 남북 IT교류협력 추진상의 애로사항 개선
제7장 우정사업
제1절 정책방향 및 추진체계
1. 우정사업의 환경변화와 정책방향
2. 조직체계
3. 일반현황
제2절 경영혁신을 통한 사업기반 강화
1. 조직․인력운영의 효율화
2. 경영체제의 개선
3. 새로운 기업문화 확립
4. 우정사업 종합정보화 추진
5. 6시그마 경영혁신 활동의 정착
제3절 우편서비스의 개선
1. 우편사업의 정책방향
2. 우편사업의 현대화
3. 우편서비스의 품질향상
4. 우편물 운송 및 집배업무의 최적화
5. 소포사업의 활성화
6. 우표문화의 향상
7. 우편마케팅 활성화
제4절 국민에게 꿈을 주는 우체국금융
1. 우체국금융의 정책방향
ⅷ 목 차
2. 종합금융서비스 역량 강화
3. 수익구조 개선을 위한 서비스 확충
4. 공익사업 추진 및 국가 경제적 역할 강화
5. 정보시스템 인프라 강화
6. 우체국금융 리스크관리 강화
제5절 국제무대를 선도하는 한국 우정
1. 우정사업의 국제화 기반 강화
2. 우정사업분야 국제협력 확대
3. 우정IT 수출활성화 추진
<부록> 주요통계자료

출처 : http://mic.go.kr/