mecㆍviewer v1.4 :: lm2001020221_애플리케이션+설계.pdf

대분류/20
정보통신

중분류/01
정보기술

소분류/02
정보기술개발

세분류/02
응용SW엔지니어링

능력단위/21

NCS학습모듈

애플리케이션 설계

LM2001020221_16v4

[NCS-학습모듈의 위치]

대분류

정보 통신

중분류

정보 기술

소분류

정보 기술 개발

세분류

SW아키텍처

능력단위

학습모듈명

응용SW
엔지니어링

요구사항 확인

임베디드SW
엔지니어링

데이터 입출력 구현

DB엔지니어링

통합 구현

NW엔지니어링

정보시스템 이행

보안엔지니어링

제품소프트웨어 패키징

UI/UX엔지니어링

서버프로그램 구현

시스템SW
엔지니어링

인터페이스 구현

빅데이터
플랫폼구축

애플리케이션 배포

핀테크
엔지니어링

프로그래밍 언어 활용

데이터아키텍트

응용 SW 기초 기술 활용

애플리케이션 리팩토링

인터페이스 설계

애플리케이션 요구사항 분석

기능 모델링

애플리케이션 설계

정적모델 설계

동적모델 설계

화면 설계

화면 구현

애플리케이션 테스트 관리

애플리케이션 테스트 수행

소프트웨어공학 활용

소프트웨어개발 방법론 활용

차 례

학습모듈의 개요

학습 1. 공통 모듈 설계하기

1-1. 공통 모듈 식별 및 명세

1-2. 공통 모듈 설계

1-3. 공통 모듈 인덱스 및 기능 코드 설계

• 교수・학습 방법

• 평가

학습 2. 타 시스템 연동설계하기

2-1. 아키텍처를 고려한 타 시스템 연동 설계

2-2. 미들웨어 솔루션 명세 작성

2-3. 오류 예측 및 대응방안 제시

• 교수・학습 방법

• 평가

참고 자료

활용 서식

애플리케이션 설계 학습모듈의 개요

학습모듈의 목표

요구사항 확인을 통한 상세 분석 결과, 소프트웨어 아키텍처 가이드라인 및 소프트웨어 아키텍

처 산출물에 의거하여 이에 따른 애플리케이션 구현을 수행하기 위해 공통 모듈 설계, 타 시스

템 연동에 대하여 상세 설계할 수 있다.

선수학습

요구사항 확인(2001020201_16v3), 화면 설계(2001020224_16v4), 인터페이스 구현(2001020212_16v4), 통

합 구현(2001020206_16v4), SW 개발 지원(2001020108_15v3)

학습모듈의 내용체계

학습

학습 내용

NCS 능력단위 요소

코드번호

요소 명칭

1. 공통 모듈

설계하기

1-1. 공통 모듈 식별 및 명세

2001020221_16v4.1

공통 모듈 설계하기

1-2. 공통 모듈 설계

1-3. 공통 모듈 인덱스 및 기능

코드 설계

2. 타 시스템

연동설계하기

2-1. 아키텍처를 고려한 타 시스템

연동 설계

2001020221_16v4.2

타 시스템

연동설계하기

2-2. 미들웨어 솔루션 명세 작성

2-3. 오류 예측 및 대응방안 제시

핵심 용어

공통 모듈, 기능 명세, 화면 설계, 로직 설계, UML, 모듈화, 아키텍처, 시스템 연동, 미들웨어

학습 1 공통 모듈 설계하기

학습 2

타 시스템 연동설계하기

1-1. 공통 모듈 식별 및 명세

학습 목표

• 재사용성 확보와 중복 개발을 회피하기 위하여, 전체 시스템 차원과 단위 시스템 차

원의 공통부분을 식별하여 이에 대한 상세 명세를 작성할 수 있다.

필요 지식 /

 공통 모듈(Module)

1. 모듈의 개념

전체 프로그램의 기능 중 특정 기능을 처리할 수 있는 실행 코드를 의미하며 자체적으로

컴파일 가능하고 다른 프로그램에서 재사용이 가능하다.

2. 공통 모듈

여러 기능 및 프로그램에서 공통적으로 사용할 수 있는 모듈을 의미하며 날짜 처리를 위

한 유틸리티 모듈 등이 해당된다.

3. 공통 모듈에 대한 명세 기법

공통 모듈에 대한 명세를 작성할 때에는 다음의 원칙을 지킨다.

(1) 정확성(Correctness) : 해당 기능이 실제 시스템 구현 시 필요한지 여부를 알 수 있

도록 정확하게 작성한다.

(2) 명확성(Clarity) : 해당 기능에 대해 일관되게 이해되고 한 가지로 해석될 수 있도록

작성한다.

(3) 완전성(Completeness) : 시스템이 구현될 때 필요하고 요구되는 모든 것을 기술한다.

(4) 일관성(Consistency) : 공통 기능들 간에 상호 충돌이 없도록 작성한다.

(5) 추적성(Traceability) : 공통 기능에 대한 요구사항 출처와 관련 시스템 등의 유기적

관계에 대한 식별이 가능하도록 작성한다.

 재사용(Reuse)

개발 시간 및 비용 절감을 위하여 이미 검증된 기능을 파악하고 재구성하여 시스템에 응

용하기 위해 적합하게 최적화시키는 작업이다.

1. 재사용 규모에 따른 분류

분류

내 용

함수와 객체 재사용

클래스나 메소드 단위로 사용하며, 소스 코드 등을 재사용

컴포넌트 재사용

컴포넌트 단위로 재사용하며, 컴포넌트 자체는 수정하지 않고 인터페

이스를 통해 통신

애플리케이션 재사용

공통된 업무가 기능을 제공하도록 구현된 애플리케이션을 공유하여

재사용

<표 1-1> 재사용 규모에 따른 분류

2. 재사용을 위한 필요 항목

(1) 재사용과 관련된 내용이 이해하기 쉽고, 누구나 사용 가능하도록 사용법이 공개되

어야 한다.

(2) 외부 모듈과의 연관성(결합도)은 적어야 하며, 자체적인 완성도(응집도)는 높아야 한다.

 유스케이스(Use Case) 및 관계(포함과 확장)

1. 유스케이스

통합 모델링 언어(UML : Unified Modeling Language)에서 시스템에 제공되는 고유 기능

단위이며, 액터(Actor, 행위자)를 통해 시스템이 수행하는 일의 목표이다.

2. 포함과 확장 관계

유스케이스(Use Case, 사용 사례)의 구성 요소 간 관계에는 연관, 확장, 포함, 일반화, 그

룹화 등이 있으며 기능 수행 시 반드시 포함하거나 선택적으로 수행할 수 있는 관계를 아

래와 같은 점선으로 표시한다.

관계

설명

표시

포함(Include)

시스템의 기능이 별도의 기능을 포함

확장(Extend)

기본 유스케이스 수행 시 특별한 조건을 만족할 때

수행하는 유스케이스

<표 1-2> 유스케이스의 포함과 확장

수행 내용 / 공통 모듈 식별 및 명세하기

재료·자료

• SW 개발 국제 표준(ISO/IEC 9126, ISO/IEC 14598, CMMi 등)

• 소프트웨어 테스트 관련 국제 표준(ISO/IEC 12119)

• 제안 요청서, 제안서, 요구사항 정의서 등의 요구사항 관련 산출물

• 업무 기능 분해도, 업무 배경도, 유스케이스 다이어그램 등의 분석 단계 산출물

• 요구사항 명세서, 유스케이스 명세서와 같은 명세 산출물

기기(장비 ･ 공구)

• 전산 장비(컴퓨터, 프린터, 빔 프로젝터, 네트워크 장비 등)

• OA 도구(워드프로세서, 스프레드시트, 프레젠테이션 도구 등)

• CASE 도구(SW설계 지원 도구, SW 개발 지원 도구, SW 테스트 지원 도구 등)

• UML 저작 도구(오픈 소스 : StarUML)

안전 ･ 유의 사항

• 실험 실습은 정해진 방법과 절차에 따라 실시하여야 한다.

• 요구사항 정의서 등과 같은 분석 단계 산출물에 대한 이해가 필요하다.

• UML 다이어그램의 유형과 작성 방법에 대해 사전 학습한다.

• 단위 시스템 및 전체 시스템에서 제공하는 업무 기능에 대해 파악할 수 있어야 한다.

• 명세 작업을 진행하는 경우 명세의 일관성, 정확성, 완전성에 유의한다.

수행 순서

 전체 시스템 차원과 단위 시스템 차원의 공통부분을 식별한다.

재사용성 확보와 중복 개발 회피를 위하여 전체 시스템 차원과 단위 시스템 차원에서 공

통으로 사용될 기능을 식별한다.

[그림 1-1] 전체 시스템과 단위 시스템 구성 예시

1. 단위 시스템의 업무 기능을 분석하여 공통부분을 식별한다.

업무 기능 분해도 산출물이 존재하는 경우 해당 산출물을 이용하여 단위 시스템 및 전체

시스템에 대한 업무를 정리하여 공통부분을 식별한다.

(1) 업무 기능 정제

업무 기능에 대해 표준 단어와 표준 용어로 작성되었는지 검토 후 프로젝트 표준에

맞게 정제 작업을 진행한다.

(가) 업무 기능에 대한 표준화 검토

표준 용어와 표준 단어로 업무 기능이 기술되었는지 전체 기능에 대해 검토한다.

(나) 업무 기능에 대한 정제

업무 기능에 대한 설명이 표준 용어와 표준 단어로 기술되지 않은 경우 표준에 맞

게 내용을 수정한다.

