개념 (CONCEPT)
사업이나 일은 흔히 아이디어로부터 시작된다. 하지만 대부분 초기 아이디어는 체계적이지 못하고 불완전해 다른 이들이 바로 받아들이기에는 다소 무리가 있다. 여하튼 아주 좋은 아이디어, 즉 요구사항(Requirements)이 있다고 가정하자.
다음에, 다른 이들이 그 아이디어에 대해 깊은 감사를 표하거나 혹은 구매하려고 달려들도록 하기 위해 어떻게 거친 모서리를 다듬듯 그 아이디어를 정제할 것인가? 먼저 이를 보다 명료하게 할 필요가 있으며, 이는 정확히 무엇이 필요한 것인가에 대한 정의로부터 시작될 것이다. 이는 실제로 명확한 “요구사항”이 무엇인가에 관한 것이라 할 수 있다. 일단 그 요구사항이 무엇인지, 무엇에 관한 것인지 정확히 설명할 수 있다면, 그 요구사항을 최신의 제품을 만들어낼 수 있는 큰 규모의 전문 팀에게 전달할 수 있다. 이제 이 요구사항이 그들의 프로세스를 통해 실제 제품에 궁극적으로 반영될지 여부는 전달받은 팀에서 요구사항을 어떻게 해석하느냐에 달렸다. 여기서 요구사항은 충분히 가치 있다고 가정하자.
실질적인 실행 명세는 개발 흐름 전반을 지원한다. 가상 플랫폼에서는 체크포인트를 통해 설계 진행에 따른 실행 명세와의 반복적 확인 과정이 이루어진다. 이는 시스템 가상 프로토타입 단계에서 ‘실제 세상’ 상호작용 및 이에 관련된 구현이 이루어지기 전 단계를 의미한다.
테스트는 설계의 진행 여부에 관계없이 일관적으로 원래의 설계 요구에 부합하는 지를 체크하기 위해 수행된다. 이때 테스트 내용은 모든 단계에 걸쳐 재사용되고 필요에 따라서는 내용이 좀 더 구체적으로 추가된다.

시연(DEMONSTRATE)
그렇다면 요구사항의 해석이란 무엇일까? 어떻게 전달받은 팀 내부 소프트웨어 부서에서의 해석이 하드웨어 부서, 개발 총괄 임원, 심지어 초기 아이디어 제공자와 정확히 부합된다고 확신할 수 있을까?
답은 보여주는 것이다!
다시 말해, 요구사항을 어떻게 이해했는지, 그리고 전달된 바가 뭔지를 시연을 통해 거꾸로 보여주는 것이다. 이때 요구사항의 시연은 전체 설계 프로세스의 초기에 평가되고 조정될 수 있는 적극적인 형태를 취해야 한다.
이와 같은 시연 능력이야말로 바로 성공적인 MDD 프로세스의 가장 주요 부분으로, 이는 반드시 전체 개발 프로세스에서 가능한 한 초기에 위치해서 시작돼야 한다. 이를 통해 관련 부서 모두는 설계 초기에 반드시 필요한 질문을 할 수 있게 되고 동일한 개발 단계에서 의미 있는 답변을 얻을 수 있다. 물론 아직까지는 전체 개발 단계 중 가장 상위 단계에 머물러 있는 중이다.

실행 명세(EXECUTABLE SPECIFICATION)
실질적 실행 명세란 용어는 종종 텍스트로 된 고객의 초기 요구와 구체적이고 실행 가능한 설계 명세 사이에서 어떤 단절을 일컬을 수 있는 단계로의 접근을 이야기할 때 사용된다. 그러나 일반적으로 유용한 실행 명세를 작성하기 위해서도 몇몇 필요한 단계가 있을 수 있다.
실행 명세 설명을 위해 불과 몇 문장 전에 언급한 두 가지 핵심 주제를 전달하고자 한다. 첫째는 이해한 것을 보여주라는 것이고, 둘째는 초기 문제에 대한 질문을 가능케 하라는 점이다. 질문에 답변하고 최종 제품의 개념, 혹은 초기 설계, 혹은 주요 기능 특성에 가해질 수 있는 변화에 대한 대응이 강조돼야 한다. 올바른 실행 명세 작성은 위에서 언급한 역량이 필수 요소이다. 그리고 작성된 실행 명세의 올바른 이해를 통해 성공적인 설계 구현 및 재사용을 통한 효과적인 설계 프로세스 수립에 이를 수 있다.

