개정판 이해하기 쉬운 소프트웨어 공학†Œ프트웨어공학_미리보기.pdf ·...

이해하기 쉬운

소프트웨어 공학

윤 청 지음

개정판

소프트본문최종-1.indd 1 2014-02-26 오후 7:55:04

1 ④ 2 ① 3 ④ 4 ② 5 ④ 6 ① 7 ② 8 ① 9 ③ 10 ③

11 ③ 12 ④ 13 ③ 14 ② 15 ② 16 ④ 17 ③ 18 ③ 19 ①

기능 모델링(Functional Modeling)

기능은 입력물을 받아 결과물을 내는 활동이며, 기능을 수행하는 활동을 프로

세스라 한다. 기능 모델링은 시스템에서 요구되는 정보의 흐름과 정보의 변환

을 나타내 주는 프로세스를 중심으로 시스템을 묘사하고 있다. 이 장에서는 시

스템을 기능 관점에서 바라보고 모델링하는 대표적인 방법인 구조적 분석 기법

(Structured Analysis)에 대하여 알아본다.

● 9.1 구조적 분석 기법 개요

● 9.2 자료 흐름도(Data Flow Diagram)

•9.2.1 배경도(Context Diagram)

•9.2.2 자료 흐름도 프로세스 번호

•9.2.3 원시 프로세스(Functional Primitive)

•9.2.4 자료 흐름도의 균형(Balancing)

•9.2.5 자료 사전(Data Dictionary)

•9.2.6 구조적 분석 기법과 기능 분할

● 9.3 문제 설명서(Problem Statement)

9Chapter

소프트본문최종-1.indd 285 2014-02-26 오후 7:55:57

286 •••

시스템을 기능 관점에서 보는 것은 매우 자연스러운 일이다. 예를 들어, 현금자

동인출기(ATM)를 관찰해 보자. 사용자는 ATM이 우리에게 어떤 서비스, 즉 기

능(function)을 제공할 수 있는가를 우선 생각할 것이다. ATM은 ‘현금 인출’, ‘잔

액 조회’, ‘계좌 이체’ 등 다양한 기능을 우리에게 제공한다. 이런 기능 관점의 생

각은 시스템이 가진 정보나 동작을 파악하려는 것보다 우선한다. 결국 소프트웨

어 시스템도 기능 관점에서 바라보는 것은 본능적이고 자연스러운 모습이며, 그

결과로 기능 중심의 프로그래밍 언어인 Fortran, Cobol, Pascal, C 등이 제일

먼저 출현하였다.

기능 관점은 다양한 분야에서 아주 중요하게 사용된다. 프로젝트 관리 영역에

서 이루어지는 모든 활동도 기능들의 연속으로 이해할 수 있다. 기능은 입력물을

받아 결과물을 내는 활동이며 이를 프로세스라 한다. 앞에서 설명한 프로젝트 관

리도 프로젝트를 바로 기능 관점에서 바라본 것이며, PMBOK은 프로젝트 관리

활동을 프로세스의 연속적인 흐름으로 설명하고 있다. 소프트웨어 개발 라이프

사이클도 기능 중심의 프로세스 흐름으로 이해되어 이를 개선하려는 노력이 광범

위하게 이루어지고 있다.

소프트웨어 시스템은 받아들인 정보를 여러 단계를 거쳐 새로운 정보로 변환시

킨 뒤 내보내는 것이라 할 수 있다. 이렇게 시스템을 기능 관점에서 바라보고 시

스템에서 요구되는 정보의 흐름과 정보의 변환을 나타내는 대표적인 기능 모델이

구조적 분석 기법(Structured Analysis)이다. 구조적 분석 기법은 1979년 디마르

코(Tom DeMarco)가 도식적 기초를 사용하여 소개하였는데[DEM 79], 1980년대

부터 널리 활용되기 시작하여 지금도 요구사항 분석에 많이 사용되고 있는 기법

이다.


1. 프로세스(기능)를 정의한다.

2. 구조적 분석 기법에서 사용하는 도구를 설명한다.

3. 배경도(Context Diagram)를 정의하고 그 용도를 설명한다.

4. 자료 흐름도의 균형을 설명한다.

5. 미니 명세서를 설명한다.

6. 자료 사전의 용도를 설명한다.

학습 목표

9Chapter

구조적 분석 기법

제 4부 요구사항 분석

소프트본문최종-1.indd 286 2014-02-26 오후 7:55:57

••• 287

이 장에서는 구조적 분석 기법을 중심으로 기능 모델링에 대하여 살펴본다. 하

향식으로 시스템을 분할해 나가는 구조적 분석 기법의 개요와 구성하는 요소들에

대하여 알아본다. 특히 구조적 분석 기법에서 사용하는 자료 흐름도(DFD: Data

Flow Diagram)의 구체적인 표현 기호와 배경도, 정보 흐름, 프로세스, 자료 사전

등에 대하여 다룬다. 구조적 분석 기법의 결과가 구조적 설계로 넘어가는 변환 과

정은 자료 흐름 중심 설계에 기술되어 있다.

구조적 분석 기법 개요9.1

구조적 분석 기법의 뿌리는 구조적 프로그래밍(Structured Programming)에서

찾을 수 있다. 구조적 프로그래밍은 대부분의 경우 프로그래밍 언어 시간에 소개

된다. 이는 프로그래밍의 간결성을 유지하고 수정을 용이하게 하기 위해, 시스템

이 수행하는 기능을 모듈화시켜 분할하는 기법으로 1960년대부터 소개되어 사용

되고 있다. 그러나 그 후 구조적 프로그래밍만 가지고는 시스템 개발의 한계점에

부딪쳤고 좀 더 안정감 있는 시스템을 만들기 위해서 설계의 원칙들이 필요하게

되었다. 이에 맞추어 소개된 것이 구조적 설계 기법(Structured Design)이다.

그러나 설계의 원칙만 가지고는 더욱 복잡해지는 시스템의 기능들을 제대로 표

시하지 못하였으므로 요구사항 분석의 필요성이 대두되었고, 그 필요성에 의해

나타나게 된 것이 바로 구조적 분석 기법(Structured Analysis)이다. 이러한 일련

의 역사적 과정에서 볼 수 있듯이 소프트웨어의 진화 과정은 어떤 기법을 적용하