(2) 업무 기능 누락 및 중복 여부 검토

시스템에 대한 업무가 정의된 업무 기능 분해도를 분석하여 관련 기능이 누락 없이

정의되었는지 검토한다.

(가) 업무 기능 분해도에 누락된 기능이 없는지 검토한다.

(나) 중복으로 작성된 기능이 없는지 검토한다.

(3) 업무 기능 중 공통부분을 식별한다.

업무적으로 중복 단어나 용어를 기준으로 공통으로 처리 가능한 기능을 식별하여 공

통 모듈 후보를 식별한다.

(가) 단위 기능 중 공통으로 사용될 수 있는 기능을 식별하여 후보군으로 선정한다.

(나) 후보군으로 선정된 업무 기능에 대해 공통 모듈로 선정할지 여부에 대해 검토한다.

(다) 공통 모듈로 선정하는 경우 별도의 업무 기능으로 분리한다.

[그림 1-2] 업무 기능 분해도를 통한 공통 기능 식별 예시

2. 유스케이스를 분석하여 공통부분을 식별한다.

분석 단계 산출물인 유스케이스 다이어그램(Use Case Diagram. 사용 사례 다이어그램)을

검토하여 <<include>> 관계로 식별된 기능에 대해 공통 기능으로 적용 가능한지 분석한다.

(1) 유스케이스 다이어그램을 검토하여 <<include>> 관계를 분석한다.

(2) 관련 유스케이스를 공통 기능으로 적용 가능한지 검토한다.

[그림 1-3] 유스케이스를 통한 공통 기능 식별 예시

3. 단위 시스템의 공통부분에 대한 검토 회의를 진행한다.

단위 시스템의 공통부분으로 식별된 기능에 대해 관련 시스템 담당자와 검토 회의를 통하

여 공통화 여부에 대해 확정한다.

(1) 단위 시스템 이해관계자와 검토 일정을 수립한다.

단위 시스템의 업무 선임 개발자 및 주요 개발자를 식별하고, 관련 이해관계자가 함께

회의에 참석할 수 있도록 회의 일정을 수립한다.

(2) 공통 기능에 대한 적용 여부를 검토한다.

업무 기능 분해도 및 유스케이스 분석을 통해 식별된 기능을 공통 기능으로 관리하고,

재사용에 대한 효과성이 높은지에 대해 검토한다.

(3) 공통 기능으로 적용 가능한 다른 기능에 대한 의견을 취합한다.

식별된 기능 이외에 추가적으로 공통화하여 관리함으로써 개발 효율성을 높일 수 있

는 기능이 있는지 의견을 취합한다.

(4) 공통 기능에 대한 담당자를 정의한다.

이해관계자가 합의한 공통 기능에 대한 변경 사항 발생에 대비하여 전체적인 공유 및

이력 관리를 맡을 담당자를 정의한다.

4. 단위 시스템에 대해 공통부분으로 식별된 기능에 대한 상세 기능을 기록한다.

공통 기능으로 관리가 필요한 기능에 대한 관련 기능 및 설명, 입력/출력 항목 등 상세

기능을 정리한다.

항목

설 명

순번

작성 순서를 나타내는 일련번호

기능

공통 기능이 수행하는 내용을 대표적으로 표현할 수 있도록 기술

기능 설명

공통 기능이 수행하는 내용을 업무적인 용어 등으로 상세히 기술

공통 모듈 ID

향후 공통 모듈을 구분할 수 있는 모듈 ID를 부여

관련 코드의 명칭

자릿수

관련 코드의 자릿수(2개 이상 복합일 경우 전체 자릿수)

사용 목적

관련 코드의 사용 방법 및 목적

코드 구조

코드의 항목 구성 및 항목별 내용

비고

추가 기술 사항 및 특이 사항

<표 1-17> 시스템 기능 코드 설계서 작성 항목 및 내용

1. 단위 시스템에 대한 명칭을 확인한다.

제안 요청서, 사업 수행 계획서, 분석/단계 산출물 등을 참고하여 단위 시스템에 대한 정

확한 명칭 및 기능을 확인한다.

2. 단위 시스템별로 대분류를 지정하여 그룹화한다.

단위 시스템의 사용자, 제공 기능, 외부 연계 등을 고려하여 대분류 체계로 단위 시스템의

그룹화 작업을 진행한다.

3. 단위 시스템별로 대분류를 중분류할지 여부에 대해 검토한다.

대분류로 그룹화된 시스템에 대해 중분류 체계를 구성할지에 대해 검토하여 중분류 체계

가 필요한 경우 다시 그룹화 작업을 진행한다.

구분

코드

시스템 영역

대분류

내부 업무를 수행하기 위한 시스템

인터넷을 통해 민원인이 사용하는 시스템

외부 기관과의 연계를 위한 별도 시스템

업무 처리 및 인터넷 서비스 등을 종합적으로 관리하고 지원하는

시스템

중분류

개인과 관련된 정보를 처리하는 시스템

부동산과 관련된 정보를 처리하는 시스템

법인과 관련된 정보를 처리하는 시스템

<표 1-18> 단위 시스템에 대한 대분류/중분류 그룹화 예시

4. 그룹화된 단위 시스템별로 기능 코드 번호를 부여한다.

각 단위 시스템별로 분류 체계를 고려하여 코드를 부여한 후 순차적으로 시스템별 기능

코드 번호를 부여한다.

5. 단위 시스템별 기능 코드 번호에 대한 중복 여부를 확인한다.

각 단위 시스템별로 분류 체계를 고려하여 코드를 부여한 후 순차적으로 시스템별 기능

코드 번호를 부여한다.

[그림 1-22] 단위 시스템 기능 코드 설계서 작성 예시

 전체 시스템 및 단위 시스템별로 공통 모듈에 대한 인덱스를 부여한다.

공통 모듈의 사용 범위에 따라 전체 시스템 혹은 단위 시스템으로 구분하여 순차적으로

인덱스 번호를 부여한다.

1. 인덱스 번호 체계를 수립한다.

(1) 공통 모듈에 대한 접두사(Prefix)를 정의한다.

공통 모듈 그룹을 식별하기 위한 접두사(예시: COM)를 지정한다.

(2) 인덱스 부여 방법을 정의한다.

단위 시스템 코드 및 공통 모듈 그룹 식별 코드, 전체 시스템에 대한 코드와 인덱스

표시 순서 및 자릿수를 정의한다.

(3) 공통 모듈에 대한 시스템 기능 코드 부여 체계를 정리한다.

전체 시스템과 단위 시스템의 구분, 전체 코드의 구성 체계 및 식별 방법에 대해 정리

하여 중복되거나 누락되지 않고 코드가 부여될 수 있도록 한다.

코드명

공통 모듈 식별을 위한 코드

자릿수

10자리

사용 목적

전체 시스템과 단위 시스템의 공통 모듈을 유일하게 식별하기 위한

체계로 재사용 및 공통 모듈 관리를 위해 사용

코드 구조

A(4자리) - COM(고정) - C(숫자3자리)

A(영문 및 숫자 4자리) : 단위 시스템에 대한 기능 코드 4자리

- 전체 시스템 공통의 별도 코드 부여(PJTC : Project Common)

B(영문 3자리) : 공통 모듈 그룹을 구별하기 위한 고정 표시(COM)

C(숫자 3자리) : 시스템별 공통 모듈에 대한 순차적 일련번호(001~999)

예시) PJTC-COM-001(전체 시스템 공통 모듈 중 일련번호 1번)

비고

공통 모듈 추가 및 삭제, 변경 시 관련 모듈 담당자와 협의 필요

<표 1-19> 공통 모듈 식별을 위한 인덱스 부여 체계 예시

2. 공통 모듈 관리 대장에 시스템별로 인덱스를 부여한다.

공통 모듈 관리 대장에 공통 모듈 코드 번호 컬럼(Column, 열)을 추가하고 기존에 식별된

전체/단위 시스템별로 인덱스 부여 체계에 맞게 코드 번호를 부여한다.

순

번

시 스

템

기능

공통 모듈

코드 번호

설명

엔티티

입력

담

당

자

출 력 ( 정

상)

...

고객

고객정보
조회

PJTC-COM-
001

고객의
기본 정보
제공

CUST_INF

O_READ

고객정보 고객번호 김일동

고객번호,고
객명,실명번
호,주거래점
명,상태코드,
등록일자

...

고객 고객한도

조회

PJTC-COM-
002

비과세
등에 대한
고객별
한도 정보
제공

CUST_LIMI

T_READ

고객정보

고객별한

도원장

고객번호

한도코드

김이동

건수,고객번
호,한도코드,
총한도금액

...

금리 시장내부

금리조회

A710-COM-
001

시장 내부
금리 조회

RATE_IN_

READ

시장내부

금리

기준일자 김삼동

적용시작일
자,적용종료
일자,
기간이율

...

금리 연동내부

금리조회

A710-COM-
002

연동 내부
금리 조회

RATE_LIN

K_READ

연동내부

금리

기준일자 김사동

적용시작일
자,적용종료
일자,
기준이율,
가산이율

...

<표 1-20> 공통 모듈 코드 번호 인덱스 부여 예시

수행 tip

• 시스템별 기능 코드의 경우 프로젝트 표준에 코드

부여 기준 규칙이 있다면 해당 가이드를 참조한다.

• 인덱싱의 경우 프로젝트 확장성을 고려하여 자릿수

및 번호 부여 체계를 수립한다.

학습1

교수·학습 방법

교수 방법

• 공통 모듈의 필요성과 공통부분 식별 방법에 대해 설명한다.

