소프트웨어 설계란 개발을 위한 초석이며, 설계자가 고객 또는 개발자와 커뮤니케이션하기 위한 도구이다. 소프트웨어 설계는 분명 다른 공학의 설계와는 다른 특성을 갖고 있으며 소프트웨어 설계는 다음의 몇 가지 이유 등으로 인해 완벽할 수 없다.
첫째, 소프트웨어 설계는 일반 공학의 설계가 아닌 시나리오다.
일반 공학, 예를 들어 건축공학에서, 건축 설계의 최종 목적물은 건축물에 대한 스틸 사진이다. 그러나 소프트웨어 설계의 최종 목적물은 시간의 흐름에 따라 혹은 외부의 이벤트에 어떤 행위 즉 기능을 해야 하는 지를 계획하는 것이다. 이 점에서 오히려 영화의 시나리오에 가깝다.
이것은 소프트웨어 설계를 위해 흔히 사용하는 UML이 영화 시나리오를 도식화하기 위해 꽤나 적합하다는 것에서도 알 수 있다. 거꾸로 UML을 영화의 시나리오로 변경하는 것에도 불편함이 없다.
소프트웨어의 설계가 영화의 시나리오에 가깝다는 점을 인정한다면, 소프트웨어의 설계가 완벽하게 이뤄질 수 없다는 점 또한 쉽게 인지할 수 있다. 예를 들어 여주인공과 남자 주인공의 키스하는 장면이 있다고 하자.
로미오 (줄리엣에게 다가서며 입맞춘다)
줄리엣 (볼을 붉게 물들이며) 읔
대부분의 영화 시나리오가 이 이상 상세히 기술하지 못한다. 어떤 각도로 남자주인공이 가까워지는지? 볼은 얼마나 붉어져야 하는 지? 는 결국 영화의 시나리오를 연기하는 배우가 해야 할 몫으로 남겨두고 있다. 시나리오의 내용을 소프트웨어로 개발을 한다고 하자. 소프트웨어 개발을 위해선 다음과 같은 데이터가 필요하다.
로미오 : 고개를 Z축 45' Y축 12' 으로 움직이며 줄리엣의 입술을 향해 나아가는 속도 2.5 cm/sec
줄리엣 : 볼의 17.2%를 현재의 COLOR 에서 RGB (231,119, 129)로 그라데이션 처리
아마 이것 보다 훨씬 많은 데이터가 필요할 것이다. 시나리오가 영화화 하기 위한 모든 정보를 담을 수 없듯, 소프트웨어 설계도 개발을 위한 모든 정보를 설계단계에서 담을 수 없으며 이 부분은 결국 개발자가 개발을 진행하면서 처리할 수 밖에 없다. 만약 설계 단계에서 개발에 필요한 모든 정보를 담을 수 있다면, 설계 문서 자체만으로 컴파일이 가능할 것이다.
영화가 영화 배우의 역량에 많은 부분 의존하듯, 소프트웨어 개발도 개발자의 역량에 그 품질의 많은 부분을 의존한다. 연극의 3요소가 대본과 배우와 관객이라면, 소프트웨어의 3요소는 설계와 개발자와 사용자다.
둘째, 소프트웨어 설계는 건축의 기본설계다.
소프트웨어의 설계에도 단계가 있듯 건축설계에도 많은 단계를 갖는다. 건축물의 실제 공사가 시작되기 전 계획단계에 이뤄지는 계획설계, 계획설계를 바탕으로 각층의 구조 평면도 등을 작성하는 기본설계, 기본설계에 맞춰 실제 시공을 할 수 있도록 전기배선 설계, 냉/난방 설계 등을 작성하는 실시설계로 나뉜다.
흔히 아래와 같은 등식으로 건축과 소프트웨어 개발 공정을 비유하지만
실제로는 다음 그림과 같이 비유해야 한다.
일반 공학에서, 설계가 끝나면 설계 문서는 제작팀에게 넘어가서 제품을 만들게 된다. 만약 설계 문서가 정말 완벽한 설계를 표현한다면, 제작팀은 제품을 만들 수 있다. 이러한 공학 설계 기준을 만족하는 소프트웨어 문서는 오직 소스코드 뿐이다.
- Jack Reeves (http://www.developerdotstar.com/mag/articles/reeves_design.html)
건축물이 시공과정을 통해서 만들어지듯 소프트웨어도 컴파일 등의 과정을 통해서 만들어진다. 소프트웨어는 설계과정을 통해서 설계의 기본을 만들고 코딩과정을 통해서 설계를 완성한다.
셋째, 움직이는 표적을 완벽히 정조준하는 것은 불가능하다.
완벽한 설계는 완벽한 분석에 기반한다. 오늘 완벽히 분석을 하였다 하더래도, 내일 아침이면 고객이 헐레벌떡 뛰어오면서 얘기한다. "시장상황이 바뀌어서, 개발 요건을 변경하여야 합니다." 이렇듯 개발요건이 수시로 바뀌는 상황에 대비해서 설계를 완벽히 한다는 것은 불가능하다.
개발사는 제안서에 흔히 다음과 같이 기술하다.
"시장 변화에 능동적으로 대처 가능한 유연한 설계"
유연한 설계? 유연한 설계를 위해서는 모든 경우의 수를 고려한 설계가 이뤄져야 하며 이는 분석/설계자가 앞으로 닥칠 환경변화 또는 고객의 변덕스러움을 완벽히 예측하여야 함을 말한다. 또한 유연한 설계는 최적화된 설계, 즉 개발요건에 정조준된 개발과 상충된다. 즉 더 많은 노력과 더 많은 개발비용이 든다. 한정된 예산, 한정된 일정으로 발생할 모든 경우의 수를 대비한다는 것은 불가능하다.
넷째, 소프트웨어 설계를 검증할 도구가 없다.
소프트웨어 설계는 많은 시간이 소요되고, 많은 사람들의 노력이 필요하다. 수많은 노력과 수많은 시간이 소요되지만 막상 이것을 검증하기란 쉽지 않은 일이다. 문서상으로 표현된 소프트웨어 설계는 그럴 듯 보인다. 하지만 현재로서 설계를 검증하기 위한 유일한 방법은 동료검토다. (http://swarchi.tistory.com/11)
건축공학에서 설계를 한 후에 그 설계가 제대로 되었는지를 확인하기 위해서 컴퓨터 시뮬레이션을 수행한다. 건물의 구조설계가 이뤄진 다음에는 수많은 역학 법칙에 따른 수학적 검증을 하게 된다. 이러한 작업이 반복된 후에야 건물의 설계가 완료된다. 경우에 따라서는 건축 모형을 만들어서 설계를 검증하게 된다.
<6층 목조 주택에 대한 가상 지진 실험 장면>
동료검토를 제외하고, 소프트웨어 설계를 가장 확실하면서도 가장 싸게 검증하는 방법? 소프트웨어 개발.
다섯째, 고객과 함께 얘기할 제대로 된 설계도구가 부족하다.
대부분의 공학에서 작성하는 설계서는 제작을 위한 지침일 뿐 아니라 고객과 대화하기 위한 도구이다. 건축공학의 예를 들면 아래 우측의 건축물을 짓기 위해 건축가가 아래 왼쪽 그림과 같이 간단히 스케치하여 고객과 이야기를 시작한다고 해도 부족함이 없다. 물론 실제 고객을 만날 때는 이 보다는 훨씬 자세한 입면도며 조감도를 갖고 이야기를 한다.
<르 코르뷔제의 롱샹성당>
그러나 소프트웨어 공학에서 분석, 설계를 마치고 고객에게 들이미는 문서라곤, UseCase, DFD, ERD, Class Diagram 등 무엇 하나 소프트웨어 공학을 전공치 않고는 직관적으로 제대로 이해할 수 있는 문서가 없으며, 화면설계서 정도가 고객과 대화할 수 있는 문서라 할 것이다. (화면설계서만으로 소프트웨어의 기능을 설명하기에는 부족한 면이 많다. 화면이 없는 배치프로그램은 어떻게 할 것인가?)
UML의 어떤 화면을 보고서 고객이 "아! 프로그램이 이런 모습으로 보여질 거군요" 라고 끄떡거리겠는가? 이해되지 않는 문서에 서명을 강요당해야 하는 고객의 입장도 이해되지 않는 것이 아니다.
이러한 것은 어디에서 기인하는가? 전술한 바와 같이 대부분의 일반적인 설계가 최종 목적물에 대한 정적인 이미지를 형상화하는 것이지만, 소프트웨어 공학의 설계는 어떤 과정을 걸쳐서 최종 목적물의 기능을 구현할까에 초점을 맞춘다.
일반적인 설계는 이미지를 형상화하는 것이기에 가시적일 수 있으나, 소프트웨어 설계는 최종 목적물을 보여주기 위한 목적으로 그려지지 않기 때문에 비가시적이다. 이러한 설계문서를 통해서 고객과 얘기를 할 수 없다. 고객과 제대로 된 대화를 할 수 없기 때문에 분석과 설계는 항상 흔들릴 수 밖에 없다. 결국 프로그램 개발이 완료된 다음에야 고객이 이해하는 제대로 된 얘기를 시작할 수 있다.
http://www.wearethebest.co.kr/blog/185
소프트웨어 공학은 유구한 역사를 지닌 다른 공학 즉, 건축공학이나 기계공학과 같은 공학분야를 닮아가려 노력하여 왔다. 그러나 소프트웨어 개발은 다른 공학분야와는 분명히 다른 특성을 갖고 있으며, 이러한 특성을 간과한 체, 일반 공학의 틀 속에 소프트웨어 공학을 구겨 넣고자 하는 수 많은 시도가 진행되어 왔다. 소프트웨어 개발의 특성에 대한 제대로 된 연구가 선행되어야 제대로 된 소프트웨어를 만들 수 있다.