여 그 한계점에 부딪치면 그것을 해결하기 위해 새로운 개발 방법을 모색하는 것

Software Engineering

[그림 9.1] 시스템의 3가지 관점

정보(객체) 관점

정보(객체) 모델링(Informantion(object) Modeling)


동적 모델링(Dynamic Modeling)

기능 관점소프트웨어시스템

동적 관점


9장 기능 모델링(Functional Modeling)

소프트본문최종-1.indd 287 2014-02-26 오후 7:55:57


288 •••

이었다. 결국 소프트웨어의 개발 역사는 어떤 방법을 시도해 문제점을 발견하면

새로운 변화를 시도하는 진화 과정이라 볼 수 있다.

구조적 분석 기법은 자료 흐름도(DFD: Data Flow Diagram)를 사용하여 정보

의 흐름과 변환을 제시하며, 하향식(top-down) 방법으로 높은 차원의 기능을 작

은 기능 단위로 쪼개 나간다. 구조적 분석 기법에서 시스템은 받아들인 정보를 가

공 처리하여 새로운 정보를 내보내는 하나의 큰 프로세스(Process)이며, 이 프로

세스는 세부 기능을 수행하는 작은 프로세스들로 나누어진다. 이와 같이 시스템

이 반복적으로 분할되는 것을 자료 흐름의 상세화(data flow refinement)라 하며

[그림 9.2]에 나타나 있다.

일반적으로 큰 시스템을 상세화하면서 계층적인 배열을 두어 서로의 종속 관계

를 표시하는 것을 레벨화(leveling) 또는 계층화라 한다. 큰 시스템을 분석하기 위

해서 분할의 개념은 필수적이며 이때 요구되는 개념이 레벨화이다.

하향식(top-down) 기법인 구조적 분석 기법은 표현의 정도를 구분하고 읽기 쉽

도록 하기 위해 레벨화를 도입하고 있다. 이러한 기능 중심의 분할과 레벨화는 우

리의 주변에서도 많이 볼 수 있다. 회사의 구조를 보면 기능과 정보의 흐름을 관

리하기 위하여 여러 부서로 나누어져 있다(예를 들어 인사부, 총무부 등). 이들 부서

는 각자가 고유 기능을 수행하고 있으며, 필요하면 서로 정보를 주고받기도 한다.

[그림 9.2] 시스템의 분할

※ 이 예는 Cadre 사의 승인을 받고 Teamwork의 예제에서 발췌한 것이다.

if K D/V2=0then

for eachn check

if

if engine-runningis 'on'then

분석설계

구현시험

제품 개발

프로젝트

범위관리

일정관리

품질관리

프로젝트 관리레벨화

계층화

자료 흐름도


소프트본문최종-1.indd 288 2014-02-26 오후 7:55:57


••• 289

이들 부서들은 더욱 분할되어 각 부서는 다음 레벨에서 여러 과로 구성되어 있

고, 이들 사이에도 정보가 교류하고 있다. 한 예로 인사부의 경우 인사과, 인사기

획과, 급여과 등으로 나누어져 서로 정보를 주고받으며 업무를 수행한다.

자료 흐름도는 회사의 경우에서 볼 수 있는 것과 같이 하향식 방식으로 시스템

을 분할하고 그것을 그림으로 보여 준다(회사의 경우도 각 부서 간의 자료 흐름도를

그리면 유용하게 사용할 수 있을 것이다). 자료 흐름도를 이용하면 여러 단계를 거쳐

기능을 분할해 나갈 수 있는데, 이러한 자료 흐름도는 프로세스 사이의 데이터 흐

름을 강조하는 관점에서 시스템을 기술한 것이다.

구조적 분석 기법은 자료 흐름도 외에 각 말단 프로세스들의 기능을 설명하

는 프로세스 명세서(process specification), 자료 흐름도에 사용되는 데이터의 정

의 등을 기록하여 놓는 자료 사전(data dictionary)으로 구성되어 있다. 이 장에서

는 구조적 분석 기법의 기본 개념을 알아보고 자동속도조절장치(Perform Cruise

Control and Monitoring System)를 모델링하는 과정을 살펴보기로 한다.

자료 흐름도(Data Flow Diagram)9.2

소프트웨어 시스템은 정보를 받아들여 가공 처리하는 변환기(transformer)라고

볼 수 있고, 자료 흐름도는 정보가 입력되어 적용되는 변화와 그 결과(출력)를 그

림으로 묘사해 주는 도식적 기법이라 할 수 있다. 자료 흐름도는 기본적으로 다음

의 4가지 기호를 사용하여 표기하고 있다.

: 시스템의 외부에서 시스템과 정보를 주고받는 사용자 등의

외부 객체이다.

: 시스템 안에서 정보를 처리하고 변환시키는 변환기이며 버블

이라고도 부른다.

: 정보의 흐름을 표시하는 자료 항목 또는 데이터 단위이며 화

살표는 데이터의 흐름을 표시한다.

: 오랫동안 보관되는 데이터를 저장해 놓는 파일이나 데이터베

이스 시스템을 말한다.

외부 객체

데이터 항목

프로세스

[그림 9.3] 자료 흐름도 표기 기호

프로세스 명세서

자료 저장소


소프트본문최종-1.indd 289 2014-02-26 오후 7:55:57


290 •••

자료 흐름도는 데이터의 흐름 또는 정보의 흐름에 초점을 맞추었기 때문에 처

리의 순서나 제어는 명확하게 표시하지 못한다. 앞에서 언급되었듯이 구조적 분

석 기법은 기능 관점을 나타내고 그 외의 동적 관점, 정보 관점은 나타내지 않는

다. 이것을 보완한 것이 다음 장에 나올 확장된 자료 흐름도인데 시스템의 정보

흐름뿐만 아니라 제어의 흐름을 포함한다.

[그림 9.4]는 자료 흐름도의 간단한 예를 보여 주고 있다. 정보 흐름 a는 외부 객체

S로부터 오며 프로세스 X에 의해 정보 흐름 b로 변환된다. 계속해서 정보 흐름

b는 파일 F의 정보 흐름 d와 결합하여 프로세스 Y에 의해 새로운 정보 흐름 c를