• 분석 단계 산출물(업무 기능 분해도, 사용 사례 다이어그램)에 대한 개념을 설명한다.

• 단위 시스템과 전체 시스템의 공통부분 정리 방법에 대해 설명한다.

• 공통 기능에 대한 흐름도 및 프로그램 설계 방법을 설명한다.

• 공통 기능에 대한 화면 설계 및 배치 업무에 대한 설계 방법을 설명한다.

• 모듈화의 필요성과 응집도 및 결합도의 개념, 팬인/팬아웃에 대해 설명한다.

• 시스템 코드 부여 방법 및 공통 모듈 인덱싱 방법에 대해 설명한다.

학습 방법

• 공통 모듈의 필요성과 공통부분의 식별 방법에 대해 이해하고 실습 단계를 준비한다.

• 분석 단계 산출물(업무 기능 분해도, 사용 사례 다이어그램)에 대한 예시 및 사례에 대해

미리 확인하고 실습 단계 수업에 참여한다.

• 단위 시스템과 전체 시스템의 공통부분 정리 방법에 대해 숙지한 후 실습을 통해 파악한다.

• 공통 기능에 대한 흐름도 및 프로그램 설계 능력을 습득한다.

• 공통 기능에 대한 화면 설계 및 배치 업무에 대한 설계 실습을 통해 작성 항목 및 작성

내용 등에 대해 학습한다.

• 모듈화의 필요성과 응집도 및 결합도의 개념, 팬인/팬아웃의 개념을 숙지하고, 그 필요성

을 파악한다.

• 시스템 코드 부여 방법 및 공통 모듈 인덱싱 방법에 대한 사례를 학습한다.

학습1

평 가

평가 준거

• 평가자는 학습자가 학습 목표를 성공적으로 달성하였는지를 평가해야 한다.

• 평가자는 다음 사항을 평가해야 한다.

학습 내용

학습 목표

성취수준

상

중

하

공통 모듈 식별

및 명세

- 재사용성 확보와 중복 개발 회피를 위하여, 전체 시스

템 차원과 단위 시스템 차원의 공통부분을 식별하고

이에 대한 상세 명세를 작성할 수 있다.

공통 모듈 설계

- 개발할 응용 소프트웨어의 전반적인 기능과 구조를

이해하기 쉬운 크기의 공통 모듈로 설계할 수 있다.

- 소프트웨어 측정지표 중 모듈 간의 결합도는 줄이고

개별 모듈의 내부 응집도는 높이기 위한 공통 모듈을

설계할 수 있다.

공통 모듈 인덱스

및 기능 코드

설계

- 전반적인 처리 논리 구조에 예기치 못한 영향을 끼치

지 않도록 공통 모듈 인터페이스의 인덱스 번호나 기

능 코드를 설계할 수 있다.

평가 방법

• 서술형 시험

학습 내용

평가 항목

성취수준

상

중

하

공통 모듈 식별

및 명세

- 공통 모듈의 필요성 서술 능력

- 공통 모듈의 식별 방법 능력

공통 모듈 설계

- 모듈화의 개념 및 응집도와 결합도의 유형에 대한 파악

- 공통 모듈에 대한 설계 능력

공통 모듈 인덱스

및 기능 코드

설계

- 코드 유형에 대한 파악

- 시스템 코드 설계 능력

• 구두발표

학습 내용

평가 항목

성취수준

상

중

하

공통 모듈 식별

및 명세

- 단위 시스템과 전체 시스템 공통 모듈 구분

- 공통 모듈에 대한 명세 방법

공통 모듈 설계

- 공통 모듈에 대한 화면 설계 및 설계서 작성

- 응집도와 결합도에 대한 분석

공통 모듈 인덱스

및 기능 코드

설계

- 단위 시스템 특성에 따른 분류

- 공통 모듈에 순차적인 인덱스 부여

피드백

1. 서술형시험

- 공통 모듈의 필요성과 식별 방법에 대한 이해도가 높지 않은 경우 성취수준이 높은 다른

학습자의 자료를 공유하여 이해력을 높일 수 있도록 한다.

- 응집도와 결합도의 경우 설계 답안 자료를 작성하여 평가 이후 학습자에게 배포하여 부

족한 부분을 보완할 수 있도록 한다.

- 코드 유형 및 코드 설계에 대한 학습자의 평가 결과가 ‘하’에 해당하는 경우 모범

답안을 참조하여 다시 작성하게 한다.

2. 구두발표

- 공통 모듈 명세에 대해 학습자의 성취수준이 낮은 경우 성취수준이 높은 다른 학습자

의 발표 내용을 공유하여 이해력을 높일 수 있도록 한다.

- 공통 모듈에 대한 설계의 경우 설계서 작성에 대한 성취수준이 낮은 학습자에게 실무 자

료를 제공함으로써 이해를 높일 수 있도록 한다.

학습 1

공통 모듈 설계하기

학습 2 타 시스템 연동설계하기

2-1. 아키텍처를 고려한 타 시스템 연동 설계

학습 목표

• 소프트웨어 아키텍처에서 정의한 타 시스템 연동 리스트 및 연동 방안을 참조하여,

타 시스템 연동 상세 설계의 가이드라인을 작성할 수 있다.

• 소프트웨어 아키텍처의 정의를 반영한 연동 상세 설계 가이드라인에 따라, 타 시스

템 연동 상세 설계를 할 수 있다.

필요 지식 /

 시스템 연동의 개념

시스템 연동이란 서버와 네트워크를 활용하는 자동화 체계 등에서 동일한 기능을 수행하

지 않는 단위 시스템 간에 접속을 통하여 업무(기능)를 수행하는 것을 의미한다.

 데이터 연동

데이터 연동이란 데이터베이스를 공유하여 타 시스템과 연계하는 방법으로, 다른 연동 방

식에 비해 자원 이용과 구축 시간을 절약할 수 있으며 주로 내부 시스템의 연동을 위해

사용된다. 대표적으로 자바 데이터베이스 연동(JDBC, Java Database Connectivity) 등이 포

함된다. 연동 설계 시 관련 테이블과 상호 관계, 데이터의 참조 관계 등을 고려하여 설계

작업을 진행한다.

 인터페이스(Interface) 연동

인터페이스란 서로 독립적인 시스템의 상호 작용을 위한 접속 경계(Boundary)나 규칙을

의미하며, 인터페이스 연동을 위해서는 응용 프로그램 인터페이스(API : Application

Program Interface), 원격 메소드 호출(RMI : Remote Method Invocation) 등을 통해 타 시

스템과 연동이 가능하다.

인터페이스가 변경되는 경우 해당 인터페이스를 사용하는 다른 시스템에 대한 영향 범위

확인이 필요하며, 인터페이스에 대한 표준화, 연계 목록 및 방식, 처리 내용 등에 대한 지

속적인 현행화(Update)와 관리, 모니터링 수행이 필요하다.

 웹 서비스(Web Service) 연동

1. 웹 서비스 연동 개념

네트워크상에서 이기종 시스템 간에 표준화된 XML 메시지 및 여러 기술을 이용하여 시

스템 간에 연동할 수 있는 기술이다.

2. 웹 서비스 구성 요소

[그림 2-1] 웹 서비스 구성도

(1) SOAP(Simple Object Access Protocol)

XML과 HTTP 등을 기본으로 이용하는 통신규약(Protocol)으로 이기종 컴퓨터의 데이터나

서비스를 호출할 수 있으며, 다양한 프로그램 언어에서 쉽게 작성 및 실행 가능하다.

(2) UDDI(Universal Description Discovery Integration)

웹 서비스를 찾기 위한 XML 기반의 표준으로, 개방형 표준과 플랫폼 독립적인 기술을

기반으로 개발된 범용적이고 통합적인 레지스트리이다. 사용자가 다양한 웹 서비스를

쉽게 검색하여 사용할 수 있다.

(3) WSDL(Web Service Description Language)

웹 서비스를 기술하기 위한 표준 형식으로, 웹 서비스에서 제공하는 기능과 해당 기능

에 대한 상호 작용 방법을 XML 기반으로 설명하기 위한 언어이다.

수행 내용 / 아키텍처를 고려한 타 시스템 연동 설계하기

재료·자료

• SW 개발 국제 표준(ISO/IEC 9126, ISO/IEC 14598, CMMi 등)

• 소프트웨어 테스트 관련 국제 표준(ISO/IEC 12119)

• 업무 배경도, 아키텍처 구성 관련 타 시스템과의 연계 산출물

기기(장비 ･ 공구)

• 전산 장비(컴퓨터, 프린터, 빔 프로젝터, 네트워크 장비 등)

• OA 도구(워드프로세서, 스프레드시트, 프레젠테이션 도구 등)

• CASE 도구(SW 설계 지원 도구, SW 개발 지원 도구, SW 테스트 지원 도구 등)

안전 ･ 유의 사항

• 실습은 정해진 방법과 절차에 따라 실시하여야 한다.

• 업무 배경도 및 아키텍처 구성 산출물을 참고하여 타 시스템 연동 구간을 식별할 수 있어

야 한다.

• 타 시스템과 연동하기 위한 기술 요소에 대한 사전 학습이 필요하다.

• 타 시스템과의 연동 상세 설계서의 경우 프로젝트 상황 및 표준, 외부 기관에서 제공받은

데이터 등을 기준으로 최대한 상세히 작성하도록 한다.

수행 순서

 소프트웨어 아키텍처에서 정의한 타 시스템 연동 리스트 및 연동 방안을 검토한다.

기존에 정의된 소프트웨어 아키텍처의 타 시스템 연동과 관련된 연동 시스템 및 기능, 연

