엔터프라이즈 시스템의 개발 프로젝트는 고객의 요구사항으로 부터 그것을 서포트하는 실행 환경을 만들어 과저으로 정의할 수있다. 여기서 실행 환경은 단순한 바이너리 코드 뿐만 아니가 데이터베이스나 H/W처럼 바이너리가 구동할 수 있는 인프라까지를 포함한다
이중에서도 가장 많은 인원과 기간이 소요되는 것은 프로그래밍이다. 따라서 프로젝트가 성공하거나 실패하는 가장 중요한 기준 또한 프로그램 개발이 성공적이나 아니냐 일 것이다.
나는 일견 당연한 듯한 요구사항->분석->설계->코딩의 일련의 과정들에 대한 몇가지 관점과 그로인해 생각해 보아야 하는 주제들에 대해서 의견을 말하고자 한다.
- Refine이란 내용이 상세화 되고 구체적으로 정제 된다는 것을 의미한다. 요구사항은 매우 불확실하고 가변적인 요소가 많다. 하지만 어떤 식으로든 구체적으로 결정되어야 실행코드에 반영이될 것이다. 따라서 요구사항은 실행 코드가 될때 까지 Refine되어야 한다.
- Translate란 형태가 바뀐다는 것을 의미한다. 즉 구두나 텍스트 문서로 존재하던것이 마지막에는 프로그램 언어로 작성된 코드가 되는데 이렇게 형태가 바뀐다는 것을 말한다.
요구 사항은 실행코드에 반영될수 있는 수준으로 정제되어야 하며 프로그램 언어로 변경되어 프로그램되어야 한다.
그런데 요구사항은 너무 부정확하기 때문에 곧바로 프로그램 언어로 작성되기 어렵고 중간에 분석과 설계의 단계를 거치면서 Translate되어야 한다.
가장 일반적으로 거치는 중간 산출물이 분석 모델과 설계서이다.
- 요구사항은 인터뷰자료 혹은 사용중인 각종 서류등이 될 수 있으며 텍스트, 엑셀, 유스케이스 등으로 정리될 수있다.
- 분석모델은 각종 S/W 아키텍처관점에서 개념뷰나 Logical View, 유스케이스 상세 스팩혹은 분석 다이어그램의 형태로 존재한다.
- 설계 모델은 클래스 다이어그램 시퀀스 다이어그램 혹은 텍스트 그림 파일 등으로 이루어진다.
- 실행코드는 프로그램 언어이다.
왜 Translate가 발생하는가? 왜 모델을 다른 형태로 작성하는가?
왜 요구사항은 텍스트나 엑셀등으로 정리하는데 분석/설계는 다른 다이어그램을 사용하는가? 어차피 프로그램 언어로 번역되어야 한다면 요구사항을 세세하게 정리하여 바로 프로그램 언어로 바꾸면되는것 아닌가?
그이유는 내용의 상세함 정도에 따라 효과적인 기술방식이 다르기 때문이다. 예를들어 텍스트로 프로그램 언어 수준의 명확하고 상세함을 정리할 수 없다. 요구사항이 정제될 수록 복잡도는 증가한다. 전체를 바라보면서도 세부적인 내용을 확인하는 것이 어렵다 따라서 이것을위한 UML과 같은 기술방식을 사용하는 것이다.
분석/설계는 과정이지 목표가 아니다
요구사항을 잘 정제하고 궁극적으로 프로그램으로 기술하기 위해 분석과 설계를 한다. 하지만 이것은 반대로 보면,요구사항이 비록 텍스트이지만 요구 내용이 명확하고 어떻게 프로그램해야 하는지 정확히 알 수 있다면 분석/설계 단계가 필요 없다는 말이 될 수 있다.
이런 현상은 동일 도메인에서 반복적인 프로젝트가 수행될때 많이 나타난다. 이전 프로젝트의 소스 코드와 기타 산출물을 기반으로 프로젝트 하는경우 고객 인터뷰 과정에서 이전과 다른 점만을 체크하고 이것을 프로그램을 하는 경우가 있다.
또다른 상황으로 시간이 극히 부족한 경우이다. 내가 아는 모 방송사 프로젝트에서 이런 현상이 나타났는데 정부에서 먼저 발표를 한것이다. 무조건 한달만에 시스템을 오픈해야 하는 절체절명의 상황이 된것이다. 이런 경우에는 모험을 할 수밖에 없다. 분석/설계는 생략될 수밖에 없고 개발자는 고객의 요구를 텍스트로만 정리하고 바로 프로그램에 들어갔다. 그런데 불행인지 다행인지 시스템은 오픈되었고 그 시스템은 몇년이 지난 지금도 유지보수되면서 사용되고 있다.
이렇게 분석/설계가 무시되는 현상은 분석/설계는 프로젝트의 최종산출물이 아니기 때문에 나타나는 것이다. 하지만 많은 소프트웨어 공학에서 너무나 당연한듯하게 분석과 설계를 이야기 하는 것은 그만큼 요구사항을 곧바로 프로그램으로 Translate하기 어렵고 위험이 크기 때문이다. 시간을 가지고 적절한 Refine과 Translate를 단계적으로 수행해야만 그래도 안정적인 프로그램이 가능하다.
모든 산출물의 기술 방식(모델링/프로그램 언어)은 사람에 의존적이다.
모든 프로그램으로 가는 중간 산출물은 나름의 기술방식 혹은 형태는 그 시스템에 관련한 사람에 의존적이다. 이점을 간과하면 않된다. 예를 들어 코볼 개발자를 모아놓고 자바로 프로그램할 수는 없다. PHP개발자를 모아놓고 C++ 프로그램을 요구할 수는 없다. 또는 웹프로그램을 만들어야 하는데 어셈블리어로 개발할 수는 없다.(가능은 하겠지만)
이것은 당연한듯한데 이런 오류를 분석/설계 산출물을 작성할 때 범하는 경우가 많다. 순서도만 아는 사람들을에게 프로젝트에서 UML로 분석/설계하라고 요구하는 것은 잘못이다.
프로젝트 팀원과 고객담당자들이 어느정도 준비된 모델링 방법으로 요구사항을 정제되고 변환되어가야 한다.
실행 코드로 부터 설계서를 리버스 하는 것은 잘못이다.
아름다운 전원 주택을 짓고 싶었다. 그냥 통나무로 되는데로 만들었다. 그리고 나서 실물을 보면서 청사진을 그린다면 맞는 것인가? 혹시 나중에 리모델링할때 사용하려고?
설계서는 그만한 깊이로 정제되어야 한다. 그것이 프로그램 언어가 아니다.
이런 오류는 기술 컴포넌트를 설계하는데 많이 나타난다. 예를 들어 "JDBC 컴포넌트 사용"이라고만 설계서에 기술하면 프로그래머는 어떻게 해야 하는지 안다.즉 그곳에 JDBC 클래스들간의 시퀀스다이어그램을 그릴 필요가 없는 것이다.
분석과 설계는 항상 적절한 상세 수준을 가져야 한다.
요구사항은 프로그램을 하는 순간까지 추가/수정될 수밖에 없다.
프로젝트 초기에 수집된 개략적인 요구사항이 프로그램하는 순간까지 변하지 않을 것이라고 믿는 것은 어리석은 생각이다. 반드시 추가되고 변화될 수밖에 없다.
다만 우리는 전체모델을 흔드는 추가나 변화가 발생하지 않도록 노력할 뿐이다.
각 단계의 산출물들은 요구사항을 상세화 하는 것이고 프로그램이 가장 상세화된 요구사항의 표현이다. 따라서 이전단계에서 확인되지 않은 요구사항은 다음단계의 산출물에 포함될것이며 이과정에서 고객과 프로젝트에서 인지하지 못했던 내용이 나타날 것이다.
사람(혹은 조직)이 바뀌면 Refine이 최소화 되어야 한다.
개발 각 단계별로 Refine이 발생하는 것은 당연하다 하지만 사람이나 조직이 변경되면 이전단계 산출물에서 다음 단계의 산출물을 생성해 내는것이 쉽지 않다.
예를 들어 컨설팅 업체가 요구사항분석까지만 하고 나머지는 개발 업체가 진행하는 프로젝이 있다면 개발 업체는 컨설팅 업체로 부터 잘 정제된 요구사항을 받아야 한다.
즉 고객의 추가적인도움없이 분석산출물을 만들 수 있는수준의 요구사항 산출물을 받아야 한다.
일반적으로 요구사항으로 부터 고객의 도움을 받아 분석 산출물을 만든다 여기서 고객의 도움이 필요한 이유는 요구사항이 정제되는 과정에서 고객의 판단이 필요하기 때문이다. 하지만 업체가 바뀌는 상황에서는 가능한 정제된 요구사항이 개발업체로 전달되어야하면 그 요구사항은 추가적인 정제과정없이 분석 모델로 변경될 수 있는 수준이어야 한다.
많은 개발 프로젝트의 설계자들이 분석과 설계를 요구사항에서 프로그램으로 가는 과정으로 이해하기 보다는 분석/설계 산출물 자체의 화려함이나 정교함을 추구하는 경향이 있다 분석/설계서를 작성하면서 빈번한 COPY&PASTE가 발생한다든지 개발 코드로 부터 리버스엔지니어링을 통해서 만들어지고 있다면 뭔가 잘못되고 있다는 것을 의미한다.(필자의견)
'아키텍처와 공학' 카테고리의 다른 글
| 잠시 그려본 Enterprise Application Architecture(전사적 응용 아키텍처) (0) | 2009.10.30 |
|---|---|
| 자바/웹 그리고 프로젝트 (0) | 2009.10.30 |
| 메시지 기반 미들웨어 (1) | 2009.10.26 |
| ISP (Information Strategy Planning) (0) | 2009.10.26 |
| Feature Driven Development(FDD) (0) | 2009.10.26 |
