기업 시스템-흔히 MIS(Management Information System)이라고 말하는-을 개발하기 위한 분석과 설계 분야에서 10년이 넘도록 일하고 있습니다. 저는 이 영역이 실제 프로젝트 현장에서 전혀 발전하지 않고, 오히려 퇴보하는 모습을 보면서 괴로워 하고 있고, 책이나 해외의 석학들은 여전히 원칙과 기본을 말하는 것을 들으며 벽을 느낍니다.
그래서, 복잡한 것 말고 단순한 것, 하면 좋은 것 말고 꼭 해야하는 것을 제 경험과 지식을 기반으로 정리해보려고 합니다.
읽는 분들에게 조금이라도 도움이 된다면 보람있는 일이겠지요. 이 글이 첫 시작이 되겠네요. 얼마나 자주가 될지 모르겠지만 열심히 정리해 보겠습니다.
오늘은 분석과 설계에 대한 제 나름의 정의를 말씀드리려고 합니다.
일반적으로, 분석이란 시스템 사용자의 업무를 파악하여 만들어야 하는 시스템이 무엇(What)인지를 정의하는 것이고, 설계란 그 시스템을 어떻게(How) 만들 것인지를 파악하는 것이라고 말합니다. 분석은 순수하게 비즈니스에 관련된 것이고, 설계란 기술(technology)에 관련된 것이 되겠지요.
이러한 정의를 기반으로 우리는 시스템을 분석, 설계하고 분석 시에 너무 구현 방식이나 구현 시의 제약사항을 고려하지 말도록 가이드 합니다. 그리고 그러한 기준으로 분석과 설계의 산출물도 구분하고요.
그러나 실제 프로젝트를 수행할 때, 이런 구분은 충분히 자세하지 않거나 혼란스럽다고 느껴집니다. 왜냐하면 분석단계의 대표적인 작업인 요구사항 정의만 해도 얼마나 자세하게 쓰느냐, 어떤 단어를 사용하느냐에 따라 분석, 설계의 경계를 넘나들 수 있으니까요.
그래서, 많이 고민하고 제가 내린 결론은 이렇습니다.
분석은 사용자의 요구사항과 관련된 모든 작업이고, 설계는 이의 구현과 관련된 모든 작업입니다.
분석은 시스템의 경계를 정의하는 작업이고, 설계는 시스템의 내부를 모듈화 하는 작업이구요.
좀 더 구체적으로 설명해 드리겠습니다.
분석 작업의 시작은 시스템의 경계를 대략적으로 스케치하는데서 출발합니다. 예를들면 시스템 배경도를 그리는 것처럼 말이죠. 가운데 개발 대상인 시스템을 두고 주변에 이를 사용하는 사람이나 관련 시스템을 두고 중요한 입출력 데이터를 표시합니다. 이렇게 함으로써 시스템의 대략의 경계를 파악할 수 있게 됩니다.
시스템을 개발하려는 프로젝트 초반에는 파악된 정보가 부족하기 때문에 사용자의 주요 입력/출력만을 파악하게 되지만, 이를 파고들다 보면 어느 순간 사용자가 최종적으로 합의하게 되는것은 자신들이 사용할 화면이 됩니다. 사용자의 요구사항을 파악하기 위한 가장 효과적인 방법으로 화면에 대한 논의가 인식되었고, 이제 많은 프로젝트에서 화면정의를 설계가 아닌 상당히 앞단계의 작업으로 설정하고 있습니다.
시스템의 경계를 대략적으로 파악하기 시작해서 화면으로 구체화 할때까지, 이 기간이 분석에 해당하며, 사용자와의 상호작용이 절대적으로 중요한 기간입니다.
이에 비해 설계는 시스템 내부를 구체화 하는 작업입니다. 상세한 시스템의 경계가 결정된 후, 이 내부를 어떻게 나누고 공통 적인 부분도 파악해 가며 개발하기도 쉽고 유지보수 하기도 쉬운 시스템을 만들 것이냐 하는 부분이라 할 수 있습니다.
많은 모델링 기법들이 있지만 많은 차이점을 보이는 부분은 사실 이 부분, 즉 설계 뿐! 이라고 생각합니다. 정보공학, 객체지향, CBD, SOA 등에서 시스템의 경계를 파악하는 방법은 대동소이 하기 때문입니다. 그런대, 현실적으로 많은 발주자들이 시스템 개발 방법론을 못박고 있는데, 이것은 건물을 지어달라고 하면서 철근이나 콘크리트의 유형까지 직접 골라주겠다고 나서는 것과 비슷하다고 생각합니다. 설계는 온전히 엔지니어의 몫인데 말이죠.
이러한 설계 작업에는 아키텍처가 빠질 수 없습니다. 개발하기 쉽고 유지보수 하지 쉽다는 설계의 목표를 달성하기 위해서는 좋은 아키텍처가 핵심이기 때문입니다. 이 아키텍처는 화면과 DB를 구분하는 간단한 것에서 부터 시작해서 7,8 단계를 거치며 설계 패턴들을 적용한 복잡한 것까지 있을 수 있습니다. 어느 수준의 것이든 시스템에 적합한 아키텍처를 결정하고 이를 시스템 전반에 적용하는 작업이 바로 설계 입니다.
(그래서 저는 객체지향에서 Boundary, Control Entity 클래스를 도출하는 것은 설계 작업이라고 생각합니다.)
정리해보면 분석은 시스템의 경계, 즉 테두리를 결정하기 위해 거친 스케치에서 출발해 세부 화면 항목까지 정하는 일련의 작업이고, 설계는 이 경계의 안쪽을 잘 메우기 위한 작업이라고 할 수 있겠네요. 그렇다면 분석은 원활한 의사소통을 통해 경계를 정확히 파악하는 것이 핵심일테고, 설계는 기술적 노하우와 논리력을 가지고 오래도록 잘 쓸수 있도록 구분해서 구현하는 작업이 중요하다고 생각됩니다.
아직은 덜 다듬어진 정의지만 앞으로 더 고민해가며 다듬어 보려고 합니다. 그리고, 다양한 방법론과 분석/설계 기법이 있는 만큼 이해를 돕기위해 산출물 등을 예를 들어 다음 기회에 한번 더 정리해 보도록 하겠습니다.
그래서, 복잡한 것 말고 단순한 것, 하면 좋은 것 말고 꼭 해야하는 것을 제 경험과 지식을 기반으로 정리해보려고 합니다.
읽는 분들에게 조금이라도 도움이 된다면 보람있는 일이겠지요. 이 글이 첫 시작이 되겠네요. 얼마나 자주가 될지 모르겠지만 열심히 정리해 보겠습니다.
오늘은 분석과 설계에 대한 제 나름의 정의를 말씀드리려고 합니다.
일반적으로, 분석이란 시스템 사용자의 업무를 파악하여 만들어야 하는 시스템이 무엇(What)인지를 정의하는 것이고, 설계란 그 시스템을 어떻게(How) 만들 것인지를 파악하는 것이라고 말합니다. 분석은 순수하게 비즈니스에 관련된 것이고, 설계란 기술(technology)에 관련된 것이 되겠지요.
이러한 정의를 기반으로 우리는 시스템을 분석, 설계하고 분석 시에 너무 구현 방식이나 구현 시의 제약사항을 고려하지 말도록 가이드 합니다. 그리고 그러한 기준으로 분석과 설계의 산출물도 구분하고요.
그러나 실제 프로젝트를 수행할 때, 이런 구분은 충분히 자세하지 않거나 혼란스럽다고 느껴집니다. 왜냐하면 분석단계의 대표적인 작업인 요구사항 정의만 해도 얼마나 자세하게 쓰느냐, 어떤 단어를 사용하느냐에 따라 분석, 설계의 경계를 넘나들 수 있으니까요.
그래서, 많이 고민하고 제가 내린 결론은 이렇습니다.
분석은 사용자의 요구사항과 관련된 모든 작업이고, 설계는 이의 구현과 관련된 모든 작업입니다.
분석은 시스템의 경계를 정의하는 작업이고, 설계는 시스템의 내부를 모듈화 하는 작업이구요.
좀 더 구체적으로 설명해 드리겠습니다.
분석 작업의 시작은 시스템의 경계를 대략적으로 스케치하는데서 출발합니다. 예를들면 시스템 배경도를 그리는 것처럼 말이죠. 가운데 개발 대상인 시스템을 두고 주변에 이를 사용하는 사람이나 관련 시스템을 두고 중요한 입출력 데이터를 표시합니다. 이렇게 함으로써 시스템의 대략의 경계를 파악할 수 있게 됩니다.
시스템 배경도 이미지
그리고나서, 시스템에 대한 각 외부 대상-배경도에서는 단말(terminal)이라고 하는데요-의 주요 입출력자료를 요구사항으로 점차 구체화 시켜 나갑니다. 이 과정에서 정보공학 방법론을 사용한다면 요구사항 정의서, 기능분해도, 업무흐름도, 프로세스 정의서 등을 작성하게 되는 거구요. 객체지향의 경우에는 use case diagram과 use case 명세서를 작성하게 됩니다.
그럼 언제까지가 분석일까요. 저는 외부 대상과의 인터페이스를 구체화 하는 단계 까지가 분석이라고 말씀드리고 싶습니다. 외부대상이 사람이라면 화면(User Interface)을 타 시스템이라면 시스템 인터페이스를 정의하는 작업이 되겠지요. 경계를 얼마나 자세히 상세화 하느냐하는 정도의 차이일 뿐, 시스템의 배경도나 화면정의서나 같은 목적을 가진 작업이기 때문입니다.
그럼 언제까지가 분석일까요. 저는 외부 대상과의 인터페이스를 구체화 하는 단계 까지가 분석이라고 말씀드리고 싶습니다. 외부대상이 사람이라면 화면(User Interface)을 타 시스템이라면 시스템 인터페이스를 정의하는 작업이 되겠지요. 경계를 얼마나 자세히 상세화 하느냐하는 정도의 차이일 뿐, 시스템의 배경도나 화면정의서나 같은 목적을 가진 작업이기 때문입니다.
화면정의서 이미지
시스템을 개발하려는 프로젝트 초반에는 파악된 정보가 부족하기 때문에 사용자의 주요 입력/출력만을 파악하게 되지만, 이를 파고들다 보면 어느 순간 사용자가 최종적으로 합의하게 되는것은 자신들이 사용할 화면이 됩니다. 사용자의 요구사항을 파악하기 위한 가장 효과적인 방법으로 화면에 대한 논의가 인식되었고, 이제 많은 프로젝트에서 화면정의를 설계가 아닌 상당히 앞단계의 작업으로 설정하고 있습니다.
시스템의 경계를 대략적으로 파악하기 시작해서 화면으로 구체화 할때까지, 이 기간이 분석에 해당하며, 사용자와의 상호작용이 절대적으로 중요한 기간입니다.
이에 비해 설계는 시스템 내부를 구체화 하는 작업입니다. 상세한 시스템의 경계가 결정된 후, 이 내부를 어떻게 나누고 공통 적인 부분도 파악해 가며 개발하기도 쉽고 유지보수 하기도 쉬운 시스템을 만들 것이냐 하는 부분이라 할 수 있습니다.
많은 모델링 기법들이 있지만 많은 차이점을 보이는 부분은 사실 이 부분, 즉 설계 뿐! 이라고 생각합니다. 정보공학, 객체지향, CBD, SOA 등에서 시스템의 경계를 파악하는 방법은 대동소이 하기 때문입니다. 그런대, 현실적으로 많은 발주자들이 시스템 개발 방법론을 못박고 있는데, 이것은 건물을 지어달라고 하면서 철근이나 콘크리트의 유형까지 직접 골라주겠다고 나서는 것과 비슷하다고 생각합니다. 설계는 온전히 엔지니어의 몫인데 말이죠.
이러한 설계 작업에는 아키텍처가 빠질 수 없습니다. 개발하기 쉽고 유지보수 하지 쉽다는 설계의 목표를 달성하기 위해서는 좋은 아키텍처가 핵심이기 때문입니다. 이 아키텍처는 화면과 DB를 구분하는 간단한 것에서 부터 시작해서 7,8 단계를 거치며 설계 패턴들을 적용한 복잡한 것까지 있을 수 있습니다. 어느 수준의 것이든 시스템에 적합한 아키텍처를 결정하고 이를 시스템 전반에 적용하는 작업이 바로 설계 입니다.
(그래서 저는 객체지향에서 Boundary, Control Entity 클래스를 도출하는 것은 설계 작업이라고 생각합니다.)
software architectrue 이미지
정리해보면 분석은 시스템의 경계, 즉 테두리를 결정하기 위해 거친 스케치에서 출발해 세부 화면 항목까지 정하는 일련의 작업이고, 설계는 이 경계의 안쪽을 잘 메우기 위한 작업이라고 할 수 있겠네요. 그렇다면 분석은 원활한 의사소통을 통해 경계를 정확히 파악하는 것이 핵심일테고, 설계는 기술적 노하우와 논리력을 가지고 오래도록 잘 쓸수 있도록 구분해서 구현하는 작업이 중요하다고 생각됩니다.
아직은 덜 다듬어진 정의지만 앞으로 더 고민해가며 다듬어 보려고 합니다. 그리고, 다양한 방법론과 분석/설계 기법이 있는 만큼 이해를 돕기위해 산출물 등을 예를 들어 다음 기회에 한번 더 정리해 보도록 하겠습니다.
'IT 이야기' 카테고리의 다른 글
| 유쾌하게 내 저작물을 개선하는 놀라운 방법 (0) | 2012.06.06 |
|---|---|
| 분석의 전략 (0) | 2011.05.15 |
| QConSF2010 Friday (0) | 2010.11.06 |
| QConSF2010 Thursday - noSQL (0) | 2010.11.05 |
| QConSF2010 - Wednesday (2) | 2010.11.04 |