만들어 내고 외부 객체 T에 제공된다.

이때 프로세스의 이름은 데이터의 입력과 출력에 의해 결정되어야 하며, 프로

세스에 의해 입출력 데이터 이름이 결정되는 것은 바람직하지 않다. 이는 데이터

흐름의 이름이 프로세스 이름에 우선한다는 것을 의미한다. 그러므로 “프로세스

X는 정보 흐름 a를 정보 흐름 b로 바꾸어 준다.”고 표현하는 것이 자연스러우며,

“정보 흐름 b는 프로세스 Y에 사용되기 위해 X로부터 만들어졌다.”고 불리지는

않는다.

각 프로세스는 앞에서 언급했던 것처럼 더욱 세부적으로 묘사하기 위해 분할될

수 있다. [그림 9.5]는 하나의 프로세스가 계속하여 단계별로 분할될 수 있음을 보여

주고 있다. X1부터 X5까지의 프로세스는 X의 자녀들이며, X4.1, X4.2, X4.3은 X4

의 자녀들이다.

[그림 9.4] 간단한 자료 흐름도

F

a b

d

cX TYS


소프트본문최종-1.indd 290 2014-02-26 오후 7:55:58


••• 291

자료 흐름도는 시스템을 하나의 프로세스로 놓고 외부와의 정보 흐름을 표시

하는 배경도(context diagram)로 시작하며 더 이상 쪼갤 필요가 없을 때까지 단

계별로 분할하여 나간다. 더 이상 쪼개어지지 않는 프로세스를 원시 프로세스

(functional primitive)라 한다. [그림 9.5]에서 보듯이 프로세스 X는 그 다음 단계의

그림 (X1에서 X5)로 대치될 수 있으며 X4는 그 다음 단계의 (X4.1, X4.2, X4.3) 프로세

스들로 대치될 수 있다.

따라서 배경도나 중간 과정의 프로세스들은 모두 쪼개어지지 않는 원시 프로세

스들로 대치될 수 있으며, 자료 흐름도를 그리는 목적은 이렇게 원시 프로세스와

원시 프로세스들 사이의 정보 흐름을 규명하는 것이라 볼 수 있다.

배경도(Context Diagram)9.2.1

자료 흐름도는 상위 프로세스, 중간 프로세스, 원시 프로세스들로 구성되어 있

다. 최상위의 하나로 된 프로세스를 그린 그림을 배경도라 하며, 이는 분할되기

이전 시스템을 하나의 큰 프로세스로 이해한 것이다. 배경도는 우리가 개발해야

할 시스템의 영역을 기술하고, 시스템과 외부 환경과의 경계를 결정하며, 외부와

의 인터페이스를 제시하여 시스템의 입출력 데이터를 보여 준다.

배경도는 시스템을 블랙박스로 본 것으로 시스템과 외부 환경과의 인터페이스

[그림 9.5] 프로세스의 분할

Xa

b

ca

d

e

f

b

g

he

if

g

X1

X2

X3

X4

X4.1

X5

X4.2

X4.3

원시 프로세스

배경도


소프트본문최종-1.indd 291 2014-02-26 오후 7:55:58


292 •••

에 초점을 맞춘다. 분석 초기에, 분석가는 사용자와 시스템이 상호 어떠한 데이터

를 주고받으며 어떠한 상호 교류가 일어나는지에 우선 초점을 맞추어야 한다. 배

경도가 완성되어 사용자가 무엇을 얻을 것인가를 확립하게 되면, 이를 실현시키

기 위해 시스템의 내부에 대한 분석이 이루어진다. 이는 시스템을 개발하는 데 있

어서 목표에 대한 우선순위를 부여하는 것과 같다.

배경도는 문제 설명서(Problem Statement) 또는 제안서에 기술되어 있는 데이

터와 시스템이 반응해야 하는 행위, 사건 등에서 시스템과 외부 객체 사이에 오

가는 정보를 추출하여 만들어진다. 또한 시스템의 외부에서 바라본 시스템의 모

습을 기술한다. 다음 그림은 자동차의 자동속도조절장치(Automobile Cruise

Control System)의 배경도이다.

자료 흐름도 프로세스 번호9.2.2

레벨화를 구체적으로 표시하기 위해서 각 프로세스와 자료 흐름도는 번호를 가

진다. 각 자료 흐름도는 상위 레벨의 부모 자료 흐름도와 연관된 프로세스로부터

번호를 부여받는다. 배경도의 프로세스는 최상위 프로세스로 번호 0을 가지고 있

다. 배경도의 프로세스는 분할되어 자료 흐름도로 표시되며 이 자료 흐름도에도 0

[그림 9.6] 자동속도조절장치 배경도

Driver(운전자)

Context DiagramPerform Cruise Control and Monitoring

Drive Shaft(변속기)

Shift_ Rotation

Engine(엔진)

Engine_Running

Gas Station(휘발유 통)

Fuel

Perform CruiseControl andMonitoring

0

Command

Throttle_Position

Display



소프트본문최종-1.indd 292 2014-02-26 오후 7:55:58


••• 293

이란 번호가 붙는다. [그림 9.6] 배경도의 프로세스 0은 프로세스 1, 2, 3, 4를 자녀

프로세스로 가지며, 프로세스 0은 프로세스 1, 2, 3, 4의 부모 프로세스이다. 각

프로세스의 번호는 그 프로세스를 분할하여 표시하는 자료 흐름도의 번호와 일치

하며, 이를 통해 프로세스와 자료 흐름도의 관계 및 프로세스의 구체적 세부 상황

을 보여 준다.

프로세스는 부모 자료 흐름도의 번호와 ‘.’ 그리고 프로세스 자체의 번호를 붙인

고유번호를 가지게 되고, 프로세스의 레벨은 프로세스 번호에 나오는 ‘.’의 수보다

하나가 더 많다. 예를 들어, 프로세스 4.1.3은 레벨 3에 속하며 프로세스 4.1의

자녀 프로세스이다.

다음 그림은 레벨화되어 있는 자료 흐름도를 보여 준다. [그림 9.7]은 [그림 9.6] 배경

도 프로세스의 자료 흐름도이며, [그림 9.6]과의 비교를 통해 이들이 어떻게 서로 연

