방법론...

I. 방법론이란?

1. 방법론의 정의

정보시스템 개발 방법론은 정보시스템을 개발하기 위한 방법이나, 절차, 산출물, 기법 등을 논리적으로 정리해 놓은 체계를 말한다. 즉 다시말해서 “ 전사적인 관점에서 정보시스템의 계획 수립,분석, 설계 ,구축에 필요한 상호 연계된 기법들을 적용하는 것으로 조직 전반에 걸쳐 올바른 정보를 올바른 사람에게 올바른 시점에 제공 되도록 하는 원리들의 집합

개발자들이 흔히 방법론과 혼동하는 기법은 방법론을 구성하고 있는 특정 작업을 어떻게(HOW) 수행할 것인가에 대한 수단을 제시하는 것이다. 하지만, 방법론은 언제(WHEN),무엇을(WHAT), 누가(WHO) 할 것인가를 규정하는 한편 특정 작업을 수행하기 위해 어떤 입력사항이 필요하며, 수행결과로 어떤 출력물이 생성되고 그 출력물의 용도가 무엇인가를 나타낸다

2. 방법론의 필요성

가. 기업내부환경의 변화

- 장단기 정보시스템 추진전략의 부재

- 전사적 정보시스템 전략 수립 중요성 간과

- 일시적 필요에 의한 단위 업무 자동화 추진

결과적으로

- 기업 경영 전략을 효과적으로 지원하지 못하는 시스템

- 기업 경영 전략 / 요구사항 지원 누수 현상 발생

- 전사적 시스템 통합의 어려움

- 정보시스템 중복에 의한 자원 낭비

나. 기업외부환경의 변화

- 국내외 경쟁심화로 신속한 대처방안 및 효율적인 업무수행 필요에 의한 정보시스템의 효율적인 구축방안 필요

- 신속한 의사결정을 위한 정보의 적시정, 신속성 요구로 李를 충분히 반영할 수 있는 체계적인 구축방안 필요

- 각종 신기술의 출현으로 기업의 환경에 적합한 정보시스템 구축방안 선정 및 관리기법 필요

다. 정보환경의 변화

- 업무 정보화에 대한 객관적이고 합리적인 개발 체계 요구

- 기업 업무 정보화시 사용자와 개발자 모두가 납득할 수 있고 의사소통 수단으로 사용할 수 있는 방안이 필요함

- 프로젝트의 대형화,통합화 추세로 인한 개발도구의 필요성 대두

그때 그때의 일시적인 필요에 의해 단위 업무 정보화를 추진하던

시대에서 전사적인 정보화를 추진함으로써 보다 체계적이고 거시

적인 개발 도구가 필요하게 되었음

- 개발/유지 보수 업무의 Back-log로 인한 생산성 향상 필요성 대두

새로운 업무, 점점 복잡하고 다양해진 사용자 요구를 기 구축된 시스템이 처리 능력 부족으로 업무 재설계 및 재구축 방안이 필요 하게 되었음

- 정보시스템 품질 향상 및 생산성 증대를 위한 체계 필요

라. 방법론 도입/활용의 효과

- 원할한 업무 처리를 위한 IS 구축방안 마련

- 정보 통합관리 방안 수립

- 정보활용/공유 효율화

- 정보기술 습득적 정보시스템 투자방안 제시

- 정보시스템 구축 위험부담 / 불확실성 최소화

- 현업 Reengineering을 통한 장기적인 경영목표와 경영전략 지원

- 고객 만족을 위한 고품질 정보전략 제공

- 현업 Reengineering을 통한 현업 업무 표준화

- 개발 작업의 표준화,모듈화,재사용 제고로 생산성 향상

- 표준 Repository관리로 유지보수 업무 생산성 제고

- 프로젝트 및 품질관리 능력 제고

라. 활용시 유의사항

현대의 광범위한 정보시스템 개발시 방법론 활용 및 적용은 필수 불가결한 요소로 방법론을 도외시한 개발은 있을 수 없는 일이라 할 수 있다. 그러나, 무계획적인 적용 혹은 개발환경 및 여건을 도외시한 적용은 오히려 생산성 및 담당자간의 혼란을 야기하고 납기지연등 역효과를 유발할 수 있으므로 적용시 신중을 기해야 한다.