분할(PARTITION)
흔히 설계 초기 과정에서 기능을 특정 구현 경로에 할당하곤 한다. 물론 이때는 올바른 결정을 내릴 수 있는 근거 역시 충분치 않은 상태이다. 더욱이 한번 내려진 결정은 보통 유일한 선택이 되는 경향이 있다. 이는 나중에 이를 결정한다면, 전체 기능을 통합하는데 큰 어려움이 있을 수 있다는 우려 때문이다. 따라서 설계 아키텍처는 매우 이른 시기에 결정되고 이에 동결된다.
일반적으로 최적의 분할을 위한 선택은 처음부터 충분히 알 수 없는 게 현실이다. 예를 들면, 특정 기능을 소프트웨어로 구현할 지, 혹은 하드웨어로 구현할 지에 대한 분할을 의미한다. 이 단계를 개선하기 위해서는 해당 프로세스의 아키텍처가 변화할 수 있다는 것을 가정한, 보다 유연한 설계 흐름과 보다 많은 정보가 필수적이다.
여기서 이미 우리의 현재 프로세스의 대부분에 존재하는 모델과 MDD의 기본 전제  사용이 중요한 차이를 만들 수 있다. 즉, 모델은 각기 다르게 제안된 분할을 실행, 검토할 수 있게 하고 다음 단계에서 필요한 질문을 요청케 한다.

기능 가상 플랫폼(FUNCTIONAL VIRTUAL PLATFORM)



그 다음 질문은 전반적인 시스템의 기능과 상위 추상화 단계에서 표현된 동작에 관련된 것이다. 필요한 설계 요소 모두가 준비되었는지, 그리고 준비된 설계 요소들이 기대했던 대로 상호작용하는지를 확인하고자 한다면 가상 플랫폼을 사용해야 한다. 이 단계에서 가상 플랫폼은 타이밍 또는 이와 유사한 제약 사항과 같은 세부 사항을 필요로 하지는 않는다. 단지 필요한 모든 기능의 동작 여부를 파악하기 위해 빠르게 실행하며 확인한다. 이 과정 역시 상당히 중요한 단계로서, 가상 플랫폼은 앞선 분할 방침 사이의 일관성 있는 보장을 위한 체크포인트 역할을 담당한다.

가상 시스템 프로토타입(SYSTEM VIRTUAL PROTOTYPE)
기능적 동작은 설계 목표 관점에서는 단지 한 부분일 뿐이다. 이밖에 성능, 전원, 실제 세계와의 상호작용과 전체 시스템 역량 역시도 평가돼야 한다. 일반적으로는 첫 번째 물리적 시제품이 만들어지고 나면 대개 이와 같은 평가 작업이 일단 이루어진다고 할 수 있다. 하지만 일단의 평가 작업일 뿐 최적화와는 거리가 있다. 이를 위해 하드웨어 플랫폼인 시스템 가상 프로토타입을 이용한다. 소프트웨어 애플리케이션 모두는 이 시스템 가상 프로토타입 상에서 구동돼야 하며 전체 시스템 동작에 관련한 정보를 제공한다. 또한 외부 센서, 액추에이터 및 실제 인터페이스의 동작도 함께 확인할 수 있다. 이 단계에서 병목현상, 소비전력 평가 등의 시스템 성능을 다양한 조건에서 확인하기 시작하고, 이를 해결하기 위해 충분히 자세한 세부 사항을 추가할 수 있다. 또한 우리가 인지하고 있는 제약 조건에 의거한 테스트 영역 설정을 통해 실제 시스템을 제한할 수도 있다. 이는 전체 시스템 성능에 관련한 질문을 시작할 수 있는 적절한 시기에 도달했음을 의미한다.

반복(ITERATION)
확실히 첫 번째 아키텍처가 가장 최선일 수는 없다. 지금까지의 단계를 거치면서 습득한 지식, 새로이 파생된 요구사항, 그리고 끊임없이 변화하는 시장 요구는 모두 유연한 프로세스에 대한 필요성을 지적한다. 반면 상당한 반복을 거치면서 얻은 시간의 대가로서 MDD 프로세스는 각 단계에서 실제 개선을 위한 정보를, 그리고 변화에 따른 결과를 반드시 제공하게 된다.

구현(IMPLEMENTATION)
현재 가능성 있는 구현 기술은 다양하고 또한 이를 위한 상세한 개발 흐름들이 존재한다. 이는 이 글의 범위를 벗어나 깊이 있게 다루지는 않는다. 예외 없이 구현에 있어서도 모델이 사용되고 있다는 언급만으로도 충분하다. 설계, 시뮬레이션 및 검증 등 모두가 전체적인 MDD 프로세스에 기여할 수 있고 또한 적절히 적용될 수 있다.