동 방식에 대한 내용을 검토한다.

[그림 2-2] 소프트웨어 구성도 예시

1. 타 시스템 연동 리스트를 검토한다.

내외부 연동 리스트에 대해 송신 및 수신 시스템, 관련 기능 등을 확인하고, 관련 정보가

누락되거나 명확하지 않은 경우 현행화한다.

(1) 내외부 시스템 연동 기능에 대한 리스트를 검토한다.

아키텍처에서 정의된 타 시스템 연동 리스트 목록을 전달 받아 관련 내용에 대한 확

인 작업을 진행한다.

(2) 연동 리스트에 누락된 항목을 확인한다.

내외부 연동을 위한 송신 및 수신 시스템, 외부 기관의 경우 기관명 및 관련 시스템

등의 정보가 누락되거나 명확하지 않을 시 관련 업무 담당자에게 내용을 확인하여 현

행화한다.

(3) 연동 리스트 항목에 대한 정확성에 대해 검토한다.

연동 대상 내/외부 시스템과 외부 기관에 대한 명칭이 일관성 있게 작성되었는지 여부

와 연동 기능이 정확히 기술되었는지를 검토하여 보완 작업을 진행한다.

2. 타 시스템 연동 방식을 검토한다.

내/외부 연동 시스템에 대한 연동 주기 및 연동 방식 등에 대해 확인하고 누락된 경우 관

련 정보를 추가한다.

(1) 내/외부 시스템 연동 주기를 확인한다.

실시간으로 연동하는지 일정한 주기(일일 배치 등)로 연동이 발생하는지 주기를 확인

하고 누락된 경우 관련 내용을 추가한다.

(2) 내/외부 시스템 연동 방식을 확인한다.

웹 서비스, 데이터베이스 공유, EAI 등 내/외부 시스템에 대한 연동 방식 유형에 대해

확인하고 외부 기관의 경우 연계 담당자를 통해 최종 확인한다.

 타 시스템 연동 상세 설계 가이드라인을 작성한다.

내외부 시스템 연동 리스트 및 연동 방식을 참고하여 연동 기능에 대한 상세 설계서를 작

성할 수 있도록 설계 가이드라인을 작성한다.

1. 타 시스템 연동 목록 작성에 필요한 정보를 검토한다.

타 시스템 연동 목록 및 방식을 참고하여 연동 목록 작성을 위해 필요한 항목과 항목별

유형 등을 검토한다.

(1) 송/수신 시스템 및 연계 기관 정보를 검토한다.

정보를 요청하는 시스템과 수신하여 처리하는 시스템에 대한 명칭과, 외부 기관의 경

우 어느 정보까지 작성 가능한지 검토하여 가이드라인에 내용을 기술한다.

(2) 인터페이스 ID 부여 규칙을 검토한다.

프로젝트 명명 규칙 등을 참고하여 인터페이스가 중복되지 않고 고유하게 식별될 수

있는 ID 생성 규칙에 대해 검토한다.

(가) 내부 시스템에 대한 시스템 코드를 부여한다.

내부 시스템을 고유하게 식별할 수 있는 시스템 코드를 확인하고, 프로젝트에서 정

의되지 않은 경우 내부 시스템에 대한 시스템 코드를 부여한다.

(나) 외부 시스템에 대한 시스템 코드를 부여한다.

외부 시스템을 고유하게 식별할 수 있도록 외부 기관의 성격 및 시스템을 구분하

여 고유한 시스템 코드를 부여한다.

(3) 인터페이스 주기 및 연동 방식을 검토한다.

인터페이스가 얼마 정도의 주기로 요청 및 처리되는지 확인하고, 연동 방식의 유형에

대해 검토하여 가이드라인에 작성 방법을 기술한다.

(4) 데이터 타입을 검토한다.

인터페이스를 통해 전송되는 자료의 유형을 확인 및 검토하여 가이드라인에 작성 방

법을 기술한다.

(5) 관련 프로그램을 검토한다.

연동 기능을 호출하거나 호출되는 프로그램을 어느 단위까지 기술 가능한지에 대해

검토하여 가이드라인에 작성 방법을 기술한다.

2. 타 시스템 연동 목록 작성을 위한 설계 가이드라인을 작성한다.

내/외부 연동 목록에 대해 전체 현황이 포함될 수 있도록 작성하고, 위에서 검토한 내용

을 기준으로 아래 항목에 대한 설명 및 작성 예시 등을 제시한다.

순번

항목

내용

연계 구분

내부 시스템인지 외부 시스템인지에 대한 구분

요청 송신 시스템

정보를 요청하는 시스템

요청 수신 시스템

정보를 제공하는 시스템

연계 기관

외부 연계인 경우 관련 기관명

인터페이스 ID

프로젝트 규칙을 고려한 인터페이스 식별 번호

인터페이스 명

인터페이스에 대한 명칭

설명

인터페이스에 대한 설명

인터페이스 주기

인터페이스가 발생하는 주기

인터페이스 방식

인터페이스 연동 방식

동기 방식

연동 방식의 동기/비동기 여부

데이터 타입

주고받는 데이터 형태

프로그램 ID(Cal er)

요청하는 시스템의 프로그램 정보

프로그램 ID(Cal ed)

제공하는 시스템의 프로그램 정보

<표 2-1> 타 시스템 연동 목록 작성을 위한 가이드라인 포함 항목

3. 가이드라인에 대한 검토 회의를 진행한다.

가이드라인에 따라 연동 목록에 대한 구체적인 작성이 가능한지, 작성 내용이 적합한지

등에 대해 이해관계자와 검토 작업을 진행한다.

검토 작업 시 식별된 개선 사항을 적용한 후 이해관계자와의 최종 합의를 거쳐 프로젝트

공식 작성 가이드로 등록한다.

[그림 2-3] 타 시스템 연동 목록 작성을 위한 가이드 예시

4. 타 시스템 연동 목록에 대한 상세 설계 가이드라인 작성 방법을 검토한다.

타 시스템 연동 목록의 요소별로 상세 설계 작업에 필요한 항목과 항목에 대한 구체적인

작성 방법을 검토한다.

(1) 인터페이스 송신/수신 시스템 항목에 대해 검토한다.

타 시스템 연동 목록과의 매핑을 위해 필요한 정보와 정보 요청 송신 및 수신 시스템

에 대해 작성이 요구되는 항목을 검토한다. 일반적인 경우 인터페이스 ID를 이용하여

상세 설계서와 매핑하고, 효과적인 유지 관리를 위하여 송/수신 시스템에 대한 정보와

함께 해당 시스템의 관련 프로그램도 기술하도록 한다.

(2) 전달 및 결과 데이터 항목에 대해 검토한다.

(가) 전달 데이터와 결과 데이터 구분 방법에 대해 검토한다.

인터페이스 호출 시 전달하는 데이터와 처리된 결과 데이터를 구분할 수 있는 방

법에 대해 검토하여 가이드를 작성한다.

(나) 일련번호 구성 방법에 대해 검토한다.

전달하는 데이터 및 처리 결과 데이터가 배열(Array)이나 벡터(Vector) 등과 같이 하

나의 객체에 여러 개의 데이터가 존재할 수 있으므로 그룹화하여 표시할 수 있도록

가이드를 작성한다.

(다) 데이터 명칭 및 데이터 타입에 대해 검토한다.

관련 데이터와 연관 있는 테이블 정보와 데이터 형식 및 길이 표시 방법 등에 검

토 후 관련 정보가 적절히 표시될 수 있도록 가이드를 작성한다.

[그림 2-4] 가이드 작성 및 발표

5. 타 시스템 연동 목록에 대한 상세 설계 가이드라인을 작성한다.

가이드라인을 작성할 때에는 위에서 검토한 항목을 포함하여 상세 설계서를 작성하도록

유도하고, 아래 표와 같이 항목에 대한 설명과 작성 예시 등을 제시한다.

순번

항목

내용

인터페이스 ID

타 시스템 연동 목록과의 매핑

인터페이스 명

인터페이스에 대한 명칭

요청 송신 시스템

정보를 요청하는 시스템 명칭

정보를 요청하는 시스템의 인터페이스 및 오퍼레이션

정보를 요청하는 시스템의 관련 테이블

요청 수신 시스템

정보를 제공하는 시스템 명칭

정보를 제공하는 시스템의 인터페이스 및 오퍼레이션

정보를 제공하는 시스템의 관련 테이블

구분

입력 및 출력 정보 구분

필드 명

관련 데이터의 세부 정보

데이터

데이터 타입 및 길이

예제

작성 예시 정보

필수

작성 항목에 대한 필수 여부

<표 2-2> 가이드라인 작성 항목 예시

6. 가이드라인에 대한 검토 회의를 진행한다.

작성된 가이드라인의 내용에 따라 인터페이스에 대한 상세 설계서 작성이 실제로 가능한

지, 작성 내용이 적합한지 등에 대해 이해관계자와 검토한 후 최종 합의를 거쳐 프로젝트

의 공식 작성 가이드로 등록한다.

[그림 2-5] 타 시스템 연동 상세 설계서 작성 가이드 예시

 타 시스템 연동 목록을 작성한다.

내/외부 시스템 연동 리스트 작성 가이드라인을 참고하여 타 시스템과 연동하는 인터페이

스 항목의 목록 및 내용을 작성한다.

1. 연계 구분 및 관련 시스템 명을 작성한다.

연동되는 시스템의 내부/외부 구분을 작성하고, 정보 요청과 관련된 송신 시스템 및 수신

시스템의 명칭을 작성한다. 연동 시스템이 외부 기관인 경우 연계 기관 항목에 해당 기관