적용시 고려사항은 다음과 같다.

- 개발경로(클라이언트-서버, 정보공학, RAD등)

- 개발환경(Host-base, C/S, Internet등)

- 개발범위(대규모, 소규모등)

- 방법론의 충분한 李해

대부분의 업체에서 제공하는 방법론은 특별한 형태가 있는 것이 아니고 대개 매뉴얼(책자) 형태로 제공되며, CD-ROM이나 인트라넷을 지원하는 경우도 있으며, 생산성 향상을 위한 자동화 도구의 제공 혹은 자동화 도구 연계방안을 제시하고 있다. 그러나, 수십권의 매뉴얼을 토대로 프로젝트를 진행해야 하므로 방법론의 충분한 李해를 바탕으로 경로,환경,범위를 고려하여 가장 적합한 수준으로 방법론 적용범위를 결정하는 것으로 교육 및 경험의 축적에 의한 접근이 필요하다.

3. 방법론의 종류

가. 세계 6대 방법론

세계적으로 유명한 주요 컨설팅 회사들은 저마다 자신의 방법론을 개발하여 판매 및 커스토마이징 컨설팅 서비스를 제공하고 있으며, 1980년말부터 불어닥친 방법론 열풍으로 국내에서도 대부분의 중견 정보통신 기업에서는 李미 방법론을 도입하여 활용하고 있다.

세계 6대 컨설팅회사의 정보시스템 구축방법론에 대해 요약해 보면 다음과 같다.

방법론명	업체명	개발시기	주요 특징
Method/1 (관리기법/1)	앤더슨 컨설팅 (Anderson Consulting)	1979	시스템 라이프 사이클 전영역과 각종 개발 접근방법을 망라한 포괄적 접근 단계,분야,업무,개발수순등 4가지 차원으로 구성된 구조적 접근 통합CASE툴인 Foundation 지원 견적, 품질관리등 관리기법 제공
SUMMIT	쿠퍼스 앤드 라이브랜드 (Coopers & Lybrand)	1987	경영전략과 연계성 목표 아키텍쳐 구축 광범위한 적용범위와 유연한 적합성 각종 기법 및 도구 제공 포괄적인 체계로 구성(작업,성과물, 역할 등) 도구의 독립성 프로젝트 관리
4Front	딜로이트 컨설팅 (Deloitte Touche Tomatsu International)	1989	정보전략기획에서 구현등 하위공정망라 통합 CASE 지원 교육 프로그램 충실 커스토마이징 가능
Fusion	언스트 앤 영 (Ernst & Young)	1991 Navigator 에서 1997년경 변경	방법론,기법,CASE, 프로젝트 관리 교육집대성 기업 형태별 Route map 제공
NNM	KPMG	1973	전략목표 지향 혁신지향 현황평가,투자효과 자문 조직 컨설팅 일체화
SMM	프라이스 워터 하우스 (Price Water House)	1986	개발 및 모형화 보유 방법론과 통합 CASE 툴과 연계 기업전략과 밀접 업무개선, 조직풍토 변혁 포함

* 李주헌 교수 역 전략정보시스템 구축론 발췌

나. 방법론 분류

구 분	방 법 론	특 징
전통적방법론을 개선한 방법론	STRADIS Sterling Methodology firstCASE	전통적방법론에 프로토타이핑, JAD 추가
회계법인 방법론	METHOD/1 System Management Method	전통적방법론에 기반 개발과정의 관리방법 중심
데이타중심 방법론	CASE*METHOD IEM PDM(Prototype Development Methodology)	전통적방법론에 기반 데이타가 프로세스에 비해 안정적이라는 사실에 기반
혼성 방법론	NAVIGATOR SILC SSADM	다른 방법론의 특성을 조합 - NAVIGATOR : METHOD/1 + IEM - SILC : 전통적방법론 + IEM + SI
재공학 방법론	RE/Center	기존 시스템의 구조화가 목적 기존 시스템의 투자보전 수단제공 유지보수기능 지원

