표준 개발 프로세스

(절차 및 산출물 요약)

Project : 자바/유닉스(리눅스) 기반 웹사이트 구축

Phase : 분석/설계/구현/테스트

Author : 개발실 곽중선

Last update : 2009년 09월 15일

Copyrights© 2006 Sunny Kwak All rights reserved.

Other disclaimers

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

VersionVersion 1.0 (draft)

HistoryMay 24, 2006 First created.

Nov 26, 2006 Drill down

December 28, 2006 Add chapter 3

2 / 27

Table of Contents

1. 문서의 개요 및 개발절차 이해.........................................................................................6

1.1 문서의 목적 (OBJECTIVE)................................................................................................................61.2 문서 요약 (SUMMARY)....................................................................................................................61.3 문서 활용 대상 (WHO)..................................................................................................................61.4 소프트웨어 개발 절차...................................................................................................................6

1.4.1 다섯 단계의 라이프사이클......................................................................................................................6

1.4.2 폭포(waterfall) 모델과 나선(spiral) 모델.................................................................................................7

1.4.3 개발방법론.............................................................................................................................................8

1.4.4 효과적인 시스템 분석 요령.....................................................................................................................8

2. 개발 및 운영환경 정의..................................................................................................9

2.1 하드웨어, 네트워크 및 보안...........................................................................................................92.1.1 서버 장비 선정........................................................................................................................................9

2.1.2 네트워크 및 보안체제...........................................................................................................................10

2.2 소프트웨어 환경 (기본 구성)........................................................................................................102.2.1 운영체제...............................................................................................................................................10

2.2.2 웹 컨테이너 서버..................................................................................................................................10

2.2.3 미들웨어 (Middleware).........................................................................................................................10

2.2.4 검색엔진 (Search engine).....................................................................................................................11

2.2.5 로그 분석 도구 (WebLog Analyzer)......................................................................................................11

2.2.6 데이터베이스 (Database).....................................................................................................................11

2.3 소프트웨어 환경 (연동 대상)........................................................................................................122.3.1 레거시 시스템 (legacy system).............................................................................................................12

2.3.2 ERP (Enterprise Resource Planning) System......................................................................................12

2.3.3 POS (Point Of Sales) System..............................................................................................................12

2.3.4 CMS (Contents Management System).................................................................................................12

2.3.5 SMS or MMS........................................................................................................................................12

2.3.6 PG (Payment Gateway).......................................................................................................................12

2.3.7 대량 메일 발송......................................................................................................................................13

2.3.8 실명 인증 서비스..................................................................................................................................13

2.3.9 GIS (Geographic information system)..................................................................................................13

2.3.10 CDN (Contents Delivery Network)........................................................................................................13

2.3.11 DRM (Digital Right Management)........................................................................................................13

2.3.12 보고서 생성 도구 (Reporting Tool)........................................................................................................13

3. 표준 개발 절차.........................................................................................................13

3 / 27

3.1 비즈니스 모델링.........................................................................................................................133.1.1 도메인 모델링.......................................................................................................................................14

3.1.2 요구사항 정의.......................................................................................................................................14

3.2 아키텍쳐링 (ARCHITECTURING)......................................................................................................153.2.1 아키텍쳐 정의.......................................................................................................................................15

3.2.2 컴포넌트 추출.......................................................................................................................................16

3.3 시스템 설계...............................................................................................................................163.3.1 컴포넌트 상세 설계...............................................................................................................................16

3.3.2 컴포넌트 상세화...................................................................................................................................16

3.3.3 유즈케이스 상세화................................................................................................................................17

3.3.4 화면 설계..............................................................................................................................................17

3.4 시스템 구현...............................................................................................................................173.4.1 어플리케이션 구현................................................................................................................................17

3.4.2 테스트................................................................................................................................................... 18

3.5 배치 (DEPLOY)............................................................................................................................183.5.1 시스템 릴리즈.......................................................................................................................................19

3.5.2 사용자 교육..........................................................................................................................................19

4. 개발 업무 세부지침....................................................................................................19

4.1 상세 업무 및 산출물 정의............................................................................................................194.1.1 대규모 프로젝트...................................................................................................................................19

4.1.2 중소규모 프로젝트................................................................................................................................20

4.2 산출물 작성 지침........................................................................................................................214.2.1 비즈니스 모델링...................................................................................................................................21

4.2.2 아키텍쳐링...........................................................................................................................................23

4.2.3 설계...................................................................................................................................................... 23

4.2.4 구현...................................................................................................................................................... 24

4.2.5 배치...................................................................................................................................................... 24

4.3 UML 적용 방안..........................................................................................................................244.3.1 UML 요약..............................................................................................................................................24

List of Figures[ Figure 1 ] 폭포 모델.........................................................................................................................................7

[ Figure 2 ] 나선 모델.........................................................................................................................................7

List of Tables[ Table 1 ] 대규모 프로젝트 단계별 업무 및 산출물 정의...................................................................................19

4 / 27

[ Table 2 ] 중소규모 프로젝트 단계별 업무 및 산출물 정의...............................................................................20

5 / 27

1. 문서의 개요 및 개발절차 이해

1.1 문서의 목적 (Objective)본 문서는 자바/유닉스(리눅스) 환경 기반의 웹 사이트 구축 프로젝트를 수행함에 있어 개발실 내부 업무

프로세스를 표준화한다. 더불어 고객과의 개발 관련 요구분석을 수행하는데 필요한 지식을 체계화 한다.

본 문서를 통해 고객, 기획자, 개발자 간에 상호 이해와 협력을 도모할 수 있다.

1.2 문서 요약 (Summary)본 문서에 포함되는 내용들은 다음과 같다.

개발환경 및 운영환경 정의 절차

분석/설계/개발/테스트 단계의 개발 프로세스 정의

각 단계에서 작성하는 프로젝트 개발 산출물

각 단계에서 고려해야 하는 제반 사항 및 유의해야 할 사항

1.3 문서 활용 대상 (Who)개발 책임자 및 테크니컬 리더

프로젝트 관리자 (기획자 혹은 개발자)

소프트웨어 개발 절차를 이해하고자 하는 전문 개발자

1.4 소프트웨어 개발 절차소프트웨어 개발 절차에 대해 간략히 설명하자면 다음과 같다.

1.4.1 다섯 단계의 라이프사이클소프트웨어를 개발할 때는 크게 분석 설계 구현(프로그래밍) 테스트 운영/유지보수 라는 다섯

사이클을 반복하게 된다. 이중에서 가장 중요한 것은 ‘분석’과 ‘설계’이다. 이 두 가지를 기초 공정이라고

하는데, 분석이란 “어떤 소프트웨어(혹은 서비스)를 만들 것인가”를 결정하는 단계이며, 설계란 “

소프트웨어를 구체적으로 어떻게 만들 것인지”를 결정하는 작업을 의미한다. 양쪽 모두 소프트웨어가

어떤 데이터 및 프로세스를 다룰 것인지를 정의해 간다는 공통점을 가지고 있다. 즉, 이 기초 공정에서

실패하면 아무리 우수한 프로그래밍 기술을 가지고 있다고 해도 좋은 소프트웨어(혹은 서비스)를 만들 수

없다.

여기서 반복한다는 표현의 의미를 정확히 이해해야 한다. 소프트웨어는 물리적인 상품(컴퓨터, TV, 휴대폰

등)과는 달리 한번 개발을 마친 이후에도 끊임없이 변화할 수 있다. 즉, 한번 개발했다고 해서 완료되는

것이 아니라 추가 기능 구현이나, 외부 환경의 변화(트렌드 변화 등)로 인해 이미 운영 중인 시스템을

6 / 27

재개발하게 되는 것이다. 이러한 점이 소프트웨어의 강점이자 또한 약점이 되는데, 정확한 분석/설계

자료를 남기지 않게 되면 추후에 재개발이 필요한 상황에서는 이전에 개발된 시스템을 제대로 활용할 수

없게 된다.

1.4.2 폭포(waterfall) 모델과 나선(spiral) 모델시스템 개발 순서는 방법에 따라 ‘폭포 모델’과 ‘나선 모델로 나뉠 수 있다. 우선 폭포 모델은 요구분석

외부 설계(개략적 설계) 내부 설계(상세 설계) 프로그램 설계 프로그래밍 테스트 배치 라는

순서를 엄수하며, 각각의 공정에서 문서를 작성하고 평가한 후 다음 공정으로 진행하는 것이다. 폭포라는

이름에서 알 수 있듯이 앞으로 되돌아 가는 낭비를 막는 것을 목적으로 한다.