에 대한 정보를 함께 작성한다.

2. 인터페이스 ID를 작성한다.

프로젝트의 명명 규칙에 따라 고유한 식별 번호를 부여하며, 해당 인터페이스 ID의 정보

를 기반으로 송신 및 수신 시스템이 구분될 수 있도록 인터페이스 ID를 작성한다. 외부

기관에 대한 시스템 코드가 존재하지 않는 경우 아래와 같은 방식으로 별도의 시스템 코

드를 부여한다.

(1) 연동되는 외부 기관 정보를 취합한다.

시스템 연동이 필요한 외부 기관에 대해 기관명과 해당 기관의 시스템 명칭을 확인하

여 취합하고 정리한다.

(2) 외부 기관 정보를 그룹화한다.

외부 기관과의 연동 목적 등을 고려하여 연동 목적이 유사한 외부 기관을 그룹화하고

분류 체계를 수립한다.

(3) 외부 기관에 대한 시스템 코드를 부여한다.

연동이 필요한 외부 기관의 개수 및 그룹화 결과 등을 검토하여 프로젝트 현황에 맞

게 외부 기관에 대한 시스템 코드를 부여한다.

[그림 2-6] 외부 기관 시스템 코드 부여 예시

3. 인터페이스 명과 설명을 작성한다.

인터페이스를 특정할 수 있는 대표적인 기능을 명칭으로 작성하고, 해당 인터페이스에서

제공 및 처리하는 내용을 작성한다.

4. 인터페이스 주기/연동 방식 등에 대해 작성한다.

인터페이스의 주기(실시간 처리, 배치를 통한 처리 등), 연동 방식(웹 서비스, API, JDBC

등), 동기/비동기 여부 등에 대한 항목을 작성한다.

5. 프로그램 정보를 작성한다.

연동 인터페이스를 호출하는 프로그램 명칭 및 메소드를 프로그램 ID(Caller)에 기술하고,

호출되는 프로그램의 정보를 알고 있는 경우 프로그램 ID(Called)에 관련 정보를 작성한다.

[그림 2-7] 타 시스템 연동 목록 작성 예시

 타 시스템 연동 상세 설계서를 작성한다.

내/외부 시스템 연동 상세 설계서 작성 가이드라인을 참고하여 타 시스템과 연동하는 인

터페이스에 대한 항목 및 내용을 작성한다.

1. 인터페이스 정보를 작성한다.

타 시스템 연동 목록을 참고하여 인터페이스 ID 및 명칭, 요청 송신/수신 시스템, 관련 인

터페이스의 프로그램 정보를 작성한다.

2. 인터페이스 데이터 항목을 작성한다.

(1) 외부 기관 연동

외부 기관의 업무 담당자를 통해 송신 및 수신 정보를 확인하고, 양쪽 기관 모두 신규

개발이 필요한 경우 기관 담당자 간 협의를 통해 송신/수신 데이터를 작성한다.

(가) 외부 기관에 데이터를 요청하는 경우

관련 업무에 대한 외부 기관 담당자의 연락처 및 메일 주소를 확인하고 담당자에

게 연계 및 개발 가이드 정보를 요청한다.

1) 관련 업무에 대한 외부 기관 담당자를 확인한다.

2) 담당자를 통해 연계 및 개발 가이드 등에 대한 정보를 요청한다.

3) 데이터 요청 시 송신 및 수신 데이터의 개수, 타입, 길이, 한글/영문/숫자 여부

등에 대해 확인한다.

4) 송신 및 수신 데이터를 조회하고 저장하는 관련 테이블과 컬럼 정보(타입, 자

릿수 등)에 대해 특이 사항이 없는지 검토한다.

5) 송신 데이터와 수신 데이터 항목을 구분하여 정리한다.

(나) 외부 기관에 데이터를 제공하는 경우

제공해야 하는 데이터와 관련된 정보 및 반환되는 형식 등에 대해 확인하고, 해당

데이터를 확인하기 위한 입력 데이터 등에 대해 분석하여 설계서를 작성한다.

1) 제공하는 데이터가 존재하는 테이블 및 컬럼에 대한 정보를 확인한다.

2) 제공 데이터의 데이터 타입 및 길이, 형식 등에 대해 정의한다.

3) 제공 데이터를 조회하기 위해 전달 받아야 하는 파라미터를 확인한다.

4) 송신 및 수신 데이터에 대한 필드 명을 정의하고 항목을 구분하여 작성한다.

5) 작성된 상세 데이터 항목 등의 정보를 외부 연동 기관에 전달한다.

(2) 내부 시스템 연동

관련 시스템의 기능 담당자를 확인하고 관련 인터페이스에 대한 송신 및 수신 데이터

상세 정보에 대해 협의 및 검토 진행 후 작성한다.

(가) 관련 시스템의 기능 연동 담당자 정보를 확인한다.

(나) 인터페이스 및 데이터 항목에 대해 확인한다.

정보를 제공하는 경우에는 관련 데이터의 존재 위치, 반환 형식, 입력 데이터 등에

대해 검토하고, 정보를 요청하는 경우에는 호출해야 하는 응용 프로그램의 정보와

입력 및 출력 데이터의 필드 명, 데이터 타입 및 길이 등을 확인한다.

(다) 송신/수신 데이터에 대해 정리한다.

송신 및 수신 데이터에 대해 인터페이스 방식과 저장/관리되는 테이블, 데이터 형식,

길이 등에 대해 검토 후 특이 사항이 없으면 상세 설계서에 관련 내용을 기술한다.

[그림 2-8] 타 시스템 연동 상세 설계서 작성 예시

수행 tip

• 소프트웨어 아키텍처 구성 확인 시 서버에 설치되는 미

들웨어 및 소프트웨어 구성 등에 대해서도 검토한다.

• 타 시스템 연동 기능의 경우 호출하거나 호출되는

시스템 담당자와 함께 전달되는 파라미터의 정확성

에 대해 확인한다.

2-2. 미들웨어 솔루션 명세 작성

학습 목표

• 소프트웨어 아키텍처에 따라 선정된 개발 및 운영 환경에 사용될 기술영역별 미들

웨어 솔루션에 대하여 명세를 작성할 수 있다.

필요 지식 /

 미들웨어 솔루션(Middleware Solution)

1. 미들웨어 솔루션의 개념

클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어 또는 컴퓨터와 컴퓨터의 연

결을 담당하는 소프트웨어로서, 중간을 의미하는 미들(middle)과 소프트웨어(Software)를

의미하는 웨어(ware)의 합성어이다.

2. 미들웨어 솔루션의 유형

미들웨어 유형

내용

데이터베이스

데이터베이스 벤더에서 제공하는 클라이언트에서 데이터베이스와

연결하기 위한 미들웨어로, 이 제품을 사용하여 시스템을 구축하는

경우에 보통 2-티어 아키텍처라고 한다.

RPC(Remote Procedure

Cal )

응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬

프로시저처럼 호출하는 방식의 미들웨어를 의미한다.

MOM(Message Oriented

Middleware)

메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어로

이기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용된다.

TP-모니터

온라인 트랜잭션 업무(은행 계정, 항공기/버스 예약 업무 등)에서

트랜잭션을 처리, 감시하는 미들웨어. 사용자 수가 증가하여도 빠른

응답 속도를 유지해야 하는 업무에 적합하다.

ORB(Object Request

Broker)

객체지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한 미들웨어.

최근에는 TP-모니터가 가지고 있는 장점(트랜잭션 처리, 모니터링

등)을 추가로 구현하였다.

WAS(Web Application

Server)

클라이언트/서버 환경보다는 웹 환경을 구현하기 위한 미들웨어.

WAS는 HTTP 세션 처리를 위한 웹서버 기능뿐만 아니라 미션-

크리티컬한 기업 업무까지 자바, EJB 컴포넌트 기반으로 구현

가능하다.

<표 2-3> 타 시스템 연동 목록 작성을 위한 가이드라인 포함 항목

 웹서버와 웹 애플리케이션 서버(WAS, Web Application Server)

1. 웹서버(Web Server)

웹 브라우저(Web Client)의 요청을 받아 html 파일이나 이미지(jpg, gif 등), 자바스크립트

의 정적인 콘텐츠를 제공하며 대표적인 웹서버로 아파치가 있다.

2. 웹 애플리케이션 서버(WAS, Web Application Server)

서버단(Server Level)에서 애플리케이션이 동작할 수 있는 환경을 제공하고, 안정적인 트

랜잭션 처리 및 관리, 다른 이기종 시스템 간의 애플리케이션 연동을 지원한다. 웹서버와

의 가장 큰 차이는 동적 서버 콘텐츠를 수행할 수 있는 기능이다.

3. 웹서버와 와스서버의 일반적인 구성

사용자가 웹 브라우저를 통해 요청하는 경우 정적 데이터(이미지, 자바스크립트 등)는 웹

서버가 처리하고, 동적 콘텐츠(DB 접속, 외부 시스템 연동 등)의 경우 와스로 서비스를 요

청함으로써 서버 자원을 효율적으로 처리할 수 있도록 구성한다.

[그림 2-9] 웹서버와 와스서버의 일반적인 구성 및 역할

수행 내용 / 미들웨어 솔루션 명세 작성하기

재료·자료

• SW 개발 국제 표준(ISO/IEC 9126, ISO/IEC 14598, CMMi 등)

• 소프트웨어 테스트 관련 국제 표준(ISO/IEC 12119)

• 아키텍처 및 시스템 구성도와 같은 환경 구성 관련 산출물