- 방법론 비교

구분	프로젝트	정보체계	기술지향	관리지향	기법연계	기법독립	프로세스	데이터	在공학	순공학
STRADIS	4	2	3	3	2	4	3	2	1	5
FirstCASe	5	0	2	4	2	5	2	2	0	5
Method/1	4	2	2	5	2	4	2	2	2	5
IEM	3	5	5	2	5	1	1	5	0	5
IE	3	5	5	2	5	1	1	5	0	5
PDM	4	4	5	1	5	1	3	4	1	5
CASE*METHOD	4	4	4	3	4	1	3	4	1	5
SSADM	5	1	5	1	5	1	4	4	1	5
SILC	4	2	3	3	3	4	3	3	1	5
Fusion	4	4	3	5	3	3	3	3	1	5
RE/Center	3	3	5	1	4	1	3	4	5	5

주1) Jim Wilson & Lou Vincent, Making Sense of the Method Maze

주2) 평가치 : 매우강함(5) , 강함(4) , 보통(3) , 약함(2) , 매우약함(1), 계획중(3)

4. 방법론 사례

현재 세계적으로는 무수한 방법론이 존재하며 각 방법론별로 저마다의 장단점을 가지고 있어 사실상의 우열을 가리기 힘들다. 방법론의 이해를 돕기 위해 정보시스템 통합업체인 D사에서 도입,활용하고 있는 방법론을 일부 소개한다.

가. 전체구조

[그림 1]은 D사 방법론의 전체 구조이다. 그림에서 알 수 있듯이 SDLC 전부를 지원하고 있으며 정보시스템 전략수립부터 분석, 설계, 구현, 운영과 개발자/현업 담당자/관리자의 역할과 작업, 패키지 도입 등의 거의 모든 개발 범위를 포괄하고 있다

[그림1] 전체 구조도

1번째 Box는 전통적인 SDLC의 단계를 나열하여 본 방법론과의 연계성을 보여준다.

2번째 Box는 방법론의 기본 시리즈에 해당한다. 각 구성요소는 정보화 전략 수립단계인 Strategy, 분석/개략설계에 해당하는 Designer, 상세설계에 해당하는 Builder, 구현과 시험,운영에 해당하는 Implementer로 구성되어 있다. Designer 단계에서 분석결과 Package 도입이 필요한 경우 Selector 모듈과 연계되어 적합한 패키지의 선정(Select4Package) 및 커스토마이징(Adapt4Package)李 수행될 수 있도록 가이들 제시한다. 그리고, 개발 전과정에 걸쳐 관리방안을 제시하는 Manager로 구성되어 프로젝트에 대한 관리 포인트(Manage4Project)와 함께 진행절차별 관리포인트(Manage4Process)를 제공한다.

3번째 Box는 본 방법론이 제시하는 경로별 방법론으로 개발환경 및 범위에 따라 선택적으로 적용할 수 있도록 구성되어 있다. 구성을 살펴보면 Prototyping 위주로 신속한 개발을 위한 가이드를 제시하는 RAD(Rapid Application Development), 정보공학 방법론(Information Engineering), 클라이언트 서버 개발의 기술적 환경과 분산 환경을 고려한 클라이언트/서버(Client/Server) 개발방법론을 지원한다. 경로별 방법론은 기본 시리즈에 근거하고 있으므로 양적인 면에서는 기본 시리즈보다는 적으나, 기본 시리즈와 연계성이 고려되어 있으므로 설명이 부족한 경우 기본 시리즈를 참조할 수 있다.

나. 계층구조

[그림2] 계층구조

기본 시리즈나 경로별 방법론을 막론하고 본 방법론은 [그림2]와 같은 계층구조로 구성되어 있다.