결되어 있는지를 쉽게 규명할 수 있기를 바란다. [그림 9.8]은 프로세스 4(Monitor

Automobile)의 자료 흐름도이다.

[그림 9.7] 레벨 1 자료 흐름도

Diagram 0Perfrom Cruise Control and Monitoring

Shift_Rotation

Speed

ControlSpeed3

EngineRunning

Control_Command

Throttle_Position

Distance

Display

Shift_Rotation

FuelMonitorCommand

MonitorAutomobile

4

DetermineSpeed

1

MeasureMile2

Pulse_Count

_

_



소프트본문최종-1.indd 293 2014-02-26 오후 7:55:58


294 •••

[그림 9.8] 레벨 2 자료 흐름도

Distance

Diagram 4Monitor Automobile

CountMile4.1

Miles

Miles

Miles ComputeAverageSpeed4.3

Look UpMaintenanceSchedule

4.2

Monitor_Command

Fuel

Maintenance_Display

Average_Speed_Display


원시 프로세스(Functional Primitive)9.2.3

프로세스 중 더 이상 그 아래로 쪼개어지지 않는 하위 프로세스를 원시 프로세스

라 한다. 프로세스를 어디까지 쪼갤 것인가는 분석가의 손에 달려 있으며 요구사

항이 충분히 표시되어 있으면 더 이상 쪼개지 않아도 된다. 일반적으로는 하나의

프로세스가 하나의 기능을 수행할 정도로 충분히 작게 쪼개는 것이 이상적이다.

원시 프로세스의 상세한 설명은 미니 명세서(mini-specification)에 기록한다.

미니 명세서는 프로세스 명세서(process specification)라고도 한다. 프로세스에

미니 명세서가 있다는 것은 그 프로세스가 원시 프로세스라는 것을 의미한다. 미

니 명세서의 번호는 그 프로세스의 번호와 같다. 결국 완성된 미니 명세서의 수는

원시 프로세스의 개수와 일치한다. 일반적으로 미니 명세서의 내용은 한 페이지

에 요약될 수 있을 정도가 적당하다.

앞에서도 언급하였듯이 자료 흐름도의 목표는 원시 프로세스를 찾아내고, 원시

프로세스들이 서로 어떻게 연결되어 있는지를 규명하는 것이다. 원시 프로세스를

제외한 중간 과정의 프로세스들은 원시 프로세스로 대치될 수 있으므로 미니 명

세서가 필요하지 않다. [그림 9.9]는 프로세스 4.1(Count Miles)의 미니 명세서를 보

여 주고 있다. 이 프로세스는 매번 주행 마일 수가 1마일씩 증가할 때마다 전체

마일 수 및 다른 측정 거리를 증가시킨다.

원시 프로세스

미니 명세서

프로세스 명세서


소프트본문최종-1.indd 294 2014-02-26 오후 7:55:59


••• 295

[그림 9.9] 미니 명세서

[그림 9.9]의 미니 명세서가 시스템의 요구사항을 담고 있는지(what), 또는 수행하

는 방식(how to)을 제시하고 있는지에 주의하며 살펴보기 바란다. 이렇듯 구조적

분석 기법은 요구사항 명세서를 나타내는 모델이며, 시스템이 제공해야 할(또는

사용자가 알아보아야 할) 기능을 어떻게 수행하는지는 표시하지 않는다.

Name4.1

TITLECount Miles / *마일 계산*/

INPUT/OUTPUTDistance : data_inMiles : data_out

BODY/*

*이 프로시저는 매 주행 마일마다 측정하는 마일 수를

*1마일씩 증가시킨다.

*/FOR EACH Distance Cummulative_Distance= Cummulative_Distance + Distance IF Cummulative_Distance ＞= 1 Mile THEN Increment MPG_Mileage Inerement Miles_Since_Oil_Change Increment Miles_Since_Air_Filter_Change Increment Miles_Since_Major_Service Increment Trip_Mileage Reset Cummulative_Distance END IF


소프트본문최종-1.indd 295 2014-02-26 오후 7:55:59


296 •••

자료 흐름도의 균형(Balancing)9.2.4

부모 자료 흐름도의 정보 입출력은 자녀 자료 흐름도의 입출력과 같아야 하는

데 이는 정보 흐름의 연속성을 유지하기 위하여 필요하다. 이러한 제약 조건을 자

료 흐름도의 균형이라 부른다.

[그림 9.6]의 배경도 입출력과 자녀 자료 흐름도의 입출력은 균형이 이루어

져 있는가? Display, Shift_Rotation, Engine_Running, Fuel, Throttle_Position 등은 [그림 9.6]과 [그림 9.7]에서 동일하게 발견되고 있다. 그러나 [그림 9.6]

의 Command는 [그림 9.7]에서 발견되지 않으며 대신 Control_Command와

Monitor_Command로 나타나 있다. 그렇다면 이 그림은 균형이 이루어져 있는가?

만약 Command가 Control_Command와 Monitor_Command의 결합으

로 이루어져 있다고 명시되어 있으면 이 자료 흐름도는 균형을 이루고 있다고 할

수 있다. 이러한 균형의 형태는 상위 레벨에서 많은 데이터를 묶어 하나로 표시하

고 하위 레벨로 내려가면서 쪼개어 표시하는 것에서 나타난다. 이러한 방법은 읽

기 쉽다는 장점이 있다. 균형에 대한 정보는 자료 사전(Data Dictionary)에 정의

하여 놓는다. 결국 Command가 Control_Command와 Monitor_Command로 이루어져 있다는 것이 자료 사전에 표시되어 있으면, 이 자료 흐름도는 균형을

이루고 있는 것이다. 자료 사전에 이 관계가 나타나지 않은 경우 이 자료 흐름도

는 불균형의 상태에 있다고 할 수 있다.

자료 사전(Data Dictionary)9.2.5

자료 흐름도로 표시되어 있는 시각적인 정보는 체계적이며 조직적으로 모아져

야 한다. 자료 사전은 자료 흐름도에 나타난 데이터에 관한 정보를 한곳에 모아

놓음으로써 개발자나 사용자들이 편리하게 사용할 수 있게 해 준다. 자료 사전은

메타데이터(metadata), 즉 데이터에 대한 데이터를 모아 놓는 저장소이며 데이터