• 미들웨어 솔루션에 대한 소개 및 설명서

기기(장비 ･ 공구)

• 전산 장비(컴퓨터, 프린터, 빔 프로젝터, 네트워크 장비 등)

• OA 도구(워드프로세서, 스프레드시트, 프레젠테이션 도구 등)

• CASE 도구(SW 설계 지원 도구, SW 개발 지원 도구, SW 테스트 지원 도구 등)

안전 ･ 유의 사항

• 실습은 정해진 방법과 절차에 따라 실시하여야 한다.

• 미들웨어의 종류와 필요성에 대한 사전 학습이 필요하다.

• 미들웨어 솔루션에 대한 명세 작업 후 아키텍처 및 제품 담당자와 함께 특이 사항이 없는

지 등에 대해 확인 작업을 진행한다.

수행 순서

 개발 및 운영 환경에 사용될 미들웨어 솔루션에 대해 확인한다.

개발 및 운영 환경에서 사용될 미들웨어 솔루션의 유형 및 종류 등의 현황에 대해 확인하

여 상세 정보를 기술한다.

1. 아키텍처 구성 정보를 검토한다.

소프트웨어 아키텍처에서 정의한 아키텍처 구성 정보를 확인하여 개발 및 운영 환경에서

사용될 미들웨어 솔루션을 식별한다.

2. 프로젝트의 구매 SW를 검토한다.

프로젝트에서 구매가 진행 중이거나 구매 예정인 SW 내역을 확인하여 개발 및 운영 환경

에서 사용될 미들웨어 솔루션을 식별한다.

3. 프로젝트에서 사용될 미들웨어 솔루션에 대해 정리한다.

아키텍처 정의 및 프로젝트 구매 SW 등을 통해 식별한 미들웨어 솔루션에 대해 솔루션의

명칭 및 버전, 제조사 정보 등을 정리한다.

4. 누락된 솔루션에 대해 검토한다.

정리된 미들웨어 솔루션 정보를 이해관계자 등에게 공유하고 누락되거나 잘못 식별된 솔

루션이 있는지 검토한다.

시스템

구분

솔루션명

버전

제조사

콘텐츠 관리

시스템

와스(WAS, Web

Application Server)

Tomacat

Ver 7

아파치 소프트웨어

파운데이션(Apache

Software Foundation)

사용자 관리

시스템

와스(WAS, Web

Application Server)

WebOOOO

Ver 11g

OOOO

결제 관리

시스템

와스(WAS, Web

Application Server)

JeOOOO

Ver 8

OOOO

연계 관리

시스템

EAI

InOOOO

N/A

OOOO

<표 2-4> 미들웨어 솔루션 목록 작성 예시

 미들웨어 솔루션에 대한 명세서를 작성한다.

개발 및 운영 환경에서 사용될 미들웨어 솔루션의 유형 및 종류 등의 현황에 대해 확인하

여 상세 정보를 기술한다.

1. 제조사의 제품 소개서 내용을 검토한다.

솔루션에 대한 제품 안내서 및 설명 자료 등을 통하여 제품 명칭 및 버전, 제품 사용 목

적 등에 대해 확인한다.

2. 솔루션의 제공 기능 및 특징 등에 대해 검토한다.

솔루션 설명 자료 검토 및 관련 담당자 확인 등을 통하여 제품에 대한 사용 환경과 특징

등에 대한 정보를 확인한다.

3. 솔루션의 제약사항에 대해 검토한다.

해당 솔루션이 지원하는 시스템 범위와 정상적인 서비스 제공을 위한 환경 구성, 제공 기

능 등에 대해 제약사항이 존재하는지 확인한다.

4. 솔루션에 대한 명세서를 작성한다.

솔루션에 대한 상세 정보 및 제공 기능, 특징 및 시스템 구성 환경 등에 대한 제약사항을

정리하여 솔루션에 대한 명세서를 작성한다.

[그림 2-10] 미들웨어 솔루션 명세서 작성 목차 예시

수행 tip

• 미들웨어 솔루션 명세서 작성 시 제품 설명서 및 기술

지원 담당자를 통해 제약사항 등에 대해 확인한다.

• 미들웨어 솔루션의 이기종 설치 지원 여부, 시스템

연계 가능 여부, 라이선스 정책, 유지 보수 방안 등

에 대해서도 미리 검토한다.

2-3. 오류 예측 및 대응방안 제시

학습 목표

• 소프트웨어 아키텍처에 따른 시스템 간의 연동 시, 발생할 수 있는 오류를 예측하

고 대응방안에 대해 제시할 수 있다.

필요 지식 /

 가용성 향상을 위한 이중화

이중화 기술이란 복수의 시스템이나 장치 등을 활용함으로써 하나의 시스템에 장애가 발

생하는 경우에도 정상적인 서비스가 제공될 수 있도록 가용성(Availability)을 극대화하기

위한 기술을 통칭한다.

[그림 2-11] 이중화 방식 비교

1. 액티브-액티브(Active-Active) 방식

평상시에도 모든 서버가 서비스를 제공하는 방식으로 운영되며, 한 서버에 장애가 발생하

는 경우 다른 서버를 통해 서비스를 연속적으로 제공하는 방식이다.

2. 액티브-스탠바이(Active-StandBy) 방식

평상시에는 한쪽 서버에서만 서비스를 제공하고, 장애가 발생하는 경우 다른 서버로 서비

스를 이관하여 연속적인 서비스를 제공하는 방식이다.

 재해 복구 시스템(DRS, Disaster Recovery System)

재해 복구 계획의 원활한 수행을 지원하기 위하여 평상시에 확보하여 두는, 정보시스템에

서의 업무 연속성 유지를 위한 체계이다.

구분

설 명

복구 시간

Mirror Site

주 센터와 동일한 수준의 정보 기술 자원을 원격지에

구축하여 실시간 동시 서비스 제공

즉시

Hot Site

주 센터와 동일한 수준의 정보 기술 자원을 원격지에

구축하여 스탠바이(Standby) 상태로 유지

수시간

Warm Site

중요성이 높은 정보 기술 자원만 부분적으로 재해

복구 센터에 보유

수일

<표 2-5> 재해 복구 시스템의 복구 수준별 유형

 복구 목표 시간과 복구 목표 시점

장애 발생 시점을 기준으로 데이터 유실 및 시스템 다운 타임의 발생을 막으려면 많은 비

용이 발생한다. 따라서 한정된 비용 안에서 데이터 유실 및 다운 타임에 대한 위험을 최

소화하기 위한 항목이 복구 목표 시간과 복구 목표 시점이다.

1. 복구 목표 시간(RTO, Recovery Time Objective)

서비스가 중단된 경우 이를 복구하기까지는 서비스가 중단될 수 있는, 다운 타임에 대한

최대 허용 시간을 의미한다.

2. 복구 목표 시점(RPO, Recovery Point Objective)

서비스가 중단된 경우 중단된 서비스를 복구할 때 데이터 유실에 대한 최대 허용 가능한

시점을 의미한다. 즉, 현재로부터 가장 가까운 복원 지점(백업 시점)까지의 시간 목표라고

할 수 있다.

 업무 영향 분석(BIA, Business Impact Analysis)

재해나 장애로 인해 서비스 운영의 문제가 발생할 것을 가정하고, 이에 따른 영향도 및

손실 평가를 조사하는 방법이다.

1. 수행 절차

(1) 업무 분류 체계 정의 및 주요 업무 프로세스 식별(정성적/정량적 평가 항목 도출 )

(2) 각 서비스별 업무 상관관계 분석 및 장애 발생 시 손실 비용 분석

(3) 서비스 중요도에 따른 복구 대상 및 우선순위 도출

(4) 주요 서비스별 복구 목표 시간 설정

2. 구성요소

(1) 핵심 우선순위 결정 : 서비스 중요도에 따라서 복구에 대한 우선순위 부여

(2) 서비스 중단 시간 산정 : 서비스 중단에 따른 최대 극복 가능 시간 산정

수행 내용 / 오류 예측 및 대응방안 제시하기

재료·자료

• SW 개발 국제 표준(ISO/IEC 9126, ISO/IEC 14598, CMMi 등)

• 소프트웨어 테스트 관련 국제 표준(ISO/IEC 12119)

• 아키텍처 구성 및 시스템 연계 구성과 같은 환경 구성 산출물

기기(장비 ･ 공구)

• 전산 장비(컴퓨터, 프린터, 빔 프로젝터, 네트워크 장비 등)

• OA 도구(워드프로세서, 스프레드시트, 프레젠테이션 도구 등)

• CASE 도구(SW 설계 지원 도구, SW 개발 지원 도구, SW 테스트 지원 도구 등)

안전 ･ 유의 사항

• 실습은 정해진 방법과 절차에 따라 실시하여야 한다.

• 시스템 연동과 관련된 연동 기술에 대한 이해가 필요하다.

• 시스템 가용성 및 이중화 구성 환경에 대한 사전 학습이 필요하다.

• 오류 방지 대책 수립 시 시스템 및 인프라 측면, 응용 프로그램 측면을 나누어 검토하고

프로젝트 비용 및 일정, 특성을 고려하여 적용한다.

수행 순서

 시스템 연동 측면에서 발생 가능한 오류 및 방안을 수립한다.

시스템 연계 구성도 등을 검토하여 재해 복구 및 이중화 구성 등에 대한 현황 확인 후,

시스템 연동과 관련된 오류 발생 시 손실을 최소화할 수 있는 방안에 대해 검토한다.

1. 시스템 연계 구성도를 검토한다.

내부/외부 시스템과의 연계 구성도를 검토하여 상호 백업 및 이중화 구성 현황에 대해 검