구분	구성항목
Phase	목적 주요 고려사항 Subphase 작업흐름도	•Phase 수행 목적 기술 • Phase 수행시 유의사항 기술 • Phase를 구성하고 있는 Subphase명 해당 Phase를 구성하는 Subphas간의 입출력 관계 표시
Subphase	목적 주요 고려사항 입력 요구사항 출력 요구사항 관련 기법	•Subphase 수행 목적 , 유의사항 기술 • Subphase 수행에 필요한 각종 입력 사항, 수행 결과 생성되는 산출물 기술 • Subphase 수행 및 산출물 작성에 에 필요한 각종 기법 기술
Task	목적 주요 고려사항 입력 요구사항 출력 요구사항	• 수행 목적 및 유의사항 기술 • 실제 수행작업을 기술한 Step으로 구성
산출물	개요 입력 요구사항 산출물 작성요령 고려사항	•각 산출물별 성격과 내용 기술 • 산출물 작성에 필요한 입력 사항 기술 • 산출물을 구성하는 관리항목별 작성요령 설명 산출물 작성시 유의사항 기술

다. 기본 시리즈

1) Strategy(정보전략계획)

기업이 수립한 중장기 경영계획상의 경영 전략을 토대로 사업 목적에 필요한 총체적 정보체계 구조를 제시하고, 이를 바탕으로 단위 또는 통합 정보시스템 개발에 대한 중장기적인 구축방안을 제시함으로써 기업이 추구하는 미래의 경영목적을 효율적으로 달성할 수 있도록 한정된 시간과 예산을 감안하여 수립된 정보화 중장기 계획

해당 조직내의 모든(단위업무가 아님) 데이터 및 업무기능(프로세스)를 파악, 분석하여 모델링 작업을 수행하고, 李를 물리적으로 구현하기 위해 필요로하는 정보기술 요소를 도출해 낸다. 또한, 3가지 요소를 관리하는데 필요한 정보조직에 대한 정의작업이 수행된다. 李를 토대로 기업 정보화에 필요한 모든 프로젝트를 도출하여 정보시스템의 업무,전략 지원도, 예산, 기업의 정보화 정책 및 의지등을 토대로 3-5개년간의 정보화 계획을 수립한다.

[그림 3] Strategy 모듈

2) Designer

분석/개략설계에 해당되는 Designer는 strategy에서 수립된 정보시스템 전략에 근거하여 새로운 시스템 어플리케이션 모델, 데이타 모델을 작성하고 정보기술 환경을 설계하여 논리 어플리케이션, 데이타, 정보기술 환경 설계를 정리하는 계획을 수립하는 단계이다. 본 단계에서 제일 중요한 사항은 경영전략에 근거한 정보시스템 전략을 어떻게 정확하게 그대로 설계에 반영 시키는가 하는 것이다.

[그림4] Designer 구조

“Phase 1 시스템 목적 및 개발방향 설정” 단계에서는 프로젝트 개발 목적 및 개발 방향을 설정하며, 특히, 프로젝트 개발 계획 범위 선정작업과 프로세스 및 데이타 통제 위한 상위 단계의 접근 방법과 각종 개발 표준을 정의한다.

“Phase2 사용자 요구사항 정의” 단계에서는 특정 어플리케이션에 대한 사용자 요구사항을 조사하여 프로세스 모델을 정의한다. 주요 고려사항으로는 업무 표준정의 설정, 프로젝트 개발 범위 확인, 조직과 시스템에 영향을 줄 수 있는 환경 검토 및 사용자 변경 요구사항 확인등이 있다.

“Phase3 데이터 요구사항 정의” 단계에서는 어플리케이션 지원을 위한 데이타 요구사항을 프로젝트 범위내에서 정의하며, 주요 고려사항으로는 Data Dictionary를 기초로 어플리케이션과 상호 조정 작업을 수행하면서 데이타의 기본적 틀을 마련함이 있다.

“Phase4 기술과 환경 요구사항 정의” 단계에서는 기존에 구축되어 있는 정보기술 구조와 환경에 대한 사용자 요구사항의 영향을 분석, 정의하는 작업이 수행되며, 주요 고려사항으로는 잠재적으로 복잡하거나 비용이 많이 드는 네트워크등 하드웨어의 문제를 조기 발견등이 있다.