항목, 데이터 흐름 등에 관한 정의가 포함되어 있다. 자료 사전에서 사용되는 기

호는 다음과 같다.

자료 사전

자료 흐름도의

균형


소프트본문최종-1.indd 296 2014-02-26 오후 7:55:59


••• 297

자료 사전에 들어가는 예들은 다음과 같다.

Command = Control_Command + Monitor_CommandEngine_Running = [“ON”|“OFF”]

구조적 분석 기법과 기능 분할9.2.6

시스템의 중요 요소나 기능을 찾아내어 분할해 나가는 것은 분석가의 임무이

며 일반적으로 쉬운 일이 아니다. 시스템을 어떻게 분할해 나갈 것인가는 간단한

문제가 아니다. 또한 어떻게 분할하면 좋은지에 대한 완벽한 가이드라인조차 없

다. 구조적 분석 기법(Classical Structured Analysis)은 이들 기능을 분할하는 일

반적인 방법을 제시해 주고 있다. 이 기법이 잘 적용되지 않는 경우에 이용할 수

있는 또 다른 방법으로서의 사건 분할(event partitioning) 방식은 시스템과 외

부 객체 사이의 상호 교류하는 사건을 이용하여 시스템을 분할하여 자료 흐름도

를 그려 나가는 것이다. 이러한 사건 분할 방식은 모던 구조적 분석 기법(Modern

Structured Analysis)에서 제안되었다.

하향식(top-down) 접근 방법인 구조적 분석 기법에 유스케이스(use case)를 적

용하여 분석할 수 있다. 유스케이스에 의한 분석 방법은 우선 시스템을 사용자의

관점에서 바라보아 시스템을 사용하는 사용자들이 볼 수 있는 기능만을 밝혀낸

다. 그 다음 이 기능들을 사용하여 ‘다이어그램 0’에서부터 가장 아래 프로세스까

지 분할한다. 결국 사용자가 이용 가능한 기능에서 출발하여 시스템의 중요 요소

들을 찾아 내려가며 분할한다. 이런 접근 방법을 사용하면 시스템의 분석이 사용

자의 관점에서 이루어질 수 있다. 또한 사용자가 볼 수 있는 기능은 다른 기능보

다 찾아내기 쉬우며, 사용자들도 분석 과정에 참여하며 그 결과를 쉽게 이해할 수

있다는 장점이 있다.

[그림 9.10] 자료 사전 기호

연산자 예 의미

= a = b + c a 는 b + c로 구성된다

+ a + b AND: a와 b의 합성

[ | ] [ a | b ] OR: a와 b 중 하나 선택

{ } 3{ a }5 a를 3번에서 5번 사이 반복

( ) ( a ) a는 선택적 (0{ a }1과 동일)



소프트본문최종-1.indd 297 2014-02-26 오후 7:55:59


298 •••

분할

분석이란 문제를 쪼개서 정복하는(divide and conquer) 과정이다. 분석은 어떤 것을 그 기본 요소들로 분해하

는 것과 관련되어 있고 이에 요구되는 개념이 세분화 또는 분할(partitioning)이다. 이 개념은 우리의 지식을 체

계적으로 정돈하기 위해 필요하며 추상화와 공통적 특성을 이용하여 더 작고 단순한 것들로 나누는 것이다. 불

행하게도 분할에 정도(正道)는 없으며 분할되어 나타나는 프로세스나 객체들을 쉽게 찾아낼 수 있는 간단한 해

결 방법은 없다.

시스템을 어떻게 분할해 나갈 것인가의 문제는 시스템을 개발하는 대부분의 사람들에게 어렵게 느껴지는 문

제이다. 기존의 분할에 사용할 수 있는 정보가 있는 경우 이를 활용할 수도 있다. 회사 업무를 위한 시스템을 만

들 때 회사의 조직(인사부, 자재부 등)은 기능 중심으로 이미 분류되어 있는 경우가 많고 이를 활용하여 시스템을

분할해 나갈 수도 있다. 만약 기존의 정보가 없이 새로운 시스템을 만들어 나갈 경우 분할은 더욱 어려운 문제

로 느껴진다.

회사의 분류 방법을 살펴보면 기능을 수행하는 조직들은 내부가 단단히 뭉쳐져 있고 외부 조직과의 결합은 최

소화되도록 만들어져 있음을 볼 수가 있다. 이는 시스템 요소들이 만들어질 때 응집력(cohesion)이 극대화되고

요소들 사이의 결합도(coupling)는 최소화되도록 설계되어 있음을 볼 수 있다. 일반적으로 시스템 분할에서 추구

하는 중요한 목표는, 요소들이 독립성을 가지며 요소 내부의 결합도가 높고 외부와의 결합은 최소화되도록 시스

템을 설계하는 것이다.

모델링의 결과는 과학적인 사실에 근거하여 엔지니어의 관점이 반영된 균형 잡힌 예술품이 되어야 한다. 모델

링은 엔지니어의 과학적인 기술은 물론 문화, 얼이 같이 섞여 어우러진 합작품이라 볼 수 있다. 모델링은 업무 분

야나 만들고자 하는 시스템에 대한 전문적인 지식을 가진 전문가가 하는 것이 바람직하며, 그렇지 못한 경우 정

확하지 못한 분할이 이루어져 시스템 전체에 큰 손실을 끼치게 된다.

Software 산책 ❶

문제 설명서(Problem Statement)9.3

시스템을 개발하려고 할 때 우선되어야 하는 첫 번째 단계는 시스템의 요구사

항을 기술하는 일이다. 일반적으로 프로젝트를 계획하거나 계약할 시기에는 모

든 구체적인 요구사항이 정의되기 어려우며 추상적인 시스템의 목적만을 나열한

문제 설명서(문제 기술) 또는 제안서로 일이 시작되는 경우가 많다.

문제 설명서에 포함되어야 하는 내용은 다음과 같다.

1. 해결하려는 문제점에 대하여 명확히 기술해야 한다. 현재의 상황, 배경, 시

스템 개발의 필요성, 문제 제약 조건, 달성하려는 목표에 대한 기술이 포함

되어야 한다. 문제 설명서는 고객의 관점에서 고객이 사용하는 용어로 기술

문제 설명서

제안서


소프트본문최종-1.indd 298 2014-02-26 오후 7:55:59