[ Figure 1 ] 폭포 모델

나선 모델은 시스템 개발 공정을 크게 요구분석 설계 프로그래밍 배치로 구분하고 각각의 공정에서

분석, 설계, 구현 평가를 작은 단위로 반복하면서 개발을 진행한다. 나선이라는 이름 그대로 시스템을

부분적으로 빙빙 돌아가면서 개발하는 방법이라고 할 수 있다. 객체 단위로 시스템을 분할하는 객체지향

방법론에서는 나선 모델이 적합하다.

7 / 27

요구분석

외부설계

내부설계

프로그램설계

프로그래밍

테스트

배치

[ Figure 2 ] 나선 모델

폭포 모델에서는 상당한 공정이 진행되지 않으면 시스템의 구체적인 모습을 볼 수 없다는 문제가

존재한다. 하지만 나선 모델에서는 객체 단위로 시스템의 부분적인 모습을 볼 수 있다. 외부에서 수주한

프로젝트의 경우는 각 단계가 명확히 구분되어야 하며, 일정이 준수되어야 하므로 폭포 모델이 적합하다.

그러나, 사내 신기술 연구 프로젝트나 시범 프로젝트(prototyping)를 수행할 경우에는 나선 모델을 검토할

만 하다. 최신 객체지향 방법론 그리고 소규모 프로젝트에서는 나선 모델이 더욱 효율적이라고 알려져

있다.

1.4.3 개발방법론개발 과정을 수행하는데 있어서 필요한 세부 절차를 체계화 시킨 것이 방법론이다. 방법론은 주로 분석/

설계 단계에서 활용되며, 대규모 프로젝트의 성공적인 수행을 위해 방법론을 적용하는 것을 권고한다.

다만, 소규모 프로젝트를 수행할 때 방법론을 완벽히 적용하는 것은 지나친 시간과 인력의 낭비가 될 수

있다.

방법론 혹은 분석/설계 방법은 아래와 같은 순서로 발전해 왔으며, 이외에도 다양한 방법론이 제시되었고

계속 새로운 방법론이 제시되고 있다. 실제 개발을 진행하는 단계에서는 하나의 방법론만을 사용하는 것이

아니라, 특정 방법론을 주로 사용하되 다른 방법론도 함께 사용하게 된다. 예를 들어 객체지향 방법론을

채택하더라도 데이터베이스 분석/설계를 위해 ER 모델링을 사용하게 된다.

구조화 분석/설계

구조화 분석/설계란 시스템으로 전환할 대상을 다양한 단위로 분할하면서 분석하는 방법이다. 주로 대상

(혹은 비즈니스)이 포함하는 자료를 위주로 분석하기 때문에 DOA(Data Oriented Approach)라고도 불린다.

1970년 대 초에 제창되었으며, 90년대 초까지 활용된 방법론이다.

8 / 27

요구분석분석 설계

리뷰 구현

설계분석 설계

리뷰 구현

구현분석 설계

리뷰 구현

배치분석 설계

리뷰 구현

객체지향 분석/설계

객체지향 분석/설계는 객체의 존재 방식에 주목하여 데이터와 그 기능을 일체화하여 분석/설계하는

방법으로 90년대 중반 이후에 각광 받고 있으며, 다양한 연구자에 의해 여러 방법론이 소개되고 있다. 또한

2000년대 들어서 가장 널리 사용되는 방법론이다.

1.4.4 효과적인 시스템 분석 요령분석이란 효과적인 해결 방법을 찾기 위해 수행하는 ‘사전 조사’를 말한다. 간단히 말하면 ‘어떤 문제가

있는가’, ‘어떻게 되어야 문제가 해결되었다고 할 수 있는가’, ‘해결 방법으로 생각할 수 있는 것은

무엇인가’와 같은 사항을 명확하게 하는 작업을 말한다.

그럼 어떻게 해야 ‘올바른 분석’을 수행할 수 있는가? 최소한 다음 5가지 요령을 알아 두어야 한다.

시스템으로 해결할 수 있는 문제인가 확인한다

분석의 목적은 시스템을 개발하여 사용자의 문제를 정말 해결할 수 있는가 확인하는 것이다. 당연한

것이지만 의외로 간과하는 경우가 많다. 왜냐하면 대게 소프트웨어 개발자들은 ‘시스템의 사용자의 문제를

해결하는지’ 보다 ‘일단 시스템을 개발하는’ 쪽을 우선하는 경향이 있기 때문이다.

분석 담당자는 시스템화 하는 것이 정말 사용자에게 이익이 되는지를 판단하는 중요한 역할도 가지고 있다.

업무 지식에 지나치게 의존하지 않는다

일반적으로 업무용 어플리케이션을 ‘분석/설계’하기 위해서는 풍부한 업무 지식이 필요하다. 은행이라면

금융에 대한 지식, 병원 시스템을 개발한다면 의료사무 업무절차에 대한 지식을 알아야 한다. 하지만,

업무에 대한 지식을 습득하고 있더라도 실패하는 경우가 종종 발생한다. 그렇기 때문에 이미 알고 있는

지식을 활용하는데 있어서도 몇 가지 주의해야 할 점이 있다.

우선 ‘전문용어 사투리’ 문제인데, 모든 사용자가 같은 의미로 전문 용어를 사용한다고 간주하지 말아야

한다. 예를 들어 ‘직위’, ‘급여’, ‘재고’, ‘품목’, ‘평가’라는 극히 기본적인 용어에 대해서도 각 기업마다

미묘한 해석의 차이를 가지고 있다.

시스템 요건의 ‘우선순위’를 결정한다

시스템 개발을 수행할 때 ‘사용자가 원하는 것’과 ‘실제로 구현 가능한 것 사이에는 큰 차이가 있다. 그렇기

때문에 초기 단계에서 ‘원하는 것’과 ‘실현 가능한 것’을 분명히 정리할 필요 있다. 그렇지 않으면 사용자와

프로젝트팀 간에 오해가 생길 수도 있으며, 일정을 준수할 없게 되기도 한다.

그 정리 방법으로 ‘새로운 시스템에서 실현할 기능과 효과(시스템 요건)의 관계를 사용하여 분석가가

구조화한 다음 우선순위를 부여’해야만 한다.

현재 시스템의 강점과 제약을 탐색한다

분석 공정에서는 작업의 진행 방법을 중심으로 테이블이나 프로그램 등 현재 상황을 조사한다. 이를 ‘현장

분석’이라고 한다. 단, 아무리 현장 분석에 시간을 들여서 꼼꼼히 했다고 해도 반드시 새로운 시스템이

그만큼 좋아진다는 보장은 없다. 그렇기 때문에 목적을 명확히 하여 그에 맞는 방법으로 현장 분석을

9 / 27

수행해야 한다. 그 목적이란 현행 업무의 강점과 제약을 찾아내는 것이다.

예비적인 기본 설계를 실시한다

분석 작업에서는 ‘해결해야 할 문제는 이것이다’라는 식의 결과만이 아니라 ‘어떻게 하면 문제들을 해결할

수 있는가’ 까지 정리해야 한다. 즉, 구체적인 해결방법(설계)을 동시에 제시하지 않는 한 정말로 문제를

분석한 것이 아니라는 것이다.

업무 흐름도

데이터 모델

서브 시스템 구성도

하드웨어 구성도

도입효과 예상 견적

2. 개발 및 운영환경 정의개발팀이 프로젝트에 투입되었을 때, 가장 우선적으로 선행해야 하는 작업은 개발 및 운영을 위한 플랫폼

(platform) 및 각종 환경을 결정하는 것이다. 개발환경 및 운영환경 정의는 요구분석 업무 이전에 수행할

것을 권장한다. 이를 선행하지 않았을 경우에는 고객의 요구사항 중 수용 불가능한 것들조차 받아들이게

될 수도 있게 된다. 예를 들어, 운영 환경의 시스템 자원이 허용하지 않는 수준의 성능을 요청 받을 수도

있다는 것이다.

2.1 하드웨어, 네트워크 및 보안

2.1.1 서버 장비 선정소프트웨어 구축 서비스를 전적으로 제공하는 경우, 하드웨어적인 문제에 대해서는 가급적 외부의 지원을

받아야 한다. 점검의 주된 목적은 하드웨어와 소프트웨어 간의 호환성, 안정성을 확보하는데 있다.

2.1.2 네트워크 및 보안체제서버 상에 개인 정보를 암호화하여 보관한다거나, 고객 사의 고유 정책에 따라 각종 보안 체제를