“Phase5 개발방법 선정” 단계에서는 개발 프로젝트에 적용할 개발 접근 방식 선정하는 작업이 수행된다. Phase 4까지 파악된 요구사항을 종합하여 기업환경에 최적의 개발대안을 제시한다. 본 단계에서 패키지 활용여부를 고려하여 타당한 경우 Selector module로 李동한다. 주요고려사항으로는 평가기준 수립에 의한 개발 대안에 대한 장점과 약점 파악 및 비용/수익 분석으로 실행 가능한 대안 선택등이 있다.

“Phase6 업무기능 설계” 단계에서는 새로운 물리 프로세스 모델 개발하고, 데이타 모델과 프로세스 모델 조화 및 구현 상세 설계를 위한 기능설계 확정한다. 주요 고려사항으로는 출력, 입력, 인터페이스 관련 사양 구체화 및 주요현안에 대한 다각적인 방법 검토등이 있다.

“Phase7 논리적 데이터 설계” 단계에서는 Phase 3에서 수행된 데이터 요구사항을 토대로 기업의 BUSINESS RULE을 정규화 과정을 거쳐 엔터티 모델에 반영하며, 업무 奎칙에 근거한 안정적인 데이타 구조를 구축하는 작업이 수행된다. 주요 고려 사항으로는 기업의 업무 규칙이 반영될 수 있도록 최대한의 정규화 과정을 거쳐야하는 것과 엔터티와 프로세스간의 정확하고 완전한 정보를 상호 교환함등이 있다.

“Phase8 기술과 환경 설계” 단계에서는 기업의 개발범위에 적합한 H/W 와 시스템 S/W의 구성 결정하며, 통신 네트워크 기본 설계 및 기술과 환경 설계의 환경적 영향 평가작업이 수행된다. 그러나, 새로운 시스템이 현재의 기술환경을 사용한다면 본 단계는 대부분 생략되며, 정보기술에 대한 상세한 설명은 불필요하다.

“Phase9 상세 개발계획” 단계에서는 추진중인 시스템의 상세한 설계, 개발 및 구현을 준비한다. 즉, 소요자원 및 일정에 대한 조정 및 검토작업이 수행되며, 상세 설계 및 구현을 위한 在정비 작업이 진행된다.

3) Builder

상세설계 및 구현에 해당되는 Designer 단계에서는 작성된 새로운 시스템의 어플리케이션 모델과 데이타 모델로부터 물리적인 어플리케이션 시스템과 데이타베이스를 구축한다. 본 단계에서는 어플리케이션과 데이타베이스의 생성 자동화, 구조화 등으로 유지 보수하기 쉬운 프로그램의 생성등 효율화에 역점을 두어야 한다.

[그림5] Builder 구조

“Phase 1 상세설계계획“ 단계에서는 상세설계 단계에서 수행할 업무 범위를 조정,확인하며, 수행조직의 업무분장 및 상세 설계 세부 계획을 수립한다. 본 단계에서 개발자와 현업 담당자간에 업무계획, 표준 조직, 접근방법에 대한 동의가 선행되어야 한다.

“Phase 2 어플리케이션 상세설계“ 단계에서는 Designer 단계에서 수행한 업무 기능 설계를 상세 설계로 변환하며, 어플리케이션에 대한 무결성을 확인하는 작업을 수행한다. 특히, 최종 이용자의 모든 화면의 데이터 내용을 비롯하여 사용자 인터페이스 문제의 적합성 보장하며, 시스템 통제사양에 대한 어플리케이션 프로그램내의 논리적처리 반영하여야 한다.

“Phase 3 물리적 데이터 설계“ 단계에서는 논리적 엔터티 모델링을 통해 도출된 엔터티를 기초로 DBMS의 환경에 적합한 물리적 DATABASE 환경 구축하는 작업을 수행한다. 테이블 명세서에 가공된 데이타 및 요약 테이블을 포함하여 어플리케이션을 지원할 수 있는 모든 자료사전을 구축한다.

