분석모델 확인

분석 모델은 왜 만들고 왜 확인할까요

요구사항을 문장으로만 적어 두면 양이 많아질수록 전체 모습이 잘 보이지 않습니다. 어떤 데이터가 어디서 와서 어디로 가는지, 어떤 기능이 어떤 순서로 이어지는지가 문장 사이에 흩어지기 때문입니다. 그래서 요구사항을 그림과 표로 정리한 분석 모델을 만듭니다. 지하철 노선도가 역 이름 목록보다 길 찾기에 훨씬 편한 것과 비슷합니다.

분석 모델 확인은 이렇게 만든 모델이 요구사항을 빠짐없이, 앞뒤가 맞게 담고 있는지 점검하는 일입니다. 요구사항 하나가 어느 모델에도 나오지 않거나, 두 모델이 같은 데이터를 다르게 부르고 있다면 설계로 넘어가기 전에 바로잡아야 합니다. 이 항목에서는 모델을 그리는 기법, 모델 작업을 돕는 자동화 도구, 그리고 요구사항의 변경을 관리하는 도구를 차례로 봅니다.

모델링 기법 ① 구조적 분석: 데이터의 흐름을 따라가기

구조적 분석은 시스템을 '데이터가 들어와 처리되고 나가는 흐름'으로 보고, 큰 기능을 점점 작은 기능으로 나눠 가며 분석하는 방법입니다. 이때 쓰는 대표 도구가 다섯 가지입니다. 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec), 개체 관계도(ERD), 상태 전이도(STD)입니다.

자료 흐름도(DFD)는 데이터가 어떤 처리 과정을 거쳐 흘러가는지를 그린 그림입니다. 네 가지 기호만 씁니다. 데이터를 바꾸는 처리 과정인 프로세스는 원, 데이터가 움직이는 길인 자료 흐름은 화살표, 데이터가 머무는 곳인 자료 저장소는 위아래 평행선, 시스템 바깥에서 데이터를 주거나 받는 대상인 단말(터미네이터)은 사각형으로 그립니다. DFD는 처리의 순서나 조건보다 '무엇이 어디로 흐르는가'에 집중하며, 가장 큰 그림(배경도)에서 시작해 프로세스를 단계적으로 쪼개 더 자세한 DFD를 그려 내려갑니다.

자료 사전(DD)은 DFD에 나오는 데이터의 뜻과 구성을 정확히 정의한 사전입니다. 정해진 기호를 씁니다. '='는 '무엇으로 이뤄진다(정의)', '+'는 '그리고(연결)', '( )'는 생략할 수 있음, '[ | ]'는 여러 개 중 하나를 고름(선택), '{ }'는 반복, '* *'는 설명(주석)을 뜻합니다. 예를 들어 '주소 = 시도 + 시군구 + (상세주소)'처럼 적습니다.

소단위 명세서(Mini-Spec)는 DFD의 가장 작은 프로세스 하나가 안에서 무엇을 하는지를 구조적인 문장이나 의사결정표 같은 형태로 적은 것입니다. 개체 관계도(ERD)는 데이터들 사이의 관계를, 상태 전이도(STD)는 시스템이 사건에 따라 어떤 상태로 바뀌는지를 보여 줍니다.

모델링 기법 ② 객체지향 분석: 객체를 중심으로 보기

객체지향 분석은 시스템을 데이터와 그 데이터를 다루는 기능을 함께 묶은 객체들의 모임으로 보는 방법입니다. 여러 학자가 각자의 방법을 내놓았기 때문에 이름과 특징을 짝지어 기억하는 것이 좋습니다.

럼바우(Rumbaugh)의 방법은 OMT(Object Modeling Technique)라고도 하며, 분석을 세 단계 모델링으로 나눕니다. 먼저 객체 모델링으로 시스템에 어떤 객체가 있고 서로 어떤 관계인지를 객체 다이어그램으로 그립니다. 다음 동적 모델링으로 시간에 따라 객체의 상태가 어떻게 바뀌는지를 상태 다이어그램으로 그립니다. 마지막 기능 모델링으로 데이터가 어떻게 처리되는지를 자료 흐름도(DFD)로 그립니다. '객체 → 동적 → 기능' 순서와 각 단계의 그림을 함께 묶어 외워 두세요.