준수하여야 하는지 여부를 파악하여야 한다. 구체적인 보안 관련 이슈를 들면 다음과 같다.

방화벽을 통한 접근고객 사의 개발 및 운영 서버에 접근하기 위해 방화벽 해제를 요청해야 하는 경우와 가상사설망(VPN :

Virtual Private Network)을 통한 접근이 발생하는 경우가 있다.

자료 암호화 요청서버 상에 저장되는 사용자 주민번호는 대칭 암호화 기술을 적용하여야 하며, 비밀번호는 비대칭 암호화를

10 / 27

적용하여야 한다. 또한 쇼핑몰 등 사용자 정보를 서버와 블특정 클라이언트 간에 전송하는 경우에는

SSL(Secure Socket Layer) 프로토콜 등을 적용해야 한다. 더불어 고객사 보유의 암호화 모듈을 사용하여

자료 암호화를 실시하여야 하는 경우가 있다.

보안을 고려한 개발(코딩)외부에서의 해킹을 방지하기 위해 보안 규정에 따른 개발을 실시하여야 하는 경우가 있다. 다음은 주로

제시되는 보안 규정이다.

웹 페이지 주소 작성 시 SQL injection 방지

세션 혹은 쿠키 사용 불가

주석 처리 시 서버 정보 포함 불가

2.2 소프트웨어 환경 (기본 구성)운영체제, 외부 도입 솔루션, 프레임워크, 라이브러리 등 소프트웨어 전반에 대한 사전 점검을 실시하여야

한다. 원칙적으로는 계약 이전에 선행되어야 하나 필히 요구분석 단계에서 다시 한 번 점검해야 한다.

2.2.1 운영체제가장 최신 버전의 운영체제가 설치되어 있는가 확인해야 한다. 최신 버전일수록 보안, 안정성, 호환성

면에서 우수하다.

2.2.2 웹 컨테이너 서버웹 서버는 고객이 제공하는 경우와 공개 버전 서버를 활용하는 두 가지 선택으로 나눌 수 있다. 고객의

비즈니스 성격을 고려하여 결정하되 주로 선택 가능한 방식은 다음과 같다. 각 사례 중 어떤 것이 가장

좋다고 권할 수는 없으나, 가급적 고객의 환경을 면밀히 검토하여 가장 적절한 환경을 채택해야 한다.

2.2.3 미들웨어 (Middleware)대규모 시스템을 개발할 경우, 필수적으로 다계층(n-tier) 구조를 채택하게 되며 이를 위해 미들웨어를

도입하게 된다. 미들웨어는 웹 서버와 데이터베이스 서버 사이에 위치하며, 비즈니스 로직 및 트랜잭션

처리 등을 수행한다. 자바 환경에서 가장 널리 활용되는 미들웨어는 2006년 기준으로 티맥스소프트 사의

제우스(JEUS), BEA systems 사의 웹로직(WebLogic), IBM 사의 WebSphere 등이다. 미들웨어 선정은 거의

고객의 기존 업무 환경 및 정책에 따라 결정되나 개발을 진행하기에 앞서 해당 패키지에 대한 경험자를

투입하거나, 외부 교육을 받는 준비가 필수적이다.

2.2.4 검색엔진 (Search engine)웹 서비스의 자료를 검색하는데 방법으로 가장 단순한 방법은 데이터베이스에 내장된 검색 기능을

사용하는 것이지만, 대용량 문서나 첨부 문서 등을 검색할 수 없다는 단점을 지니고 있다. 따라서, 고속으로

11 / 27

대량의 자료를 검색하고자 할 때는 검색엔진 도입을 검토하게 된다. 다만, 실시간 인기 검색어 추천, 검색

단어 자동 완성 등의 기능은 제공되지 않으므로 사전에 제약사항을 고객측에 인지시켜야 한다.

웹 서비스 규모 및 성격에 따라 권고하는 검색엔진은 다음과 같다.

소규모 웹 사이트

웹 사이트에서 제공되는 정적인 컨텐츠 만을 검색하는 브랜드 및 기업 홍보 사이트인 경우, 루슨을 이용한

공개 소스 기반 검색엔진을 제공한다. (자체 보유 및 커스터마이징 필요)

중규모 웹 사이트

게시판 등에서 누적되는 자료를 검색해야 한다면, 나모 딥서치(DeepSearch)를 활용할 수 있으며 최대 10

만건의 문서를 색인할 수 있다.

대규모 웹 사이트

회원 수 10만 이상의 웹 사이트를 구축할 경우에는 쓰리소프트 사에서 제공하는 K2 검색엔진을 제공하는

것이 좋다. 다만, 일정 부분 커스터마이징을 거쳐야 한다. 고객이 K2보다 고성능 검색엔진(포털 사이트

등에 활용되는 대용량 검색엔진)을 채택하기를 희망한다면 전문 검색엔진 업체(다이퀘스트 등)의 제품을

도입하게 되며, 이 경우 검색엔진의 커스터마이징을 납품업체가 진행하게 된다.

2.2.5 로그 분석 도구 (WebLog Analyzer)웹 로그 분석이란 웹 서버를 실행시키면서 생성되는 웹의 로그파일을 수집 / 분석하여 사이트의 에러,

방문자수, 방문 경로 등 기본적인 작업은 물론 유입경로 분석, 페이지 분석, 환경 분석 등을 수집하여

웹사이트의 사용량에 대한 분석 및 통계를 수행하는 것을 말한다.

분석용 스크립트를 사이트에 삽입함으로써 웹 로그 분석을 이용할 수 있는 ASP형태의 웹 로그 서비스와

패키지 자체를 구매하는 형태가 있다.

2.2.6 데이터베이스 (Database)사용자 및 관리자에 의해 생성되는 거의 모든 자료를 저장하며, 고속으로 검색, 조회할 수 있게끔 하는

시스템으로 웹 사이트 구축에 있어 웹 서버와 함께 가장 중요한 솔루션이다. 사이트 규모와 안정성 대한

기준에 따라 몇 가지 선택이 가능하다.

Oracle세계적으로 가장 점유율이 높고, 성능과 기능 면에서도 우수한 제품이나 가격대가 높기 때문에 대기업

등에서 주로 사용한다.

MS-SQL윈도우 기반 환경에서 가장 널리 쓰이며, 오라클과 함께 시장을 양분하고 있는 제품이다 성능과 기능

면에서도 오라클에 뒤지지 않는다.

12 / 27

MySQL소규모 시스템에 적합한 무료 혹은 저렴한 비용으로 이용할 수 있는 데이터베이스 솔루션이나, 안정성이

떨어지는 단점이 있다.

Sybase, Informix, IBM DB2기업용 데이터베이스로 많이 쓰였으나 최근에 활용되는 곳이 적어진 상태이다. 그러나, 공공기관 등에서는

여전히 활용되고 있다.

2.3 소프트웨어 환경 (연동 대상)2.3.1 레거시 시스템 (legacy system)

오래된 혹은 낡은 시스템이라는 표현으로 사용되며, 초창기 전산화 과정에서 구축되어 10년 이상 장기

운영 중인 기업 내부 정보시스템을 일컫는다. 대부분의 기업들이 시스템 재구축을 수행한 바 있기 때문에

낡은 시스템을 접하게 될 경우는 거의 없으나, 시스템 컨설팅 등을 수행하는 과정에서 자주 접하게 되는

용어이므로 이해해 둘 필요가 있다. 간혹 고객 측에서 레거시 시스템과 웹 사이트 간의 연동을 요구하는

경우가 발생한다.

2.3.2 ERP (Enterprise Resource Planning) System전사적 자원 관리시스템이라고도 불리며, 기업활동을 위해 사용되는 기업 내의 모든 인적, 물적 자원을

효율적으로 관리하여 궁극적으로 기업의 경쟁력을 강화시켜 주는 역할을 하는 통합정보 시스템이다. SAP

제품이 가장 널리 공급된 솔루션이나, 중소 솔루션 업체에서 제작한 ERP 제품도 많이 볼 수 있다. 웹

서비스를 구축할 때 연동 구축에 대한 요구가 종종 발생한다.

2.3.3 POS (Point Of Sales) System판매가 이루어짐과 동시에 판매 활동을 관리하는 시스템. 매장의 금전 등록기와 본사의 컴퓨터를

연결하여, 판매 즉시 그 데이터가 입력되어 매상 관리, 재고 관리, 상품 관리를 할 수 있게 한다. 이러한