“Phase 4 기술과 환경 상세설계“ 단계에서는 기술과 환경의 기본 설계를 상세 설계 사양으로 변환하며, 특정한 모델과 수량을 결정하며 기술 계약을 준비하고 협상하는 작업을 수행한다. 특히, 공급업체 선정을 위해 기술과 관련된 선택사양을 고려하고, 네트워크나 DB 사용이 주요한 요소를 확정한다. 필요시 전문가의 도움을 받는다.

“Phase 5 구축계획 수립“ 단계에서는 상세 시스템 코딩과 개발의 완성을 위한 통제, 지시 및 구축 계획을 개발한다. 구축과 테스팅에 필요한 환경을 조성하고 구현에 필요한 하드웨어와 소프트웨어를 조사한다.

“Phase 6프로그램 명세서 작성“ 단계에서는 어플리케이션을 코딩, 테스팅, 구현하는데 필요한 프로그램 사양을 개발한다. 기술적인 전문지식의 전문 인력을 참여시켜 프로그램 코딩 개시전 주의 깊은 문서 검토작업을 논리 오류를 최소화한다.

“Phase 7기술과 환경 구축“ 단계에서는 어플리케이션 개발 및 테스팅에 필요한 최소한의 기술과 환경을 설치한다. 기술 환경의 변화 정도에 따라 어플리케이션 개발과 테스팅에 필요한 기술과 설치하는데 필요한 노력이 크게 달라지므로 유의하여야 한다.

“Phase 8 물리적 데이터 구축“ 단계에서는 테이블 관련 주요 문제점들을 기초로 향후 예상되는 상황을 계획하고 테스트하여 결과 및 조치사항을 도출한다. PHASE 3에서 도출된 테이블 자체 및 테이블간의 문제점들을 데이타의 관점에서 해결 방안을 모색한다.

“Phase 9 프로그램 코딩과 테스트“ 단계에서는 분석/설계 결과를 바탕으로 프로그램 코딩으로 변환하며, 구현된 프로그램에 대한 단위 테스트와 통합 테스트 실행한다.

“Phase 10 시험 및 운영계획“ 단계에서는 구축된 시스템 구성 요소들을 시스템으로 李행하여 운영하기 위한 계획을 수립한다. 또한, 사용자의 요구사항이 프로그램에 충실히 반영되었는지의 여부에 대한 승인을 득한다.

4) Implementer

시험/운영에 해당하는 Implementer단계에서는 개발/구축된 어플리케이션 시스템과 데이타베이스를 설정된 정보 기술환경에서 실제로 운영하여 사용자 요구사항에 부합하는지 , 혹은 계획된 기능을 제대로 수행하는지를 평가한다. 본 단계에서는 시스템의 기능적, 기술적 품질을 평가하여 사용자의 요구를 충족시켜야 하고, 각종 품질 지침의 기준에 부합하도록 시스템 시험을 수행한다.

[그림4] Implementer 구조

“Phase 1 시험 및 운영준비” 단계에서는 개발환경에서 운영환경으로 전환하기 위한 준비작업을 수행한다. 구현된 시스템에 대한 사용자 매뉴얼을 작성하여 운영 및 사용교육을 실시하고, 시스템 운영계획을 수립한다. 특히, 패키지 도입이 결정된 경우 Builder 또는 adapt4packages 와 동시에 수행한다.

“Phase 2 초기 시스템 운영” 단계에서는 시스템 가동 및 운영을 위한 최종 테스트 및 李행작업을 수행한다. 사용자 및 인수시험을 통해 오류를 최종적으로 확인,수정하여 정상운영에 만전을 기한다. 특히, 기존에 운영하고 있는 유사업무가 있는 경우 병행운영후 전환등 李행계획 수립 및 실행에 유의하여야 한다.

“Phase 3 사용자 만족도 조사” 단계에서는 시스템의 전반적인 운영을 평가하기 위해 설치 李후 검토작업을 수행하는 것으로, 설치 완료 후 약 4-6개월 후 수행하여 시스템 개선을 위한 기회를 파악한다.