심기보 숭실대학교 정보과학대학원 교수


▲ 심기보 숭실대학교 정보과학대학원 교수





데이터 중심(DOA)형 요구정의 방법론

시스템 개발에서는 여기저기서 말들이 돈다. '아무리 시간이 지나도 UI(유저 인터페이스)가 결정되지 않는다', '설계단계에서 기능이 추가되어 개발범위가 추가 되었다', '테스트 단계에서도 설계 변경이 수없이 발생한다', '시스템 테스트의 중반에서 데이터베이스가 변경되어 모든 테스트를 다시 해야 했다'등 말들이 많다. 왜 이러한 상황을 시간이 지나도 개선이 되지 않는 것인가.

이는 요건정의의 방식에 원래부터 문제가 있다는 것을 보여주고 있는 것이다. 정보시스템 개발 프로젝트에서는 최적의 스코프(개발범위)를 개발 초기 단계에서 요구정의를 확실히 한 다음에 유저와 합의를 해 놓는 것이 가장 중요하다. 그러나 실제로는 너무 서두른 나머지 이를 하지 않거나 어떻게 요건을 결정하는지를 잘 알지 못한 채 개발을 추진해 버리는 경우가 많다. 이렇게 해서는 앞에서 말한 것과 같은 상황은 아무리 시간이 지나도 없어지지 않는다. 이번 호에서는 요구정의를 확실하게 하기 위한 실천적인 요건정의의 진행방식을 많은 시스템 개발에서 실적을 가지고 있는 'DOA(데이터 중심형 어프로치)'에 근거하여 설명한다.


필연적으로 태어난 DOA

DOA라는 말은 시스템 개발에 종사하는 엔지니어라면 한번쯤은 들어봤을 것이다. DOA는 원래 크리스·게인/트릿슈·서든의 저서 'Structured Systems Analysis'(1977년)와 톰·디말코의 저서 'Structured Analysis and System Specification(구조화 분석과 시스템 명세)'(1978년)에서 발단된 생각이다.

DOA는 시스템 개발의 중점이 데이터베이스 설계로 이행되어 가는 시대의 흐름에 대응하는 형태에서 필연적으로 생긴 개념이다. DOA 이전에는 '이 시스템은 판매, 구입, 재고관리, 고객 서비스를 포함한 영업 업무를 대상으로 한다', '판매 업무에는 수주, 집하, 납품, 청구의 기능이 포함된다'라고 하는 것처럼 단지 기능 명칭을 나열하거나 문장으로 기술하고 있었다. 시스템화의 대상이 되는 업무 종류가 증가하여 그 규모가 거대해 짐에 따라 이러한 방법으로는 업무의 본질적인 구조나 체계를 '명세(Specification)'레벨로 충분히표현할수없게됐다.

DOA에서는 대상 시스템의 '데이터의 흐름'파악에 중점을 두면서 요건 정의나 설계를 진행한다. 업무 전체를 데이터의 흐름에 주목하여 그림으로 표현하는 DFD(Data Flow Diagram), 데이터 항목의 집합(엔티티)과 엔티티 간의 관련을 그림으로 표현하는 ERD(Entity-Relationship Diagram), 데이터의 정규화(데이터의 중복을 최소한으로 하여 데이터 구조를 최적화하는 것), 복합 설계와 구조화 설계(개발효율이나 보수성이 높은 프로그램 구조를 설계하기 위한 기법) 등의 기법을 조합한 것이다.



<이하 상세 내용은 컴퓨터월드 12월 호 참조>

저작권자 © 아이티데일리 무단전재 및 재배포 금지