시스템을 쇼핑몰, 물류 및 택배 회사, 편의점 등에서 채택되고 있으며, 웹 서비스 개발 시 연동 대상이다.

2.3.4 CMS (Contents Management System)회사가 보유하고 있는 컨텐츠를 인터넷으로 서비스하고자 할 때, 기존의 html, asp, jsp 등의 방식으로는

많은 제약과 어려움이 있으며, 대량의 컨텐츠를 제공해야 하거나 다수의 사이트를 단시간 내에 구축하고

관리하는 경우, 더 나아가서는 유선과 무선 서비스를 동시에 제공해야 하는 경우에는 문제가 더욱

복잡해지고 많은 비용과 시간이 소요된다. 이러한 문제점을 없애고 신속하고 편리하게 사이트를 구축,

통합, 관리, 수정할 수 있게 하는 시스템이다. CMS의 목표는 탁월하나 개발하는 과정에서 입력, 개발에

대한 추가 비용 및 시간이 발생하므로 권장하지 않는다.

13 / 27

2.3.5 SMS or MMSSMS(Short Message Service)은 웹 서비스에 가입한 회원들에게 휴대폰 문자 메시지를 발송하는

서비스이며, MMS(Multimedia Messaging System)는 SMS에서 발전하여 정지영상, 음악, 음성, 동영상 등을

발송하는 서비스이다. 회원 가입이 필수적인 교육, 커뮤니티, 쇼핑몰 등의 사이트에서 채택하는 경우가

많고, ASP(Application Service Provider / 소프트웨어 임대 서비스) 형태로 제공된다. 따라서, 지속적으로

고객 측에 추가 비용이 발생한다는 점을 인지시켜야 한다.

2.3.6 PG (Payment Gateway)지불 대행 서비스라고 불리며, 쇼핑몰 서비스인 경우 상품에 대한 소액 및 카드 결제를 위해 도입하게 된다.

상품 금액의 일정 부분을 이니텍, 데이콤, KCP 등의 업체에 수수료로 제공하며, 개발 시에 연동 작업을

수행해야 한다.

2.3.7 대량 메일 발송뉴스레터, 공지사항 등을 회원들에게 일괄 발송하기 위해 사용되는 솔루션이며, 다양한 제품이 시장에

선보인 상태이지만 주도적인 시장 지배자는 없다. 대량 메일을 발송할 경우, 서버의 부하가 높아지기

때문에 제품의 성능과 신뢰성을 사전에 점검해야 한다.

2.3.8 실명 인증 서비스실명확인 서비스란 인터넷 회원 가입이나 거래 계약 시 고객이 입력한 주민등록번호와 성명의 일치 여부를

확인시켜주는 서비스이다. 실명확인을 통해 회원별 컨텐츠 차별화, 불량회원 차단, 회원에 대한 신뢰도

확보 등의 효과를 기대할 수 있다. ASP 형태로 제공되며, 쇼핑몰 업체에서는 필수적으로 도입해야 하는

서비스 이다.

2.3.9 GIS (Geographic information system)지리정보 시스템이라고도 하며, 지도 및 위치 정보를 제공하는 솔루션이다. 국내에서는 콩나물닷컴이 가장

유명하며 점유율이 높다. 일반적으로 ASP 서비스를 제공하며, 음식점, 여행 정보 등을 제공하는

서비스에서 활용 가능하다.

2.3.10 CDN (Contents Delivery Network)CDN이란 인터넷 사용자들로부터 멀리 떨어져 있는 컨텐츠 제공업자(CP)의 웹서버에 집중되어 있는

컨텐츠를 중 그림, 배너, 비디오 혹은 오디오와 같이 용량이 크거나 사용자들의 요구가 잦은 컨텐츠를

인터넷 서비스 제공업자(ISP)의 접속점(POP)에 설치한 CDN 서버에 미리 저장해 놓고, 컨텐츠 요구 발생 시

최적의 CDN 서버로부터 사용자에게 컨텐츠를 전달하는 대용량 데이터 전송 서비스 이다. 이러한

서비스는 최근 대두되고 있는 UCC(User Created Contents)의 필수적인 기반 환경으로 적용되고 있다.

2.3.11 DRM (Digital Right Management)디지털 저작권 관리 시스템이라고 하며, 디지털 형태로 존재하는 문서, 음악 파일 등의 불법 복제 및 인쇄,

부당 유출 등을 제한하기 위해 컨텐츠를 암호화 시키는 솔루션이다. 오디오북, MP3 파일을 제공하는

14 / 27

사이트에서 주로 채택한다.

2.3.12 보고서 생성 도구 (Reporting Tool)웹 사이트를 구축한 이후에는 회원의 방문 횟수 증감 추이, 연령 및 성별 등에 의한 분포도 등 다양한 통계

보고서를 생성해야 하며 이러한 작업을 손쉽게 처리할 수 있도록 도와주는 도구가 리포팅 툴이다.

3. 표준 개발 절차앞서 기술한 점검 사항들을 숙지했다면, 실제 개발 환경을 준비하고 개발에 착수해야 한다. 개발 환경을

준비하는 과정을 순차적으로 설명할 것이나, 이와 같은 절차를 완벽하게 준수할 필요는 없으며 대략적인

가이드로 활용할 것을 권고한다. 예를 들어 아키텍쳐 정의 및 비즈니스 모델링 단계는 동시에 진행하거나

순서를 바꾸어도 무관하다.

3.1 비즈니스 모델링일반적으로 요구분석 단계를 의미하며, 기획자 혹은 PM과 개발자가 함께 고객을 면담하면서 업무 범위를

파악하며, 구현 가능한 범위를 제한하는 것이다. 여기서, 제한한다는 표현을 쓰는 이유는 한정된 시간과

자원으로 고객의 모든 요구를 수용하는 것이 현실적으로 불가능하기 때문에 요구사항에 대한 우선순위와

투자 가치를 판단한 후에 구현 가능한 범위를 결정하기 때문이다.

3.1.1 도메인 모델링도메인은 고객의 비즈니스 영역 혹은 IT로 구현하고자 하는 서비스 전체를 개발 관점에서 부르는

표현이다. 또한 모델링이라는 표현은 현실 세계의 업무를 컴퓨터가 수행할 수 있는 형태로 재구성하는

과정을 말한다.

인터뷰 실시

기획자와 함께 고객의 요구사항을 듣거나 고객 측 시스템 관리자와 개별 면담을 추진하며, 고객이

목표하는 시스템의 기능, 성능, 보안 등 제반 규격 및 희망 수준을 파악한다. ‘요구명세서’를 작성해야

하지만 기획자에 의해 작성되는 요구분석서 혹은 회의록으로 대체할 수 있다면 따로 작성하지 않는다.

개발 가이드 정의

개발 가이드에 포함되는 문서는 코딩 규칙(coding rule), 용어사전(dictionary), 데이터베이스 설계 지침

(database design guide), 명명 규칙(naming rule), 코드 설계 규칙(code design guide) 등이며, 표준 문서를

기초하되 고객과 협의하여 보완하도록 한다. 예를 들어, 용어 사전의 경우는 업무 성격에 따라 추가해야 할

단어가 다수 발생하고, 고객 자체 규정을 포함시켜야 하는 경우도 있다 또한, 데이터베이스 설계 지침은

기업마다 고유한 문화가 있기 때문에 사전 점검이 필수 사항이다.

15 / 27

비즈니스 역할(role) 이해

UML 모델링의 산출물인 롤 액티비티 다이어그램(role activity diagram)을 작성하는 단계이며, 업무 흐름을

플로우차트(flow chart)로 표현하되 업무 주체(고객, 업무 담당자 등)를 기준으로 각 주체간의 관계와

흐름을 파악하는 작업이다. 다이어그램을 작성할 때는 개발팀 단독으로 수행해서는 안되며, 기획자 및

고객과 함께 회의를 통해 정립하여야 한다. 또한 회의를 마치고 다이어그램을 그리지 말고 화이트보드

등을 이용해 회의 진행 중에 완성하는 것을 목표로 삼아야 한다.

비즈니스 객체 도출

롤 액티비티 다이어그램으로부터 개념적인 클래스들을 추출한 후, 개념적 클래스 다이어그램을 작성한다.

이 단계에서는 비즈니스를 소프트웨어 형태로 추상화 하는 초기 단계이므로 세밀하게 클래스(개체)를

검증할 필요는 없다. 비즈니스 객체 도출 단계에서 추출(혹은 추정)된 클래스가 정확히 구현 단계에서도

존재해야 한다는 법칙은 없다는 것이다. 고객의 요구 혹은 현행(as is) 업무를 정확히 이해한 것인지를