••• 299

1. 연구·개발의 필요성

가. 국내·외 기술 개발 현황

나. 연구·개발하려는 기술(또는 연구·개발 내용)의 수준

다. 문제점

라. 앞으로의 전망

마. 연구·개발의 중요성

2. 연구·개발 목표

3. 연구·개발 내용 및 범위

4. 연구 결과물

5. 추진 전략 및 방법

6. 지금까지의 연구·개발 실적

7. 기대 성과 및 활용 방안

8. 인원 편성표

9. 연구·개발 기자재 현황

10. 연구 추진 일정 계획

11. 소요 예산 명세

12. 참고 문헌

되어야 한다.

2. 자동화하는 데 요구되는 추진 전략 및 방법을 기술한다. 적용하고자 하는 개

발 방법론 및 접근 방법 등이 구체적으로 기술된다.

3. 제공되어야 할 기능, 만들어질 시스템의 제약 조건, 요구되는 하드웨어, 연

관된 소프트웨어, 일의 범위 등을 기술한다.

4. 시스템 차원의 목표, 개발 과정에서 요구되는 사항, 결과물 등이 기술된다.

5. 추상적인 차원(high-level)에서 합격 판정 검증 기준을 확립하여 기술한다.

6. 시스템이 개발되었을 때 예상되는 기대 효과 및 활용 방안을 기술한다.

우리나라에서 흔히 연구 또는 개발에 사용하는 제안서의 양식은 다음과 같다.

문제 설명서를 쓰는 과정은 일반적으로 계획 단계에서 이루어진다고 볼 수 있

다. 문제 설명서는 문제를 이해하기 위한 출발점이기 때문에 완벽한 문서일 수 없

다. 따라서 문제 설명서 뒤에 이루어지는 요구사항 분석은 문제점을 완벽하게 이


소프트본문최종-1.indd 299 2014-02-26 오후 7:56:00


300 •••

해하기 위한 노력이라 볼 수 있다.

문제 설명서는 일반적으로 완벽하거나 구체적이지 못하여 이를 사용해 시스템

을 검증하는 일은 쉽지 않다. 2장에서 언급한 것과 마찬가지로 제안서는 사회에

서의 헌법에 해당되며 제안서의 목적을 구체적으로 분석한 요구사항 명세서는 법

률에 해당된다고 볼 수 있다. 따라서 요구사항 명세서는 시스템을 검증할 수 있는

구체적인 기준을 제시해 주어야 한다.

다음은 현금자동지급기(ATM) 문제 설명서로는 부적당하다. 그 이유를 생각해

보라.

다음은 ATM 문제 설명서로 적당하다. 위의 예와 비교하여 생각해 보라.

고객이 ATM을 사용하고자 할 때는 ATM 카드 구멍에 카드를 넣어야 한다.

ATM은 현금 카드로부터 고객 번호를 읽어 들이고 유효 일자와 소속 은행 등을

조사하여 유효한 카드인지 검증한다. 만약 유효한 카드이면 고객이 PIN 번호(암

호)를 넣기를 요구한다. 만약 고객이 정확한 PIN 번호를 넣으면 고객의 요구를

처리하게 된다. 만약 PIN 번호가 잘못되었으면 ATM은 고객에게 PIN 번호를

넣도록 요구한다. ATM은 고객에게 3번의 기회를 주며 3번째에도 틀리게 되면

현금 카드를 압수하고 합당한 메시지를 고객에게 보여 준다.

고객은 ATM을 사용하여 그의 구좌에서 현금을 찾을 수 있다. ATM은 고객의

요구를 처리하기 전에 현금 카드와 암호를 읽어 유효한 카드인지 검증한다. 한

번에 찾을 수 있는 현금의 한계가 있으며 현금의 지불이 허용되면 현금과 영수증

을 고객에게 지불한다.


소프트본문최종-1.indd 300 2014-02-26 오후 7:56:00


••• 301

무엇(What)과 어떻게(How to)

이 책은 ‘무엇’(What)을 만들 것인가와 ‘어떻게’(How to) 만들 것인가를 구별하는 것의 중요성을 설명하고, 무

엇을 만들 것인가에 우선순위를 두라고 제시하고 있다. 앞에서 설명하였듯이 요구사항 명세서에는 ‘무엇’을, 설

계 명세서에는 ‘어떻게’를 기술하여야 한다. 그러나 실제 개발에 있어서 ‘무엇’과 ‘어떻게’가 명확히 구별되지 않

는 경우가 많다.

만약 최적화된 해답을 구하는 문제에서 주경로(critical path) 또는 임계 경로를 구하는 알고리즘이 있다고 하

자. 이 알고리즘을 요구사항 명세서에 넣는 것이 맞는지, 설계 명세서에 넣는 것이 옳은지 생각해 보라. 디자이

너가 더 좋은 알고리즘을 구하거나 만들 수 있다면 이 알고리즘은 요구사항 명세서에 들어가면 안 된다. 만약 이

문제에 대한 해답이 이 알고리즘 하나밖에 없으면(unique) 요구사항 명세서에 들어갈 수도 있다. 문제를 해결하

는 방법이 오직 하나이거나, 이 방법을 쓰기로 모든 사람이 이미 동의하고 추후에도 바꿀 가능성이 전혀 없는 경

우 요구사항 명세서에 기록할 수 있다.

필자의 경험을 하나 들겠다. 연구소 시절 분산 데이터베이스의 병렬제어(concurrency control)를 위한 요구사

항 명세서를 쓰게 되었다. 요구사항 명세서에 병렬제어를 위한 로킹(locking) 알고리즘을 포함하여 기술하였다.

데이터베이스의 병렬제어 해결 방법으로는 로킹, 타임 스탬프(time stamp) 등의 여러 기법이 있다. 필자의 상사

는 요구사항 명세서에서 이 알고리즘을 지우기를 권유하며, 이는 개발자(developer)들이 결정할 문제라고 충고

하였다.

시스템을 개발하면서 해결 방법이 하나밖에 없어 추후 변할 가능성이 없는 것은 일종의 프로그램이라 하더라

도 요구사항 명세서에 기록될 수 있다. ‘무엇’과 ‘어떻게’를 굳어 있는 틀로 해석해서는 안 된다. ‘무엇’과 ‘어떻게’