토한다.

(1) 시스템 연동 구간에 대한 이중화 및 백업 구성 여부에 대해 검토한다.

(2) 연동 기능 중 이중화 구성이 되지 않은 업무에 대해 식별한다.

2. 이중화 구성에 대해 검토한다.

이중화 구성이 되지 않아 시스템 연동 시 업무가 완전히 중단될 수 있는 시스템을 대상으

로 이중화 구성을 적용할지 여부 등에 대해 검토한다.

(1) 이중화 구성이 되지 않은 업무에 대한 업무 영향 분석을 수행한다.

시스템 연동이 되지 않을 경우 업무 중단으로 인해 발생할 수 있는 여러 가지 상황과

그로 인한 영향을 파악한다.

(2) 업무에 대한 우선순위화 작업을 진행한다.

업무 영향 분석을 통하여 시스템 연동이 되지 않을 경우 그로 인해 중단될 수 있는

여러 업무에 대해 우선순위를 부여한다.

(3) 이중화 구성 가능 여부에 대해 검토한다.

우선순위가 높은 업무의 시스템 연동 구간에 대해 이중화 구성이 가능한지를 이해관

계자와의 관련 회의 등을 통해 검토한다.

이중화 구성의 경우 별도의 하드웨어 및 소프트웨어 등에 대한 구매가 필요할 수 있

어 프로젝트 상황 및 비용 대비 효과성을 고려하여 검토를 진행한다.

[그림 2-12] 시스템 연계 및 이중화 구성 등에 대한 검토 회의

 데이터를 제공하는 시스템에 대해 발생 가능한 오류를 예측하고 방안을 수립한다.

내/외부 시스템 연동 시 데이터를 제공하는 시스템에서 발생 가능한 오류를 식별하고, 오

류 발생 내용을 확인하고 조치할 수 있도록 방안을 수립한다.

1. 입력 정보에 대해 발생할 수 있는 오류를 예측한다.

타 시스템에서 데이터 요청 시 전달되는 항목에 잘못된 정보가 포함될 경우 시스템 오류

가 발생할 수 있으므로 관련 데이터에 대해 검증 가능한지 여부를 검토한다.

(1) 입력 항목의 필수 항목에 대한 누락 여부 검증 방안을 검토한다.

입력 항목 중 필수로 전달 받아야 할 항목이 누락되어 존재하지 않는 경우 관련 사항

에 대해 시스템에서 검증 가능한지 여부를 검토한다.

(2) 입력 항목의 데이터 형식에 대한 검증 방안을 검토한다.

입력 항목의 데이터 형식이 기존에 정의한 형식(숫자, 영문자 등)과 동일한지에 대해

검증 가능한지 여부를 검토한다.

(3) 입력 항목의 길이에 대한 검증 방안을 검토한다.

입력 항목의 길이가 상이할 경우 시스템에 오류가 발생할 수 있는 항목에 대해 관련

정보에 대해 검증 가능한지 여부를 검토한다.

(4) 입력 항목의 데이터 값에 대한 검증 방안을 검토한다.

입력 항목의 데이터 중 특정 값이 아닌 다른 값이 전달되어 오류를 유발시킬 가능성

이 존재하는 항목에 대해 검증 가능한지 여부를 검토한다.

항 목

데이터

설계서 내용

전달 데이터

검 증

필수 여부

주민등록번호

필수

필드 값에 Nul , 공백이

존재하는지 검증

데이터 형식

신청연도

4자리 숫자

ABCD

데이터의 각 항목이

숫자인지 검증

데이터 길이

접수번호

1234567

데이터의 Length가 5가

아니면 오류 반환

데이터 값

내국인구분

Y : 내국인

N : 외국인

값이 'Y', 'N'이 아니면

오류를 반환

<표 2-6> 입력 항목 오류 검증 예시

2. 출력 정보에 대해 발생할 수 있는 오류를 예측한다.

입력 데이터는 정상적이나 데이터 처리 중 오류가 발생하는 경우, 호출하는 시스템에 비

정상적으로 처리되었다는 정보가 제대로 전달될 수 있는지에 대해 검토한다.

(1) 조회 결과가 존재하지 않는 경우의 처리 방안에 대해 검토한다.

조회 결과가 존재하지 않는 경우 정상적인 결과 코드만 반환할지, 오류 코드를 별도로

부여할지 여부에 대해 검토한다.

(2) 데이터 처리 중 오류가 발생한 경우의 처리 방안에 대해 검토한다.

조회 중 오류가 발생하는 경우 솔루션 및 프레임워크, 응용 프로그램에서 예외 처리를

하고 비정상 여부를 식별하여, 호출 시스템에 비정상 처리와 관련된 정보를 반환할 수

있는 방안에 대해 검토한다.

3. 입력 및 출력 정보 오류에 대해 오류 코드를 정의한다.

시스템에서 식별 및 검증 가능한 오류 항목에 대해 호출 시스템에 전달할 오류 코드 및

내용을 정의한다.

(1) 오류 코드 부여 방법을 정의한다.

프로젝트 및 시스템의 특성 등을 고려하여 오류 코드의 자릿수와 형식을 검토하고, 오

류 코드가 그룹화되어 관리될 수 있도록 부여 방법을 정의한다.

(2) 오류 코드 및 오류 내용을 정리한다.

오류 코드가 부여된 항목에 대해 해당 코드와 오류 내용을 기술하여 정리하고, 지속적

으로 관리 및 업데이트 작업을 진행한다.

순번

그룹

오류 코드

오류 메시지

필수값 입력

누락(0001~0999)

0001

입력값 오류(주민등록번호 Nul )

0002

입력값 오류(요청자 성명 Nul )

데이터 형식

오류(1000~1999)

1000

데이터 형식 오류(주민등록번호)

1001

데이터 형식 오류(접수일자)

데이터 길이

오류(2000~2999)

2000

데이터 길이 오류(신청연도)

2001

데이터 길이 오류(접수번호)

데이터 값

오류(3000~3999)

3001

데이터 값 오류(성별)

3002

데이터 값 오류(내국인 여부)

데이터 처리

오류(9000~9999)

9000

데이터 조회 오류(서버 시스템 오류)

<표 2-7> 데이터 제공 시스템에 대한 오류 코드 정의 예시

 데이터를 제공 받는 시스템에서 발생 가능한 오류를 예측하고 방안을 수립한다.

타 시스템에 데이터를 요청하였으나 수신 결과가 정상적이지 않은 경우 후속 기능 처리에

오류가 발생할 수 있으므로 발생 가능한 오류를 식별하고 조치할 수 있는 방안을 수립한다.

1. 전송 데이터 항목에 대한 검증 방안을 검토한다.

인터페이스 호출 시 전송되는 데이터에 대해 필수 항목, 데이터 형식, 데이터 길이, 데이

터 값 등에 대해 시스템에서 사전 검증 가능한지와 검증을 수행할지 등을 검토한다.

2. 수신 데이터 항목에 대한 검증 방안을 검토한다.

반환 결과에 대해 예외가 발생한 경우 에러 코드 등이 정의되었는지 확인하여 해당 결과

에 따라 시스템에서 분기하여 처리하도록 한다.

(1) 타 시스템 연계 담당자에게 예외 상황에 대한 오류 코드를 요청한다.

(2) 반환되는 오류 코드 유형에 따라 처리 방안에 대해 검토한다.

연계 기관의 반환 결과에 대한 오류 코드 유형에 따라 사용자에게 어떤 정보를 표시

할지에 대해 검토한다.

(가) 요청 데이터에 문제가 존재하는 경우

사용자가 잘못 입력한 정보로 인해 정상적으로 처리되지 않은 경우 관련 데이터에

대한 확인 후 다시 요청할 수 있도록 검토한다.

(나) 타 시스템 장애 등으로 처리가 되지 않는 경우

연계 시스템의 장애 등으로 관련 업무가 정상적으로 처리되지 않고 있으므로 잠시

후 다시 요청할 수 있도록 검토한다.

 시스템 연동 구간에 대한 단계별 로그 추가에 대해 검토한다.

시스템 연동 구간에서 오류가 발생할 수 있는 구간을 식별하고 해당 구간에 단계별 로그

를 추가함으로써 예기치 않은 오류 발생 시 발생 원인을 파악할 수 있도록 한다.

1. 시스템 간 연동에 대한 구성도를 검토한다.

시스템 연동 구간을 확인하여 오류가 발생 가능한 연동 구간을 파악하고 인터페이스를 호

출하기 전과 결과를 반환 받는 시점에 로그를 남기는 것으로 검토한다.

2. 단계별 로그를 생성할 수 있는지에 대해 검토한다.

시스템 연동 시 오류가 발생하는 경우 내부 시스템과 외부 시스템(데이터 요청, 데이터

제공)에 대한 로그 생성 위치 및 내용을 검토하여 적용한다.

구분

요청 송신 시스템

요청 수신 시스템

로그 내용

내부시스템

1. 인터페이스 호출 전

2. 인터페이스 호출 후

1. 인터페이스 실행 전

2. 인터페이스 실행 후

1. 전달 데이터

2. 시스템 오류 내용

외부시스템(데이

터요청)

1. 인터페이스 호출 전

2. 인터페이스 호출 후

외부시스템(데이

터제공)

1. 인터페이스 실행 전

2. 인터페이스 실행 후

<표 2-8> 내/외부 시스템 연동 시 로그 생성 위치 및 내용 예시

 외부 기관 연계에 대한 업무 및 담당자 정보를 작성/관리한다.