파악하고, 다음 단계에서 컴포넌트 혹은 어플리케이션으로 구현해야 하는 범위(혹은 규모)를 대략적으로

추정하기 위한 기초 준비인 것이다.

3.1.2 요구사항 정의비즈니스 모델링 단계에서 도메인 모델링 단계와 요구사항 정의 단계의 차이는 고객의 요구를 단지

이해하고 정리하는 수준인가 아니면 PM 혹은 아키텍트가 이해한 것을 소프트웨어 관점에서 다시

재구성해 보는 것인가라는 차이를 가지고 있다. 달리 말하자면, 요구사항 정의 단계에서는 고객이

구상하고 있는 프로젝트 결과를 그려보고, 설계자와 함께 확인하는 것에 주안점을 두어야 한다. 여기서

중요한 것은 단지 보고서로의 산출물을 작성해서는 안되며 산출물을 만드는 과정에서 고객과 능동적인

협력과 상호 이해를 추구해야 한다는 것이다.

유즈케이스 모델링

엄밀히 절차를 정의하자면, 유즈케이스 모델링 이전에 요구사항 정의서를 작성하여야 하나, 기획자가

참여하는 프로젝트인 경우는 기획자 작성한 요구사항 정의서를 기반으로 개발 PL 혹은 아키텍트가

유즈케이스 모델링을 수행한다.

유즈케이스 디스크립션

유즈케이스 다이어그램은 매우 추상적인 문서이기 때문에 고객의 요구를 제대로 표현하지 못하게 된다.

따라서, 유즈케이스에 대한 설명을 별도의 문서 혹은 유즈케이스 문서 자체에 추가하게 된다. 참고로

유즈케이스 디스크립션의 서식은 정해진 바가 없기 때문에 자유롭게 작성해도 무방하다.

UI Prototyping고객이 구상하거나 요구하는 사용자 인터페이스 화면을 요구사항 정의 단계에서 협의할 수도 있다.

그러나, 모든 프로젝트에서 제안서 작성 및 시안(디자인 시안)을 통해 사용자 인터페이스에 대한 초기

구상을 실시하므로, 분석 설계에서의 UI prototyping은 생략 가능하다. 다만 브레인스토밍(brain storming)은

지속적으로 진행되어야 하고, 설계 단계에서 작성되는 스토리보드(storyboard)에서 정확히 묘사하게 된다.

16 / 27

3.2 아키텍쳐링 (architecturing)아키텍쳐링은 엄밀히 말하자면 설계 단계의 일부라고 할 수 있다. 하지만, 세부적인 설계를 진행하기

이전에 골격을 정의하고 핵심적인 부분을 먼저 검토하는 것이다. 이러한 단계를 진행함으로써 목표

시스템에서 가장 중요하고 핵심적인 부분에 대해 충분히 검토할 시간을 가질 수 있다는 장점이 있다. 또한,

단 한번의 설계를 수행할 때 발생할 수 있는 오류를 두 번째 설계 단계에서 제거(filtering)할 수 있다.

3.2.1 아키텍쳐 정의소프트웨어 아키텍쳐 정의

전체 소프트웨어의 계층 구조 및 논리, 물리 구조를 다이어그램으로 작성한다. 계층 구조(layer)는 서버

상의 서비스와 사용자가 연결되기 위해서 몇 개의 계층(단계)을 필요로 하는지 가장 단순하고 추상적으로

묘사한다. 논리적 구조는 앞서 기술된 계층 구조 내에 포함된 각종 소프트웨어 모듈들의 명칭을 보다

상세하고 명확하게 기술한다. 최종적으로 논리적 구조에서 묘사된 모듈들이 어떤 하드웨어 상에서

동작하는지를 표현하는 것이 물리적 구조도 이다.

테크니컬 아키텍쳐 정의

기술적 아키텍쳐 정의는 논리적 아키텍쳐 다이어그램을 좀 약간 다른 관점에서 기술하는 것이다. 논리적

단계에서는 각 소프트웨어 모듈의 명칭을 기술하지만, 테크니컬 아키텍쳐 다이어그램에서는 각

소프트웨어 모듈의 분류(category) 혹은 기술 정의를 묘사한다. 이를 통해, 향후 성능 향상 등을 위한

소프트웨어 재설계 혹은 특정 모듈을 교체해야 하는 상황에 빠르고 유연하게 대처할 수 있게 된다.

데이터 아키텍쳐 정의

사용자 요구사항을 정의하는 단계를 거치게 되면 시스템에서 가장 중요하게 관리되어야 할 정보들이

무엇인지를 파악할 수 있게 된다. 쇼핑몰을 예로 들자면, 고객 신상 정보와 상품 정보 그리고, 거래 내역

등을 중요한 요소라고 볼 수 있다. 이러한 단위 정보들의 내역과 각 정보 간의 관계를 개략적으로 정의해야

하며, 간단한 ERD(개념 및 논리적 데이터베이스 모델) 를 작성하게 된다.

3.2.2 컴포넌트 추출기업의 비즈니스 노하우를 구체화한 프로그램의 재사용성을 높이고, 대용량 서비스를 분산 환경으로

구축하는데 있어서 핵심 기능을 부품화(혹은 컴포넌트화) 하는 것은 피할 수 없는 선택이다. 또한

컴포넌트들은 비즈니스에서 가장 중요한 요소(제반 규정 및 처리 과정)를 담고 있기 때문에 컴포넌트의

완성도가 시스템 전체의 완성도에 직접적이며 중대한 영향을 미치게 되는 것이다. 따라서, 컴포넌트 추출

과정은 아키텍쳐링에서도 독립된 단계로서 분리되어 있다.

컴포넌트 식별

컴포넌트를 식별하기 위해서는 요구분석서, 유즈케이스 모델링, 롤 액티비티 다이어그램을 참고하여 업무

흐름 중에서 가장 빈번하게 활용되며, 규칙의 변화 가능성이 적고, 사용자 인터페이스와의 연관성이 적은

17 / 27

기능 요소를 추출한다. 또한, 해당 기능이 타 기능과 독립적으로 동작할 수 있는가 여부를 판단해야 하는데,

가급적 개별 컴포넌트는 다른 컴포넌트의 설계 변화에 영향을 받지 않아야 한다. 사용자 인터페이스 역시

컴포넌트의 후보가 될 수는 있지만, 트렌드(유행)의 변화 혹은 서비스 환경의 변화(모바일 환경의 도래)

등으로 변화 가능성이 높기 때문에 컴포넌트 구축 대상으로 삼지 않는다. 컴포넌트 내역을 추출한 후에는

컴포넌트 내역서를 작성하여 산출물로 남겨야 한다.

컴포넌트 아키텍쳐 정의

컴포넌트라는 것은 독립적인 소프트웨어 부품으로서 교체 가능한 것이나, 부품이라는 태생적인 특성

때문에 단독으로 서비스(동작) 되지는 못한다. 따라서, 여러 컴포넌트가 어떻게 조합되어 동작할 것인지

이해할 수 있는 설계 문서가 필요하다. 이러한 요구를 충족시킬 수 있는 것이 컴포넌트 아키텍쳐

다이어그램이다. 컴포넌트 아키텍쳐 다이어그램에서는 각 컴포넌트 간의 관계를 가급적 실행 시점에서

묘사해야 한다. 달리 말하자면, 컴포넌트의 인스턴스(instance) 간의 관계도를 작성해야 한다.

컴포넌트 사양서

개별 컴포넌트가 가지는 기능 내역, 입력과 출력, 그리고 구현 시 고려해야 하는 각종 제약 사항들을 정의한

것이 컴포넌트 사양서이다. 다만, 아키텍쳐링 단계에서는 명확하고 변경이 불가능한 최종 요구사항을

표현할 필요는 없다. 자칫 요구분석 단계에서 지나치게 오랜 시간을 허비하게 되면 설계에 필요한 시간을

빼앗길 것이기 때문이다. 더불어 소프트웨어 설계 및 구현은 한번에 완벽히 끝내는 것보다 조금씩 여러

단계에 걸쳐서 개선하는 것이 능률적이다.

3.3 시스템 설계

3.3.1 컴포넌트 상세 설계인터페이스 설계

인터페이스 설계는 구현 이전과 이후 단계를 연결하는 징검다리와 같은 것이다. 인터페이스 이전의 설계는

소프트웨어 설계라고 할 수 없는 상태이므로 개발자가 자칫 오해하거나 아예 다시 구조를 떠올려야만