를 구별하는 것은 우선순위를 두고 체계적인 엔지니어링을 하기 위한 것이 목적이지, 그것을 구별하는 것 자체

가 목적은 아니기 때문이다.

Software 산책 ❷


소프트본문최종-1.indd 301 2014-02-26 오후 7:56:00


302 •••

요약

요구사항 분석에 가장 많이 사용되는 구조적 분석 기법은 정보의 흐름과 정보의 변환을 도

식화시켜 나타내는 모델이다. 구조적 분석 기법은 시스템과 외부와의 정보 흐름에서 시작하

여 하향식으로 시스템의 기능을 분할해 나간다. 이것은 우리가 지금까지 해 왔던 구조적 프로

그래밍 및 구조적 설계와 깊은 관계가 있다.

구조적 분석 기법에서 나온 결과는 다음 단계인 설계 단계에서 필요로 하는 시스템의 골격

을 제공한다. 자료 흐름도의 각 프로세스는 설계에서 필요로 하는 모듈(또는 모듈들)로 될 가

능성이 높으며, 이 경우 각 정보 흐름은 모듈들 사이의 매개 변수로 나타난다. 구조적 설계는

응용 분야의 관점에서 컴퓨터 관점으로 이동하여, 구조적 분석의 결과에 살을 붙여가는 과정

이다.

현재 구조적 분석 기법을 지원하는 많은 CASE 도구들이 상업화되어 활용되고 있으며, 이

들 도구들은 모델의 무결성 및 오류에 대한 검증 등을 해결해 준다. 구조적 분석 기법의 실시

간용 확장은 다음 장에서 소개되는데, 이 기법들은 복잡한 문제들에 효과적으로 적용할 수 있

는 더욱 강력한 분석 도구로 발전하였다. 또한 이들 도구들은 요구사항 분석의 결과를 체계적

으로 문서화할 수 있게 해 주고 수정을 용이하게 하여 문서 관리에 많은 도움을 주고 있다.

[BOO 94] Booch, G., Object-Oriented Analysis and Design with Applications, Benjamin/Cummings,

1994.

[CAD 90] “An Introduction to TeamWork Release 4.0”, CORE Product Training Workbook, 1990.

[DEM 79] Demarco, T., Structured Analysis and System Specification, Yourdon Press, 1979.

[JAC 92] Jacobson, I., Object-Oriented Software Engineering, Addison-Wesley, 1992.

[MIR 96] Mirza, M., 차승훈, 정재일, 이기종, 윤청, “Use Case Driven Structured Analysis”, Proceedings

of IEEE COMSAC Conference, 1996.

[MYN 90] Mynatt, B., Software Engineering with Student Project Guidance, Prentice Hall, 1990.

[PRE 92] Pressman, R., Software Engineering : A Practitioner’s Approach, McGraw-Hill, 1992.

[YOU 79] Yourdon, E., and Constantine L., Structured Design, Yourdon Press, 1979.

[YOU 89] Yourdon, E., Modern Structured Analysis, Yourdon Press, 1989.

[왕창종 92] 왕창종, 구연설, 이언배, 『구조적 시스템 분석과 설계 기법』, 정익사, 1992.

[우치수 94] 우치수, 『구조적 기법 소프트웨어 공학』, 상조사, 1994.

참고 문헌


소프트본문최종-1.indd 302 2014-02-26 오후 7:56:00


[ 연습 문제 ]

프로세스(Process)에 대한 설명으로 틀린 것은?

① 시스템은 받아들인 정보를 가공 처리하여 새로운 정보를 내보내는 하나의 큰

프로세스(Process)이다.

② 큰 프로세스는 세부 기능을 수행하는 작은 프로세스들로 나누어진다.

③ 프로세스는 입력물을 받아 결과물을 내는 활동이며, 기능을 수행하는 활동

이다.

④ 프로세스는 정보와 오퍼레이션의 묶음이다.

프로세스 정의에 대한 설명 중 옳은 것은?

① 동적 행위를 일으키는 주체

② 시간에 종속적인 프로그램

③ 객체의 속성

④ 입력물을 받아 결과물을 내는 활동과 기능

DFD(Data Flow Diagram)에 대한 설명으로 거리가 먼 것은?

① 자료 흐름 그래프 또는 버블(Bubble) 차트라고도 한다.

② 구조적 분석 기법에 이용된다.

③ 시간 흐름의 개념을 명확하게 표현할 수 있다.

④ DFD의 요소는 화살표, 원, 사각형, 직선(단선/이중선)으로 표시한다.

자료 흐름도(DFD)의 구성 요소가 아닌 것은?

① 프로세스

② 데이터 저장소

③ 데이터 사전

④ 데이터 흐름

객관식 문제

1

2

3

4

••• 3039장 기능 모델링(Functional Modeling)

소프트본문최종-1.indd 303 2014-02-26 오후 7:56:00

[ 연습 문제 ]

자료 흐름도의 핵심 요소는?

① 프로세스와 자료 흐름

② 상태와 사건

③ 엔티티와 관계

④ 객체와 클래스

미니 명세서(Mini-Specification)에 관한 내용 중 옳지 않은 것은?

① 원시 프로세스의 상세한 설명이다.

② 프로세스 명세서(process specification)라고도 한다.

③ 미니 명세서가 있다는 것은 그 프로세스가 원시 프로세스라는 것을 의미한다.

④ 미니 명세서의 번호는 그 프로세스의 번호와 다르다.

미니 명세서에 관한 내용 중 옳지 않은 것은?

① 일반적으로 미니 명세서의 내용은 한 페이지에 요약될 수 있을 정도가 적당

하다.

② 미니 명세서는 구조적 언어를 사용하지 않고, 자연어를 사용하여 이해하기 쉽

고 엄밀하게 기술한다.

③ 원시 프로세스를 제외한 중간 과정의 프로세스들은 원시 프로세스로 대치될

수 있으므로 미니 명세서가 필요하지 않다.

④ 미니 명세서 작성에는 서술문장, 의사결정나무, 의사결정표, 표, 그래프 등을

사용한다.

자료 흐름도의 목표는?

① 원시 프로세스를 찾아내고, 원시 프로세스들이 서로 어떻게 연결되어 있는지