외부 기관의 경우 인사이동과 업무 변경, 퇴사 등의 여러 가지 사유로 담당자 확인이 어

려울 수 있으므로 프로젝트 차원에서 체계적인 관리가 필요하며, 인터페이스 변경 및 시

스템 변경 작업 등에 대해서는 사전에 공지한다.

1. 내/외부 연동 리스트를 참고하여 관련 시스템 및 외부 기관을 식별한다.

내/외부 연동 리스트에서 외부 기관과의 연계 항목과 관련된 시스템 및 외부 기관 정보를

확인하여 관리 대상 목록을 식별한다.

2. 외부 기관의 담당자 정보를 파악한다.

해당 기관의 연계 기능 담당자의 성명 및 연락처, 이메일 정보를 파악한다.

3. 내부 시스템을 기준으로 외부 기관 담당자를 정리한다.

내부 시스템에 대한 외부 연계 기능과 담당자 정보를 기준으로 외부 기관에 대한 기관명

과 담당자 정보 등을 정리한다.

프로젝트

외부 기관

시스템

업무

담당자

기관명

담당자

전화번호

이메일

사용자관리

인증서 로그인

김일동

공인인증기관

이갑동

000-0000

XX@YY.ZZ

사용자관리

세금 납부 조회

김일동

국세청

이을동

000-0000

XX@YY.ZZ

사용자관리

실명 인증

김일동

행정안전부

이병동

000-0000

XX@YY.ZZ

결제관리

온라인 결제

김이동

결제대행업체

이정동

000-0000

XX@YY.ZZ

<표 2-9> 외부 기관 담당자 연락처 관리 예시

4. 관련 기관 담당자 정보를 주기적으로 현행화한다.

프로젝트 상황에 맞게 1년에 1~2회 정도 외부 기관의 담당자 정보를 현행화하여 비상 연

락 체계를 구축한다.

5. 시스템 변경 사항에 대해 관련 담당자에게 공지한다.

외부 기관에 데이터를 제공하는 경우 인터페이스 변경 및 시스템 변경 작업 등에 대해서

는 사전에 공지한다.

(1) 인터페이스 변경이 발생하는 경우

인터페이스 항목을 변경할 때에는 해당 인터페이스를 사용하는 외부 기관에 변경 사

유 및 예정 일자 등을 사전에 공지하고 연계 테스트를 진행하여 시스템 연동 오류가

발생하지 않도록 한다.

(2) 시스템 점검 등으로 데이터 제공이 불가능한 경우

시스템 점검에 대한 내용 및 기간, 제공이 불가능한 서비스 등을 외부 기관에 공유하거

나 공문을 발송하여 타 기관에서 시스템 연동과 관련된 오류가 발생하지 않도록 한다.

[그림 2-13] 시스템 점검 관련 공문 작성 예시

수행 tip

• 외부 기관 연계 시 호출하는 기관과 호출되는 기관

모두 로그를 생성하여 오류가 발생하는 경우 정확한

원인 파악이 용이하도록 구성한다.

• 응답이 없는 경우 업무 특성을 고려하여 응답 대기 시

간을 설정함으로써 불필요한 자원 낭비를 제거한다.

학습2

교수·학습 방법

교수 방법

• 타 시스템 연동 기술에 대해 설명한다.

• 타 시스템 연동 상세 설계 가이드라인 작성 방법에 대해 설명한다.

• 타 시스템 연동 상세 설계서 작성 방법에 대해 설명한다.

• 미들웨어 솔루션의 종류에 대해 설명한다.

• 시스템 연동 시 오류가 발생할 수 있는 구간 및 유형에 대해 설명한다.

• 시스템 연동 시 오류 발생 시 대응 방안에 대해 설명한다.

학습 방법

• 타 시스템 연동이 왜 필요한지 이해하고, 연동 기술에 대해 숙지한다.

• 타 시스템 연동을 위하여 필요한 정보 및 내용이 무엇인지 이해하고, 상세 설계 가이드라

인 작성 실습을 진행한다.

• 가이드라인에 대한 내용을 숙지하고 타 시스템 연동 상세 설계서를 작성함으로써 타 시스

템 연동 시 필요한 정보를 파악한다.

• 미들웨어 솔루션의 종류에 대해 미리 파악한다.

• 시스템 연동 시 오류가 발생할 수 있는 구간에 대해 이해하고, 어떤 유형의 오류가 발생

할지 미리 확인해 본 후 수업에 참여하여 상호 의견을 공유하며 토론한다.

• 시스템 연동 시 발생 가능한 오류에 대한 대응방안을 학습한 후 상호 토론 등을 통해 추

가 방안에 대해서도 검토한다.

학습2

평 가

평가 준거

• 평가자는 학습자가 학습 목표를 성공적으로 달성하였는지를 평가해야 한다.

• 평가자는 다음 사항을 평가해야 한다.

학습 내용

학습 목표

성취수준

상

중

하

아키텍처를

고려한 타 시스템

연동 설계

- 소프트웨어 아키텍처에서 정의한 타 시스템 연동 리

스트 및 연동 방안을 참조하여, 타 시스템 연동 상세

설계의 가이드라인을 작성할 수 있다.

- 소프트웨어 아키텍처의 정의를 반영한 연동 상세 설

계 가이드라인에 따라, 타 시스템 연동 상세 설계를

할 수 있다.

미들웨어 솔루션

명세 작성

- 소프트웨어 아키텍처에 따라 선정된 개발 및 운영 환

경에 사용될 기술 영역별 미들웨어 솔루션에 대하여

명세를 작성할 수 있다.

오류 예측 및

대응방안 제시

- 소프트웨어 아키텍처에 따른 시스템 간의 연동 시, 발

생할 수 있는 오류를 예측하고 대응방안을 제시할 수

있다.

평가 방법

• 평가자질문

학습 내용

평가 항목

성취수준

상

중

하

아키텍처를

고려한 타 시스템

연동 설계

- 타 시스템 연동 기술에 대한 파악

- 연동 상세 설계서를 작성할 수 있는 능력

미들웨어 솔루션

명세 작성

- 미들웨어의 개념과 종류에 대한 파악

- 미들웨어 명세서의 작성 능력

오류 예측 및

대응방안 제시

- 시스템 가용성과 이중화에 대한 파악

- 시스템 간 연동 시 발생할 수 있는 오류에 대한 파악

• 서술형시험

학습 내용

평가 항목

성취수준

상

중

하

아키텍처를

고려한 타 시스템

연동 설계

- 타 시스템 연동 상세 설계 가이드라인 작성

- 타 시스템 연동 상세 설계서 작성

미들웨어 솔루션

명세 작성

- 미들웨어의 유형과 사용 목적 서술

- 미들웨어 솔루션 명세서 포함 항목 및 내용

오류 예측 및

대응방안 제시

- 외부 기관 연동 시 오류 발생 가능 위치 및 유형

- 오류 유형에 따른 대응방안 제시

피드백

1. 평가자질문

- 타 시스템 연동 기술에 대해 다른 학습자들에게 발표 또는 설명하는 시간을 통해 성취

수준이 낮은 학습자의 실력 향상에 도움을 줄 수 있도록 한다.

- 미들웨어의 개념과 명세서 작성과 관련하여 학습자가 부족한 부분에 대해 추가 설명을

진행한다.

- 이중화 및 연동 오류에 대해 여러 학습자들에게 발표 또는 설명하는 시간을 통해 다른

학습자의 실력 향상에 도움을 줄 수 있도록 한다.

2. 서술형시험

- 타 시스템 연동 설계서 작성 항목별로 학습자가 수행한 내용을 검토하여 수행 내용의 문

제점을 식별하고 문제 유형별로 모범 답안을 제시한다.

- 미들웨어 명세서 작성 항목에 대해 모범답안 이외에 미들웨어 기술문서를 추가적으로 제

공하여 학습자가 미들웨어에 대해 이해할 수 있도록 한다.

- 연동 오류 위치 및 오류 유형에 대해 성취 수준이 높은 학습자의 답안 자료를 공유하거

나 설명하는 시간을 통해 전체 학습자의 실력 향상에 도움을 줄 수 있도록 한다.

• 지식경제부(2012). 『소프트웨어사업 요구사항 분석∙적용 가이드』

• 채흥석(2004). 『클래스 구조의 이해와 설계』. 한빛미디어.

• 채흥석(2009). 『UML과 JAVA로 배우는 객체지향 CBD 실전 프로젝트』. 한빛미디어.

• 최은만(2014). 『새로 쓴 소프트웨어 공학』. 정익사.

• 한국전산원(2004). 『정보화사업 사전타당성분석 방법론 연구』

• 한국정보화진흥원(2009). 『정보시스템 감리지침 - 시스템개발사업 구조적 정보공학적 모델 –

V1.0』

• 한국정보화진흥원(2009). 『정보시스템 감리지침 - 시스템개발사업 객체지향 컴포넌트 기반 모델

– V1.0』

• CBD SW 개발 표준 산출물 관리 가이드. NIA.

단위 시스템 공통 모듈 관리 대장

순번

시스템

기능

기 능
설명

공통모
듈ID

관 련
엔 티
티

입 력
항목

모 듈
담 당
자

출 력
(

정

상)

출 력
(Error
)

입 력
항 목
설명

출 력 항 목
/ E r r o r 설
명

전체 시스템 공통 모듈 관리 대장

순
번

시
스
템

기
능

기
능
설
명

공
통
모
듈
ID

관
련
엔
티
티

입
력
항
목

모
듈
담
당
자

출
력

(정
상)

출
력

(Er
ror

)

입
력
항
목
설
명

출
력
항

목/
Err

or
설
명