한다. 인터페이스 설계 시에는 컴포넌트에 포함되어야 하는 기능에 대한 명칭과 입출력 항목을 정의한다.

이로서 개발자는 주어진 틀 안에 자신의 기술로 실제 동작하는 코드를 삽입하게 되며, 설계자는 각기 다른

컴포넌트들이 상호 결합하고, 정확히 연동하게 될 것을 확신할 수 있게 된다.

3.3.2 컴포넌트 상세화컴포넌트 정적설계

컴포넌트 내외부에서 필요로 하는 각종 클래스를 정의하며, 각 클래스의 속성과 클래스 간의 관계를

정의한다. 컴포넌트들을 포함하는 클래스 다이어그램을 작성한다.

컴포넌트 동적설계

클래스가 동작하는 과정과 타 객체와의 협동 관계를 표현한다. 컴포넌트들이 시퀀스 다이어그램을

작성하는 단계이다.

18 / 27

3.3.3 유즈케이스 상세화유즈케이스 정적설계

프로그램으로 구현해야 할 클래스들을 구체적으로 추출하며, 필요하다면 디자인 패턴 등의 기법을

적용하여 클래스의 분리, 합성, 재구성 등의 과정을 거친다. 결과물로서 각 클래스간의 관계를 표현한

클래스 다이어그램을 작성한다.

유즈케이스 동적설계

유즈케이스에서 개략적으로 표현된 업무를 보다 상세히 그려나가며, 중요한 객체들이 연결되어 동작하는

방식을 시각적으로 표현하는데 시퀀스 다이어그램을 작성한다.

데이터베이스 설계

데이터베이스 객체를 보다 구체적이며 세부적으로 정의하는 단계로서 논리적, 물리적 데이터베이스

설계를 진행한다. 이 단계에서는 ERD, 테이블 목록서, 테이블 정의서 등의 산출물을 작성한다.

3.3.4 화면 설계UI 상세 설계

사용자 인터페이스 설계는 기획자가 작성하는 화면 스토리보드(screen story board)로 대체 가능하다. 다만,

스토리보드 만으로는 이해할 수 없거나, 동적인 요소를 포함시켜야 할 경우에는 사전 개발(prototyping)을

통해 사용자 인터페이스를 검토한다.

3.4 시스템 구현

3.4.1 어플리케이션 구현어플리케이션 구현 단계에서는 컴포넌트 구현, 사용자 인터페이스 구현, 어플리케이션 클래스 구현,

컴포넌트 조립과 단위 테스트가 진행된다. 단위 테스트 이외의 작업 단계에서의 산출물은 소스

프로그램이다.

컴포넌트 구현

요구분석 및 설계 단계에서 도출된 컴포넌트를 구현 한다. 구현 시에 유의해야 할 점은 설계가 늘 정확할

수는 없다는 점을 상기해야 한다는 점이다. 구현 초기 단계에서 설계의 문제점을 파악하고 수정할 수

있다면 이후에 발견하는 것에 비해 수정에 따르는 비용이 몇 배로 감소하게 된다. 따라서, 가능하다면 구현

단계 이전(설계 혹은 분석 단계)에서부터 컴포넌트 구현을 시도하는 것(prototyping)을 권장한다. 시간이

부족하다면 구현 단계에서 가장 먼저 실행해야만 한다.

컴포넌트 조립컴포넌트가 독립적인 기능을 수행하나 단독으로 실행되어서는 의미 있는 결과를 얻어낼 수 없다. 자동차의

부품이 개별적으로 존재해서는 자동차라는 기능을 수행할 수 없는 것과 일맥상통한다. 따라서, 개별적으로

19 / 27

제작된 컴포넌트들이 상호 관계를 맺고 함께 동작하여 보다 복잡한 기능을 수행할 수 있도록 해야 한다.

일반적으로 어플리케이션 클래스가 컴포넌트들을 조립하는 역할을 수행한다. 컴포넌트를 제작하는 것은

모든 개발자의 역할이지만, 컴포넌트를 조립하는 작업에 대한 책임은 숙련될 개발자 혹은 개발 리더가

맡도록 해야 한다. 가급적 컴포넌트 조립은 어플리케이션 구현을 진행하는 단계 초반에 진행하여 리스크를

줄이도록 한다. 또한, 어플리케이션 기능 중 가장 구현 시간이 짧고 단순한 부분을 선택하여 가조립을

수행하는 것도 좋은 방안이다.

User Interface 구현

웹에서 사용자 인터페이스는 JSP, Flash, HTML 등으로 제작된다. 제작 프로세스에서 사용자 인터페이스를

설계하고 구현하는 작업은 퍼블리싱 팀에서 주도하게 되며, 퍼블리싱 팀에서 수용할 수 없는 인터페이스가

있다면 개발 단계 이전에 사전협의 하는 것을 원칙으로 한다. 개발 작업에 있어서 사용자 인터페이스와

비즈니스 로직은 항상 분리되도록 구현해야 한다.

어플리케이션 클래스 구현

컴포넌트가 재사용되는 독립된 기능 모듈이라면 어플리케이션 클래스는 특정 기능을 수행하기 위한

목적으로 고도의 설계를 따르지 않고 빠르게 제작하는 모듈이라고 보면 되겠다. 프로그램 개발에 있어서

모순된 가치이지만 정확도와 생산성은 양립 되어야 한다. 이러한 목표를 실현하기 위해서 지적 자산에

해당하는 컴포넌트는 고도의 설계를 거치지만, 재사용될 가능성이 거의 없는 어플리케이션 클래스는

최대한 단순하게 개발하는 것을 원칙으로 한다.

단위 테스트

단위 테스트는 개별 개발자가 제작한 기능, 메뉴 혹은 모듈 단위로 테스트 하는 것을 의미한다. 전체 시스템

흐름에 구애 받지 않고, 특정 화면(혹은 기능)의 형태나 입출력 값, 처리 결과 메시지 등 각 프로그램 설계

시에 요구되는 기준을 정확히 준수하는지 여부를 검증하는 것이다. 단위 테스트는 개발자와 테스터(혹은

기획자)가 함께 진행하며, 발견된 오류는 즉시 수정해야 하는 것을 원칙으로 한다. 단위 테스트 기간 내에

발견된 오류를 모두 수정되지 않으면 개발 단계가 완료된 것으로 보지 않는 것이 원칙이다.

3.4.2 테스트통합 테스트

통합테스트는 시스템 전체의 기능을 종합적으로 확인하는 시나리오를 작성한 후, 모든 단위 기능들이

정상적이며 조화롭게 상호동작 하는지 여부를 테스트 하는 것이다. 단위 테스트가 정상적으로 수행되었을

지라도 각 단위 모듈에서 출력된 자료가 다음 단위 모듈의 입력으로 받아들여지지 않거나, 여러 단계를

거치면서 잘못된 결과를 출력하는 경우가 발생할 수 있기 때문이다. 사전에 계획된 시나리오에 따라

고객이 테스트를 진행하며 통합테스트 결과서를 산출물로 작성한다. 대규모 시스템이며, 테스트 가용

인력이 많은 경우에는 사용자 그룹 일부가 동시에 운영 시스템에 접근하여 모의 수행해보는 몹 테스트

(mob test)를 수행하는 경우도 있다.

20 / 27

시스템 테스트

일반적으로 프로젝트 진행 단계에서의 테스트는 개발 환경(혹은 서버)에서 수행된다. 개발을 마치고 운영

시스템에 프로젝트 수행 결과를 시범 탑재한 후 서비스 성능과 각종 소프트웨어, 하드웨어의 충돌 여부 및

오동작 여부, 응답 속도 등을 점검하는 것을 시스템 테스트라고 한다. 세부적인 테스트 항목과 절차는

프로젝트 규모 및 일정에 따라 달라지므로 구체적인 업무 진행 방법은 고객과의 협의를 통해 결정하여야

한다.

3.5 배치 (deploy)배치란 개발이 완료된 후에 개발 시스템에 탑재된 어플리케이션을 운영 서버에 설치하는 과정이다. 또한

설치한 시스템의 정상동작 여부와 서비스 운영을 위한 준비를 마치는 단계이며, 그 결과를 최종적으로

고객에게 확인 받는 과정이다.

3.5.1 시스템 릴리즈인수 테스트

이전 단계까지의 테스트는 개발자 혹은 기획자가 프로젝트팀 내부에서 자체 테스트하는 방법이며, ‘인수

테스트’ 단계에서는 시스템 운영 담당자(혹은 고객 전체)가 인수 및 운영을 위한 체크 항목을 정의한 후