를 규명하는 것이다.

② 원시 프로세스를 제외한 중간 과정의 프로세스들에 대한 미니 명세서를 작성

하는 것이다.

③ 시스템이 제공해야 할 기능을 어떻게 수행하는지 표시하는 것이다.

④ 시스템의 동작을 보여 주는 것이다.

5

6

7

8

304 ••• 제 4부 요구사항 분석

소프트본문최종-1.indd 304 2014-02-26 오후 7:56:00


자료 흐름도의 자료 사전(Data Dictionary)에서 필수가 아닌 선택을 의미하는 기호는?

① = ② { }

③ + ④ ( )

배경도(Context Diagram)에 대한 설명으로 틀린 것은?

① 최상위의 하나로 된 프로세스를 그린 그림을 말하며, 이는 시스템이 분할되기

이전의 프로세스이다.

② 배경도는 우리가 개발해야 할 시스템의 영역을 기술하고, 시스템과 외부 환경

과의 경계를 결정하며, 외부와의 인터페이스를 제시하여 시스템의 입출력 데

이터를 보여 준다.

③ 배경도는 시스템을 화이트박스로 본 것이며 시스템 내부 인터페이스에 초점을

맞춘다.

④ 배경도는 사용자가 무엇을 얻을 것인가를 보여 주는 그림이다.

자료 흐름도의 균형(Balancing)에 대한 설명 중 틀린 것은?

① 하위 레벨에서 많은 데이터를 묶어 하나로 표시하고 상위 레벨로 올라가면서

쪼개어 표시하는 것이다.

② 부모 자료 흐름도의 정보 입출력은 자녀 자료 흐름도의 입출력과 같아야 한다.

③ 정보 흐름의 연속성을 유지하기 위하여 필요하다.

④ 균형에 대한 정보는 자료 사전에 정의하여 놓는다.

자료 흐름도의 자료 사전에 대한 설명으로 합당하지 않은 것은?

① 자료 흐름도로 표시되어 있는 시각적인 정보를 체계적이며 조직적으로 모아

놓는 것이다.

② 데이터에 관한 정보를 한곳에 모아 놓음으로써 개발자나 사용자들이 편리하게

사용할 수 있게 해 준다.

③ 메타데이터(metadata), 즉 데이터에 대한 데이터를 모아 놓는 저장소이며 데이

터 항목, 데이터 흐름 등에 관한 정의가 포함되어 있다.

④ 원시 프로세스들 사이의 정보 흐름을 설명하는 것이다.

9

10

11

12


소프트본문최종-1.indd 305 2014-02-26 오후 7:56:00

[ 연습 문제 ]

구조적 분석 기법을 정의하라.

기능 모델링은 시스템을 어떤 관점에서 묘사하는가?

구조적 분석 기법과 구조적 프로그래밍의 관계를 설명하라.

구조적 분석 기법에서 사용하는 도구들을 열거하라.

구조적 분석 기법의 분할 방식에 대하여 기술하라.

구조적 분석 기법의 레벨화와 여러분이 속한 조직의 레벨화와 연관지어 보고 여러분이

속해 있는 조직의 자료 흐름도를 그려라.

프로세스 명세서, 제어 명세서, 자료 사전, 배경도(Context Diagram)를 정의하라.

시스템 경계(System boundary)를 정의하고 그 중요성을 설명하라.

원시 프로세스와 미니 명세서의 수는 어떤 관계가 있는가?

자료 흐름도의 균형이란 무엇이며 왜 필요한가?

자료 사전의 용도는 무엇인가?

문제 설명서(Problem Statement)와 요구사항 명세서의 역할 분담에 대하여 논의하라.

앞에서 다루었던 자판기의 기능에 다음과 같은 기능이 추가될 때의 자료 흐름도를 작성

하라.

•크레디트 카드를 넣을 수 있는 기능

• 자판기의 물건이 떨어지거나 문제가 발생하였을 때 관리자를 호출할 수 있는 기능

객관식 문제주관식 문제

1

2

3

4

5

6

7

8

9

10

11

12

13

306 ••• 제 4부 요구사항 분석

소프트본문최종-1.indd 306 2014-02-26 오후 7:56:01


자판기의 편리함을 위해 추가할 수 있는 기능들을 3가지만 써라.

CD 1백 장을 수록하고 일정 금액을 넣고 즉석에서 음악을 들을 수 있는 음악 자판기의

문제 설명서를 작성하고 자료 흐름도와 자료 사전을 사용하여 요구사항 명세서를 작성하라.

즉석에서 자신이 원하는 명함을 만들 수 있는 컬러 명함 자판기의 문제 설명서를 작성하

고 자료 흐름도를 사용하여 요구사항을 분석하라.

앞의 질문들에서 자판기의 재사용 가능한 구성 요소들을 식별해 보라.

사거리 신호등 시스템에 대한 문제 설명서를 작성하고 요구사항 명세서는 자료 흐름도를

사용하여 작성하라.

프로세스와 모듈의 차이점을 기술하라.

현금자동교환기(ATM) 시스템에 대한 문제 설명서를 작성하고 요구사항 명세서는 자료

흐름도를 사용하여 작성하라.

구조적 설계 기법을 이용하여 현금자동교환기의 분석 결과를 설계하라.

엘리베이터에 대한 문제 설명서를 작성하고 자료 흐름도를 사용하여 요구사항 명세서를

작성해 보라.

구조적 설계 기법을 이용하여 엘리베이터의 분석 결과를 설계하라.

고속도로 통행료 징수 시스템(tollway system) 대한 문제 설명서를 작성하고 자료 흐름도

를 사용하여 요구사항 명세서를 작성해 보라.

구조적 설계 기법을 이용하여 고속도로 통행료 징수 시스템의 분석 결과를 설계하라.

14

15

16

17

18

19

20

21

22

23

24

25

1 ④ 2 ④ 3 ③ 4 ③ 5 ① 6 ④ 7 ② 8 ① 9 ④ 10 ③ 11 ① 12 ④

객관식 문제 정답


소프트본문최종-1.indd 307 2014-02-26 오후 7:56:01

개정판 이해하기 쉬운 소프트웨어 공학†Œ프트웨어공학_미리보기.pdf ·...

Documents