다른 방법들도 핵심만 알아 둡니다. 부치(Booch) 방법은 미시적 개발 과정과 거시적 개발 과정을 함께 다룹니다. 야콥슨(Jacobson) 방법은 사용자가 시스템으로 하려는 일을 유스케이스로 정리해 분석의 중심으로 삼습니다. 코드-요돈(Coad-Yourdon) 방법은 데이터베이스 설계에서 익숙하게 쓰던 E-R 다이어그램 표기를 가져와 객체와 그 활동을 표현했다는 점이 특징입니다. 워프스-브록(Wirfs-Brock) 방법은 분석 단계와 설계 단계 사이에 선을 긋지 않고, 고객이 준 명세를 검토하는 일에서 출발해 설계까지 한 흐름으로 이어 간다는 점을 기억하면 됩니다. 이 학자들 중 럼바우, 부치, 야콥슨의 방식을 하나로 합친 것이 앞 항목에서 본 UML입니다.

분석자동화 도구: CASE

모델이 커지면 사람 손으로 그리고 고치고 서로 맞는지 검사하는 일이 금방 벅차집니다. DFD의 화살표 이름이 자료 사전에 있는지 일일이 대조하는 것만 해도 큰일입니다. 그래서 분석 작업을 컴퓨터로 돕는 도구를 쓰는데, 이를 분석자동화 도구라고 하며 흔히 CASE(Computer Aided Software Engineering) 도구라고 부릅니다.

CASE 도구는 모델을 그리는 일뿐 아니라, 모델 사이의 일관성과 오류를 자동으로 검사하고, 분석 내용을 문서로 만들어 주며, 변경 내용을 여러 산출물에 함께 반영하도록 돕습니다. 그 결과 분석 품질이 올라가고, 여러 사람이 같은 모델을 공유하며 일하기도 쉬워집니다.

CASE 도구는 개발 과정의 어느 부분을 돕느냐에 따라 나뉩니다. 상위(Upper) CASE는 요구사항 분석과 설계 같은 앞쪽 단계를 돕습니다. 모델 작성과 오류·일관성 검사가 주된 기능입니다. 하위(Lower) CASE는 코드 작성, 테스트, 문서화 같은 뒤쪽 단계를 돕습니다. 통합(Integrated) CASE는 앞뒤 단계를 모두 아울러 지원합니다.

시험에 이름이 나오는 대표 도구도 있습니다. SADT는 구조적 분석과 설계를 위한 도구로, 기능을 상자(블록)로 그려 계층적으로 나눠 표현합니다. SREM은 실시간 처리 소프트웨어의 요구사항을 정해진 언어(RSL)로 적고 이를 분석하는 도구(REVS)를 갖춘 방법입니다. PSL/PSA는 요구사항을 문서화하는 언어(PSL)와 이를 분석하는 도구(PSA)로 이뤄져 있습니다. 이 밖에 TAGS는 요구사항 분석에 그치지 않고 시스템 공학적 접근으로 개발 주기 전 과정을 지원하는 도구로 소개됩니다.

요구사항 관리 도구: 바뀌는 요구사항 붙잡기

요구사항은 한 번 정해도 개발 중에 계속 바뀝니다. 고객이 마음을 바꾸기도 하고, 만들다 보니 처음 생각과 다른 사정이 드러나기도 합니다. 문제는 바뀌는 것 자체보다, 무엇이 언제 왜 바뀌었고 그 변경이 어디에 영향을 주는지 모르는 상태입니다. 요구사항 관리 도구는 이런 혼란을 막기 위해 요구사항을 체계적으로 저장하고 변경을 관리해 주는 도구입니다.

요구사항 관리 도구가 하는 대표적인 일은 다음과 같습니다. 요구사항마다 고유 번호와 우선순위, 상태(제안, 승인, 구현됨 등)를 붙여 관리합니다. 누가 언제 무엇을 바꿨는지 변경 이력과 버전을 남깁니다. 그리고 요구사항이 어느 설계, 코드, 테스트와 이어져 있는지를 기록하는 추적성(Traceability)을 관리합니다. 추적성이 있으면 요구사항 하나가 바뀔 때 함께 고쳐야 할 설계와 테스트를 바로 찾을 수 있고, 반대로 어떤 코드가 왜 존재하는지도 거꾸로 따라갈 수 있습니다.

변경은 아무 때나 마음대로 반영하지 않습니다. 확인을 마친 요구사항 묶음을 기준(베이스라인)으로 정해 두고, 변경 요청이 들어오면 영향 범위와 비용을 분석한 뒤 승인을 거쳐 반영합니다. 이것을 변경 통제라고 합니다. 요구사항 관리 도구는 이 요청과 승인 과정을 기록으로 남겨 줍니다.

도구를 고를 때는 기능, 비용, 다른 개발 도구(설계 도구, 이슈 관리 도구 등)와 연동되는지, 여러 사람이 동시에 쓰기 편한지를 따집니다. 작은 프로젝트라면 표 문서로도 관리할 수 있지만, 요구사항이 수백 개를 넘어가면 전용 도구 없이는 추적성을 유지하기 어렵습니다.