테스트(TEST)
테스트! 테스트는 항상 진가를 인정받기 힘든 업무에 속한다. 테스트는 제품이 만들어져 도착하는 즉시 다음과 같은 압박에 시달린다. “어떻게 하는 거지? 동작해? 성능은?” 이런 질문을 던진 이들이 알 것인가?  그들이 이것을 본 것은 이번이 처음이다!
모델을 통해 테스트 팀은 무엇을 측정할 수 있고, 이를 위해 무엇을 준비해야 하는 지 예측할 수 있다. 알려진 실제 결과에 의하면, 이 같은 하나의 단계에서만 전체 생산 일정에서 몇 개월의 단축이 가능하다고 한다. 여기에 우리는 이전에 평가한 경계가 여전히 유효한 지 확인하고, 또한 시스템 타이밍과 성능 등의 관점에서 깊이 있는 시험을 진행한다. 그리고 시험 결과에 의거해 미세 조정 등을 시행한다. 하지만 기능의 변경이 요구된다 할지라도 변경에 대한 노력을 기울이기에는 너무 늦은 시점이므로 기능 자체의 문제점을 찾고 확인하지 않는다.

추적(TRACE)
기존 설계 방법론에서는 선반 위 자리를 차지한 채 최종 제품 개발을 위해 미미한 역할만을 수행했던 요구사항이 MDD 설계 프로세스에서는 적극적으로 참여하게 된다. 또한 MDD 설계 프로세스의 각 단계에서 요구사항을 설계의 살아있는 일부로 반영하고,  초기 설계 목표, 요구 변화에 대한 반응 등을 계속적으로 추적하게 된다. 더 중요한 것은 이러한 과정 안에서 개별 기능 및 통합 시스템 성능 등을 검증하고 테스트한다.

문서화(DOCUMENT)
원더풀! 우리는 해냈고 제품은 출시 준비가 끝났다. 혹은 우리가 초기 의도한 대로 제품이 생산됐는가? 그리고 이를 보여줄 수 있는가? 다시 만들 수 있을까… 더 낫게?
이전에 진행된 것이 무엇인지 정확히 아는 것은 제품을 다시 만들고 이를 바탕으로 개선하며 시장을 선도하는 능력을 수립해 이를 계속적으로 유지하는 가장 중요한 부분이다. 따라서 MDD 프로세스 상에서 진행된 모든 사항을 문서화하는 것이 개발 프로세스에서 또 하나의 필수 요소다. 이를 통해 제품 자체와 개발하기 위한 프로세스를 지속적으로 개선하고 혁신할 수 있는 능력이 배양된다.

결론
MDD는 단지 하나의 좋은 아이디어 이상이다. 이는 실제적으로 설계 프로세스 관점에서 생산성을 보다 향상시키는 수단을 제공한다. MDD는 하향식 설계 흐름 전반에서 모델의 사용을 가능케 하고, 설계에 요구되는 일부를 자동 생성한다. 또한 재사용 및 표준 준수 절차의 채용은 궁극적으로 설계의 품질 향상에 기여한다. 시스템을 운영하는 제어 소프트웨어와 함께 디지털 및 아날로그 요소 시뮬레이션을 통해 기존의 프로세스에서 물리적인 프로토타입 생성 단계를 없애는 한편, 종이 서류에 의존한 설계 진행을 없애거나 현저히 줄일 수 있게 한다.
생산적인 모델 기반 개발 프로세스는 툴과 주요 문제점을 개발 주기의 초기에 발견할 수 있는 툴 내 역량을 통해 구현된다. 물론 해당 프로세스는 주로 시스템 통합의 훨씬 이전 단계에서 역할을 하게 된다.
모델 기반 개발은 복잡성 관리 측면에서의 기반을 제공하는 한편, 각각의 설계 단계에서 이루어지는 개별 기능이 거꾸로 해당 기능의 초기 요구사항 및 기능 사양과 직접 연결할 수 있도록 하며, 이를 통해 일관된 설계 의도의 진행을 돕는 역할을 수행한다. 가상 프로토타입 기반 내에서 각기 다른 도메인에서 생성된 모델들은 필요 단계에서 통합된다. 따라서 시스템 통합 시 발생할 수 있는 문제점은 해당 개발 단계에서 발견되고 해결된다. 이는 실제로 시스템 통합 문제 해결이 전체 프로세스의 초기 단계에서 이루어짐을 의미한다. 요구사항을 모델링 할 수 있는 툴을 적용하고 해당 모델을 통해 기술된 기능을 가상 환경에서 시스템으로 통합한다. 따라서 검증은 보다 선행 단계에서 이루어질 수 있다.