반응형

대사작업을 가장한 정산시스템

분석단계

 

국내 프로젝트들은 분석/설계단계가 해외 프로젝트들보다 굉장히 짧다고 한다.

해외 프로젝트를 해보지 않아서 진위여부는 잘 모르겠다.

하지만, 국내의 프로젝트들 약 20년간 진행해 본 결과...

분석/설계단계가 짧다는 것에는 깊이 동의한다.

 

대부분의 프로젝트가 개발을 하면서 설계를 한다.

실무자들 조차 '개발자의 일정이 도래하기 전에만 설계하면 되지' 라는 생각을 가지고 있다.

그 조차 생각안하는 사람들도 많이 있......

 

분석/설계단계

 

분석이라 함은 (업무적인) 요구사항의 분석과

사이트의 인프라 및 (현행 시스템이 있을 경우) 현행 시스템을 분석하는 것으로 나눌수 있다.

 

요구사항 분석은...

현업의 요구사항needs을 파악하는 일이다.

대부분의 프로젝트들이 막연한 요건으로 시작되는 경우가 많다.

프로젝트 발주부서와 실제 시스템을 사용할 현업사용자가 다른 경우도 대부분이다.

이렇다보니 사용자의 요구사항이 명확하지 않은 경우가 상당히 많다.

 

분석 단계에서 이러한 요구사항을 도출하는 것이다.

( 현실에서는 오픈하기 전날까지 요구사항을 내고, 바꾼다. )

업무부서나 영업점 등에 설문조사를 하기도 하고, 미팅을 가지기도 한다.

이런 과정을 거쳐 '요구사항 정의서'라는 산출물을 만들게 된다.

 

개발자(설계자)는 현행 시스템을 분석한다.

사이트의 인프라에 대한 이해와 현행 업무를 어떤식으로 처리하고 있는지

아키텍처, 모델, 업무프로세스, 주오 알고리즘 등을 확인한다.

 

그 결과를 가지고

테이블 정의서, 인터페이스 정의서, 프로세스 정의서, 프로그램 목록 등의 산출물을 작성한다.

 

이번 프로젝트에서는 소규모다 보니 시간이 여의치 않아

분석단계가 3주로 잡았다.

그런데, 시스템이 조그만해도 있을 것 다있다는 것이 문제!

즉, 정의할 건 다 해야하고, 산출물도 만들 건 다 만들어야 하다는 것이다.

 

두 명의 개발자에게 시스템 소스를 보라고 지시하고

간단히 소스를 파싱하는 프로그램을 만들어 돌렸다.

이 프로그램으로 CRUD Matrix라고 하는 형태의 문서를 도출할 수 있고,

이를 기반으로 개략적인 흐름을 읽을 수 있다.

( 솔직히 말하면, 프로세스 흐름보다는 산출물을 용이하게 만들 수 있다 )

 

** 가능하다면, 프로그램을 만들어 파싱하는 것을 추천한다.

     프로젝트에서 활용하면 여러가지로 시간을 아낄 수 있고, 나 역시 많은 도움을 받았다.

 

참고할 수 있는 현행 시스템(이하 As-Is라 칭함)은 업무 정산시스템이었다.

이번에 개발하는 시스템(이하 To-Be라 칭함)도 '주 업무'는 정산이다.

 

차이점은 As-Is시스템은 당사 원장자료를 기반으로 

원하는 조건들을 입력/조합하여 대상고객 및 금액을 도출하는 시스템이었고,

To-Be는 제휴사에서 정산요청한 데이터를 기반으로 당사의 자료를 찾고

이를 상호 비교하여 정확한지를 판단한다.

최종 일치하는 데이터를 기반으로 도출된 금액을 제휴사에 지급하는 시스템이다.

 

고객의 요구사항은

제휴사자료와 (제휴사 자료와 무관하게) 당사의 기준에 맞춰 자료를 추출하고

두 자료간 대사를 하여 일치/불일치를 판단하고 사유를 표시하는 것이었다.

각 제휴사에 따라 비교/계산하는 기준이 각각 달랐고, 일부는 데이터 보정 프로세스도 필요했다.

즉, 기존 시스템보다 몇배 더 많은 업무량인 것이었다.!

여기에 또 다른 시스템에 '기능을 추가'하는 업무가 있으니...

이 업무는 개발해야하는 To-Be시스템을 어느정도 만들고 생각하기로 했다.

기능을 추가해야 할 시스템도 현재 개발중이었기에, 전체 일정을 해당 시스템이 개발완료된 이후로 미뤘다.

( 아마 같이 진행해야 하는 상황이었으면, 100% 프로젝트는 실패했을 것이다. )

 

3주라는 시간은 빛의 속도로 지나갔고...

겨우겨우 산출물을 맞추고 개략적인 이해만 하는 수준으로 분석단계가 끝났다.

 

이제는...

분석된 자료를 기반으로 요건을 시스템화 해야 하는 설계단계이다.

이런걸 보고, 산 넘어 산이라 하나보다.

 

끝.

반응형