점검한다. 즉, 인수 테스트의 주체는 고객 혹은 최종 시스템 사용자다. 인수 테스트의 구체적 방법과 절차는

고객과 협의하여 결정하도록 한다.

3.5.2 사용자 교육고객 교육

시스템의 정상적인 운영을 위해 서비스 환경, 관리자 도구 사용법, 방법론 및 각종 Q&A 등의 문서를

고객측에 제출하며, 필요하다면 일정 시간 고객을 상대로 기술 이전 교육을 실시한다. 이 단계의 산출물과

수행 업무 내역은 프로젝트 수행 기간과 고객의 요구, 프로젝트 상황 등을 다각적으로 고려한 후 결정한다.

4. 개발 업무 세부지침

4.1 상세 업무 및 산출물 정의

4.1.1 대규모 프로젝트대규모 프로젝트를 수행할 경우에는 다음과 같은 업무 수순을 따라 진행하며, 각 단계별 수행 결과에 따른

산출물을 작성해야 한다. 다만, 프로젝트 사양(인력 및 기간)에 따라 고객과의 협의를 거쳐 일정 부분을

제외할 수 있다.

[ Table 1 ] 대규모 프로젝트 단계별 업무 및 산출물 정의

단계 세부 단계 상세 업무 산출물 비고

21 / 27

비즈니스 모델링

도메인 모델링 인터뷰 실시시스템 환경 정의개발 표준 정의

용어 사전코딩 및 명명 규칙시스템 환경 정의서시스템 설치 매뉴얼개발 가이드

인터뷰 실시 결과 문제기술서는 기획팀 작성

비즈니스 역할 이해 롤 액티비티 다이어그램

비즈니스 객체 도출 개념 클래스 다이어그램

요구사항 정의 유즈케이스 모델링 유즈케이스유즈케이스 명세서

요구사항 정의서는 기획팀 작성

UI prototyping UI prototype 옵션 사항

아키텍쳐링 아키텍쳐 정의 S/W 아키텍쳐 정의시스템 개발 환경 설정

S/W 아키텍쳐 다이어그램(layer, logical , physical)

기술 아키텍쳐 정의 기술 아키텍쳐 다이어그램

데이터 아키텍쳐 정의 개념적 ERD

컴포넌트 추출 컴포넌트 식별 컴포넌트 목록

컴포넌트 아키텍쳐 정의 컴포넌트 아키텍쳐 다이어그램

컴포넌트 정의 컴포넌트 사양서

설계 컴포넌트 상세설계

인터페이스 설계 인터페이스 목록 JavaDoc으로 대체 가능

컴포넌트 구체화

컴포넌트 정적분석 클래스 다이어그램

컴포넌트 동적분석 시퀀스 다이어그램

컴포넌트 데이터 모델링

데이베이스 설계 논리적 ERD

어플리케이션 유즈케이스 상세화

유즈케이스 정적설계 클래스 다이어그램

유즈케이스 동적설계 시퀀스 다이어그램

데이터베이스 설계 물리적 ERD테이블 목록테이블 정의서Stored Procedure 정의서DB 생성 스크립트일괄 작업 정의서백업정의서코드, 권한 명세서

화면 설계 UI 상세 설계 스토리 보드 기획팀 작성

구현 어플리케이션 구현

컴포넌트 구현UI 구현어플리케이션 구현컴포넌트 조립

소스 코드 Version Control System을 이용해 형상관리 해야 함

단위 테스트 단위 테스트 결과서 Bug-Tracking System으로 대체 가능

테스트 통합 테스트 통합 테스트 결과서

시스템 테스트 시스템 테스트 결과서

배치 시스템 릴리즈 인수 테스트 시스템 설치 명세서인수 테스트 결과서

22 / 27

사용자 교육 고객 교육 장애 조치 가이드고객 교육 결과서

4.1.2 중소규모 프로젝트중소규모 프로젝트 혹은 기존에 구축된 사례를 활용하여 개발 기간을 단축하는 프로젝트인 경우에는 좀 더

축약된 업무를 수행하며, 그에 따른 산출물을 작성하면 된다.

[ Table 2 ] 중소규모 프로젝트 단계별 업무 및 산출물 정의

단계 세부 단계 상세 업무 산출물 비고

비즈니스 모델링

도메인 모델링 인터뷰 실시시스템 환경 정의개발 표준 정의

용어 사전코딩 및 명명 규칙시스템 환경 정의서시스템 설치 매뉴얼개발 가이드

인터뷰 실시 결과 문제기술서는 기획팀 작성

비즈니스 역할 이해 롤 액티비티 다이어그램 생략 가능

요구사항 정의 유즈케이스 모델링 유즈케이스유즈케이스 명세서

요구사항 정의서는 기획팀 작성

UI prototyping UI prototype 옵션 사항

아키텍쳐링 아키텍쳐 정의 S/W 아키텍쳐 정의시스템 개발 환경 설정

S/W 물리적 아키텍쳐 다이어그램

컴포넌트 추출 컴포넌트 식별 컴포넌트 목록 생략 가능

컴포넌트 정의 컴포넌트 사양서 생략 가능

설계 컴포넌트 상세설계

인터페이스 설계 인터페이스 목록 JavaDoc으로 대체 가능

어플리케이션 유즈케이스 상세화

유즈케이스 정적설계 클래스 다이어그램 생략 가능

유즈케이스 동적설계 시퀀스 다이어그램 생략 가능

데이터베이스 설계 물리적 ERD테이블 목록테이블 정의서DB 생성 스크립트

화면 설계 UI 상세 설계 스토리 보드 기획팀 작성

구현 어플리케이션 구현

컴포넌트 구현UI 구현어플리케이션 구현

소스 코드 Version Control System을 이용해 형상관리 해야 함

단위 테스트 단위 테스트 결과서 Bug-Tracking System으로 대체

테스트 통합 테스트 통합 테스트 결과서

배치 시스템 릴리즈 인수 테스트 인수 테스트 결과서

사용자 교육 고객 교육 고객 교육 결과서

4.2 산출물 작성 지침각 단계별 산출물을 작성하는데 있어서 주의가 필요한 부분에 대한 세부 지침을 제공한다. 아래 기술한

23 / 27

모든 내용을 필수적으로 작성할 필요는 없다. 다만, 아래와 같은 사항을 꼼꼼히 확인할수록 시행착오를

줄일 수 있게 된다. 매번 프로젝트를 수행할 때마다 전부 다시 작성할 필요는 없으며 가급적 이전

프로젝트의 산출물을 재가공해서 사용할 것을 권장한다.

4.2.1 비즈니스 모델링

용어사전 (glossary)개발 관련 용어 뿐만 아니라, 비즈니스 상의 용어들을 포함시켜야 한다. 예를 들어, 고객에 대한 정의를

내릴 경우에도 프로젝트 범위에 따라 가맹점 고객, 일반 고객, 우수 고객 등 다양한 분류가 필요한 사이트가

있기 마련이다. 또한, 일상적으로 사용하는 용어라고 할지라도 고객의 업무에 따라 구체적인 의미가

달라지는 경우가 발생한다. ‘금액’이라는 표현을 들어보자면 ‘단가’, ‘총액’, ‘원가’ 등 세분화될 수 있기

때문이다. 용어를 정의하면서 각 용어를 영어 단어로 어떻게 표현할지도 기준을 정해야만 설계 및 구현

단계에서의 혼란을 방지할 수 있다.

코딩 및 명명 규칙변수 명칭, 클래스 명칭, 테이블 명칭 등 다양한 요소에 대한 명명 규칙도 개별 고객마다 조금씩 다른데

이것은 각 고객사의 문화와 관습이 담겨 있기 때문이다. 고객이 특별히 요구하지 않을 경우에는 프로젝트

별로 고유 규칙을 적용하도록 한다. 또한 외부 업체와 컨소시엄으로 개발할 경우에도 외부 개발팀장과의

협의를 거쳐 규칙을 조정하도록 한다.

시스템 환경 정의서

시스템 환경 정의서에 포함시켜야 하는 내용은 다음과 같다. 일정 부분은 고객에게 정보를 요청하여 좀 더

정확한 정보를 획득 할 수 있다. 다만, 개별 프로젝트 상황에 따라 세부항목은 조절 가능하다.

하드웨어 구성도 및 사양

하드웨어 구성도

하드웨어 사양 (벤더 및 모델, 성능 정보, 제약 사항 등)

네트워크 구성도 및 보안체제

네트워크 구성도

네트워크 성능, 부하 분산 체계, 방화벽 및 보안 서버 구성,서버 간 자료 교환 체제 (NAS, FTP 등), 도메인 주소 정의 등

소프트웨어 구성도

현행 서버 소프트웨어 탑재 내역

서버 소프트웨어 및 버전, 디렉토리 위치, 계정 정보, 쉘 프로그램 정보 등

24 / 27

시스템 설치 매뉴얼개발 및 운영 시스템에 설치되는 각종 소프트웨어의 설치 매뉴얼을 확보해두는 것은 개발 완료 후 운영

시스템 설치에 큰 도움이 되며, 각 서버(혹은 어플리케이션) 설정 파일을 문서화 하거나 백업하게 되면,

만약에 따른 불상사에 손쉽게 대처할 수 있게 된다.

서버 프로그램 설치 매뉴얼

웹 서버 (Tomcat, Apache), 미들웨어 (JEUS, WebLogic), 데이터베이스 (Oracle, MS-SQL), 개발 언어 및 컴파일러 (JDK), 버전 관리 툴 (CVS), 버그 추적 시스템 (Bugzilla, Mantis, Scarab), 자동화 툴(Ant, JUnit, CruiseControl), 서드 파티 라이브러리(Xerces, Apache commons, etc) 등

환경 설정 가이드

위와 같은 소프트웨어들의 설치 내역 및 버전, 디렉토리 위치, 계정 정보, 쉘 설정 정보, 환경 설정

파일 등

개발 및 운영 환경 가이드

개발 가이드에서는 가급적 시스템의 제약 사항(한계)을 명시해야 한다. 시스템을 개발할 때는 특정

서비스환경에 최적화 시켜 개발하는 것이 일반적이며, 달리 말하자면 변화를 완벽히 소화할 수 있는

시스템을 만드는 것은 불가능하다. 따라서, 시스템을 개발하는 과정에서 어느 정도 수준의 기능과 품질을

준수할 것인지에 대한 기준으로 활용할 수 있는 정보 및 향후 시스템을 업그레이드 혹은 재개발 여부를

결정할 수 있는 근거 자료를 제공해야 한다. 이와 같은 정보는 가능하다면 고객이 작성하여야 한다.

개발 가이드

허용된 개발 방법 및 서버 접근 방법, 개발 시 고려사항(DB 연결 방법, 쿠키 허용 여부, 개인 정보

암호화 여부), 해킹 방어 방안 등

사용자 환경 정의

운영체제, 웹 브라우저 버전, 클라이언트 프로그램 설치 내역, 실행 시 제약 사항 등

관리자 환경 정의

네트워크 제한 요소, 로그인 제한 방법 등

4.2.2 아키텍쳐링S/.W 아키텍쳐 다이어그램

소프트웨어 아키텍쳐 다이어그램은 일반적으로 3가지 구성으로 나뉠 수 있다. 시스템 구조가 복잡한

경우에는 3가지 모두를 표현하지만, 하드웨어 구성도 만으로도 충분히 이해할 수 있을 정도로 단순할

25 / 27

경우에는 생략해도 무방하다.

S/W layer architecture diagram웹 운영환경을 구성하는 가장 단순한 방법은 웹 컨테이너와 데이터베이스를 연결하는 2계층

구조이지만, 성능 향상 및 부하 분산을 위해 미들웨어를 포함하게 되면 3계층 이상의 구조로

설계한다. 3계층 이상으로 구성될 경우에는 레이어 아키텍쳐 다이어그램으로 단순하게 묘사하여

시스템에 대한 이해를 돕는다.

S/W logical architecture diagram논리적 아키텍쳐 다이어그램은 서버 소프트웨어 간 혹은 서버와 클라이언트 소프트웨어 간의

의존 관계와 통신 방법을 묘사한 것이다.

S/W physical architecture diagram물리적 아키텍쳐 다이어그램은 각 서버 소프트웨어가 어떤 하드웨어에 탑재되어 있는지 묘사하는

것이다. 2대 이상의 서버를 이용해 구축할 경우에 그리게 된다.

기술 아키텍쳐 다이어그램

복잡한 시스템을 구축할 경우에는 다양한 기술을 접목하여 설계 및 운영하게 된다. 시스템을 구축함에

있어서 사용된 모든 유형의 기술들을 하나의 도표에 일목요연하게 묘사하는 것을 테크니컬 아키텍쳐

다이어그램이라고 한다.

개념적 ERD개념적 개체 관계 모델은 데이터베이스를 구성하는 개체(테이블)과 각 개체 간의 관계를 묘사한 것이다. 각

개체의 명칭은 비즈니스에서 사용되는 명칭 그대로 가급적 한글로 묘사하며, 세부적인 속성(컬럼)은

묘사하지 않아도 된다. 또한, 각 개체관계 관계를 묘사함에 있어서도 세밀하게 표현하지 않는다.

4.2.3 설계물리적 ERD개념적 모델을 좀 더 정확하게 표현한 단계이며, 각 개체의 명칭은 영문으로 변환하여 묘사한다. 또한 주요

키와 외부 키를 정의하고, 세부 속성을 기입하게 된다. 다만, 물리적 ERD에서는 DB 종류와 버전에

종속되지 않도록 작성할 것을 권장한다.

DB 생성 스크립트

사용자 생성 스크립트, 물리적 테이블 스페이스 정의, 저장 프로시져, 트리거, 테이블 생성 스크립트 등

데이터베이스 구축에 필요한 모든 객체에 대한 선언을 포함해야 하며, DB 생성 스크립트를 이용해 운영 및

테스트 데이터베이스를 초기화 할 수 있어야 한다. 따라서, 기본 데이터(코드 정도) 생성 스크립트(insert

query)를 포함해야 한다.

26 / 27

4.2.4 구현단위 테스트 결과서

단위 테스트 결과서는 워드나 엑셀로 작성하기 보다는 버그 추적 시스템을 통해 자동 생성되는 리포트를

사용할 것을 권장한다. 프로젝트 규모가 작거나, 버그 추적 시스템 활용에 익숙하지 않을 경우에는 단위

테스트 문서를 엑셀로 작성한다.

4.2.5 배치

장애 조치 가이드

서버 중단, 실행 오류 등이 발생했을 경우에 서버 상의 어느 위치에서 장애 로그 정보를 확인할 수 있는지

여부와 오류 유형에 따른 조치 방안을 간략히 서술하여, 예측할 수 없는 장애에 대한 대응 시나리오를

제공한다.

4.3 UML 적용 방안

4.3.1 UML 요약UML(Unified Modeling Language)은 소프트웨어의 구조를 도식화하여 표현하는 표기법으로서 소프트웨어

설계도를 그리는 규칙이라고 할 수 있다. 언어라는 표현을 사용하고 있기는 하지만, 소프트웨어를 ‘제작’

하기 위한 것이 아니라, ‘설계’하기 위한 언어라는 점에 주목해야만 한다. 따라서, UML은 개발자들만을

위한 도구가 아니라, 설계자 혹은 설계를 이해해야 하는 사람들 모두(개발자, 기획자, 고객)를 위한

표기법이라고 할 수 있다.

소프트웨어를 제작한다는 것은 현실 세계의 비즈니스를 시스템화 하는 것이기 때문에 그 전환 과정을

묘사할 방법이 필요한 것이다. 달리 말해서, 현실과 시스템의 중간 지점이라고 이해하는 것이 좋겠다.

따라서, 어찌 보면 개발자와 기획자 모두에게 생소하게 여겨질 수 있다. 하지만, 사용자의 요구를 개발자

혹은 설계자가 정확히 이해했는지 여부를 확인하지 않고 개발을 수행한다는 것은 그만큼 위험을 감수해야

한다는 것을 의미하기도 한다. 따라서, 완벽하지 않을지라도 개발에 착수하기에 앞서 UML을 이용해

설계를 진행하는 것은 프로젝트의 성공 가능성을 높이는 매우 중요한 절차라고 할 수 있다.

UML은 소프트웨어 설계의 3대 대가인 ‘제임스 럼바’, ‘이바 야곱슨’, ‘그래디 부치’가 독자적으로 연구하던

설계 방법론을 통합하였기 때문에 유래한 명칭이며, 1997년 객체기술 표준화 단체인 OMG에 의해서

표준으로 인정 받았다. 객체지향 개발을 진행하는데 있어서 UML은 가장 널리 쓰이는 표준이므로, 개발

절차에 도입하였으며, 문서에서 명시한 대부분의 다이어그램들은 UML의 일부이다.

27 / 27