"프로토타입"의 두 판 사이의 차이
83번째 줄: | 83번째 줄: | ||
* 불충분한 분석 | * 불충분한 분석 | ||
제한된 프로토타입에 초점을 맞추면 개발자가 전체 프로젝트를 제대로 분석하지 못할 수도 있다. 이로 인해 더 나은 솔루션을 간과하거나, 불완전한 사양을 준비하거나, 제한된 프로토 타입을 유지관리하기 어려운 잘못 설계된 최종젝트로 변경될 수도 있다. 또한 프로토타입은 기능이 제한되어 있기 때문에 프로토타입이 최종 결과물의 기반으로 사용되는 경우 제대로 확장되지 않을 수도 있으며, 개발자가 프로토타입을 모델로 구축하는 데 너무 집중하면 눈에 띄지 않을 수 있다. | 제한된 프로토타입에 초점을 맞추면 개발자가 전체 프로젝트를 제대로 분석하지 못할 수도 있다. 이로 인해 더 나은 솔루션을 간과하거나, 불완전한 사양을 준비하거나, 제한된 프로토 타입을 유지관리하기 어려운 잘못 설계된 최종젝트로 변경될 수도 있다. 또한 프로토타입은 기능이 제한되어 있기 때문에 프로토타입이 최종 결과물의 기반으로 사용되는 경우 제대로 확장되지 않을 수도 있으며, 개발자가 프로토타입을 모델로 구축하는 데 너무 집중하면 눈에 띄지 않을 수 있다. | ||
− | *프로토타입과 완성된 시스텝의 사용자 | + | *프로토타입과 완성된 시스텝의 사용자 혼돈 |
사용자는 버려질 목적으로 만들어진 프로토타입이 실제로 완성되거나 다음기만 하면 되는 최종시스템이라고 생각하기 시작할 수 있다. 예를 들어 사용자는 프로토타입에 없을 수 있는 오류 검사나 보안 기능을 추가하는 데 필요한 노력을 인식하지 못한다. 이로 인해 개발자의 의도가 아닌 경우 프로토타입이 최종 시스템의 성능을 프로토타입이 정확하게 모델링할 것으로 예상할 수 있다. 또한 사용자는 검토를 위해 프로토타입에 포함된 기능에 연결한 다음 최종 시스템의 사양에서 제거할 수 있다. 사용자가 제안된 모든 기능을 최종 시스템에 포함하도록 요구할 수 있는 경우 충돌이 발생할 수 있다. | 사용자는 버려질 목적으로 만들어진 프로토타입이 실제로 완성되거나 다음기만 하면 되는 최종시스템이라고 생각하기 시작할 수 있다. 예를 들어 사용자는 프로토타입에 없을 수 있는 오류 검사나 보안 기능을 추가하는 데 필요한 노력을 인식하지 못한다. 이로 인해 개발자의 의도가 아닌 경우 프로토타입이 최종 시스템의 성능을 프로토타입이 정확하게 모델링할 것으로 예상할 수 있다. 또한 사용자는 검토를 위해 프로토타입에 포함된 기능에 연결한 다음 최종 시스템의 사양에서 제거할 수 있다. 사용자가 제안된 모든 기능을 최종 시스템에 포함하도록 요구할 수 있는 경우 충돌이 발생할 수 있다. | ||
+ | *사용자 목표에 대한 개발자의 오해 | ||
+ | 개발자는 광범위한 상업적 무넺를 이해하지 않고 사용자가 자신의 목표(예:액심 기능을 제 시간에 예산 내에서 제공)를 공유한다고 가정할 수 있다. 예를 들어 엔터프라이즈 소프트웨어 이벤트에 참석하는 사용자 대표는 이 기능에 추가 코딩을 요구하며 종종 추가 데이터베이스 액세스를 처리하기 위해 더 많은 하드웨어를 요구한다는 말을 듣지 않고 트랜잭션 감사(transaction advising)의 데모를 보았을 수도 있다. 사용자들은 모든 분야에서 감사를 요구할 수 있다고 믿는 반면, 개발자들은 사용자의 요구사항의 정도에 대해 가정했기 때문에 이것이 기능상 이상하다고 생각할 수 있다. 사용자 요구사항을 검토하지 전에 개발자가 전달을 약속했다면, 특히 사용자 관리가 요구사항을 이행하지 않음으로써 어느 정도 이점을 얻는 경우에 개발자는 난처한 상황에 있게 된다. | ||
+ | *프로토타입에 대한 개발자 애착 | ||
+ | 개발자는 제작에 많은 노력을 기울인 프로토타입에 애착을 가질 수 있다. 이것은 제한된 프로토타입을 적절한 기본 아키텍처를 가지고 있지 않을 때 최종 시스템으로 변환하려고 시도하는 것과 같은 문제를 발생시킬 수 있다. (이는 진화형 프로토타이핑이 아닌 일회용 프로토타이핑을 사용해야한다는 것을 시사할 수 있다.) | ||
+ | *프로토타입의 과도한 개발 시간 | ||
+ | 프로토타이핑의 핵심 속성은 신속하게 수행되어야한다는 사실이다. 만약 개발자가 이를 잊어 버리면 너무 복잡한 프로토타입을 개발하려고 할 수 있다. 프로토타입을 폐기할 때, 시제품이 제공하는 정밀하게 개발된 요구사항으로 인해 시제품 개발에 소용되는 시간을 보충할만큼 충분한 생산성 향상이 이루어지지 않을 수 있다. 사용자는 프로토타입의 세부 사항에 대한 논쟁에 갇혀 개발 팀을 잡고 최종 제품을 지연지킬 수 있다. | ||
+ | *프로토타입 구현 비용 | ||
+ | 프로토타이핑에 중점을 둔 개발 팀을 구성하기 위한 시작 비용이 높을 수 있다. 많은 기업들이 개발 방법론을 시행하고 있으며, 이를 변경하는 것은 재교육, 재설계 또는 둘다를 의미할 수 있다. 많은 회사가 작업자를 재교육하지 않고 프로토타이핑을 시작하는 경향이 있다. | ||
+ | ::프로토타이핑 기술을 채택할 때 공통적으로 발생하는 문제는 학습 곡선 뒤에 충분한 노력을 기울이지 않고 생산성에 대한 높은 기대다. 프로토타이핑 기법의 사용을 위한 교육 외에도, 기술을 지원하기 위한 기업 및 프로젝트별 기초 구조를 개발해야 할 필요성이 종종 간과되고 있다. 이러한 기본 구조를 생략하면 생산성이 저하되는 경우가 많다.<ref name="wiki_en"></ref> | ||
{{각주}} | {{각주}} |
2020년 9월 4일 (금) 14:31 판
프로토타입(prototype)은 '원형' 또는 '기본형'이라는 뜻으로서 다수의 사이트나 시스템을 개발하는데 필요한 기본 형태를 말한다. 시제품(試製品), 견본품, 초기형, 시작형이라고도 한다. 프로토타입은 정보시스템의 미완성 버전 또는 중요한 기능들이 포함되어 있는 시스템의 초기 모델이다. 프로토타입은 일반적으로 양산형으로 제작되기 전에 미리 제작해보는 초기 모델로, 사용자의 모든 요구사항이 정확하게 반영할 때까지 계속해서 개선·보완된다. 실제로 많은 애플리케이션들이 지속적인 프로토타입의 확장과 보강을 통해 최종 설계가 승인된다. 프로토타입을 복제하는 방식으로 사이트를 대량 제작을 할 수 있다. 프로토타입 개발 방법론은 소프트웨어 개발 방법론(SDM)의 일종이다.
목차
개요
프로토타입의 목적은 소프트웨어 사용자가 설명을 기반으로 디자인을 해석하고 평가할 필요없이 최종 제품의 디자인에 대한 개발자의 제안을 실제로 시도하여 평가할 수 있도록 하는 것이다. 소프트웨어 프로토타입은 소프트웨어의 기능과 잠재적인 위협 또는 문제에 대한 이해를 제공한다. 프로토타입은 최종 사용자가 고려하지 않은 요구 사항을 설명하고 증명하는데 사용할 수 있으며, 개발자와 클라이언트 간의 상업적 관계에서 핵심 요소가 될 수 있다. 특히 인터랙션 디자인은 이러한 목표를 가지고 프로토 타이핑을 많이 사용한다.[1]
단계
프로토타이핑(prototyping)의 과정은 4단계로 구분된다.
- 1단계: 사용자의 요구사항을 분석하며 시스템 설계자는 기본적인 요구사항이 도출되기까지 사용자와 함께 작업을 한다.
- 2단계: 1단계에서 도출된 요구사항을 만족시키는 프로토타입을 개발하여 앞으로 개발될 시스템의 가장 핵심적인 기능 위주로 개발한다.
- 3단계: 사용자가 개발된 프로토타입을 검토 및 사용을 통해 요구사항이 이행되고 있는지 확인하고, 보완을 위해 피드백을 제안한다.
- 4단계: 수정과 보완이 이루어지며 수정된 후에는 3단계로 돌아가 사용자가 만족할 때까지 3단계와 4단계를 반복한다.[2]
프로토타입 치수
수평 프로토타입
사용자 인터페이스 프로타입의 일반적인 용어는 수평 프로토타입이다. 데이터베이스 액세스와 같은 저수준 시스템 기능보다 사용자 상호 작용에 초점을 맞추어 전체 시스템 또는 서브시스템에 대한 넓은 시야를 제공한다. 수평 프로토타입은 다음의 목록에 유용하다.
- 사용자 인터페이스 요구 사항 및 시스템 범위 확인
- 비즈니스로부터 인수를 얻기 위한 시스템의 데모 버전
- 개발 시간, 비용 및 노력에 대한 예비 추정치를 개발한다.[1]
수직 프로토타입
수직 프로토타입은 단일 서브시스텝 또는 기능의 환전한 정교함을 강화한 것이다. 특정 기능에 대한 상세 요구사항을 얻는 데 유용하며 다음과 같은 장점이 있다.
- 데이터베이스 설계 개선
- 네트워크 크기 조정 및 성능 엔지니어링을 위한 데이터 볼륨 및 시스템 인터페이스 요구에 대한 정보 얻기
- 실제 시스템 기능가지 드릴 다운하여 복잡한 요구사항을 명확히 한다.[1]
프로토타입 유형
소프트웨어 프로토타입에는 다양한 변형이 있다. 그러나 모든 방법은 어떤 식으로든 일회용 프로토타이핑과 진화형 프토로타이핑이라는 두 가지 주요한 형태의 프로토타입에 기반한다.
일회용 프로토타이핑
폐쇄형 프로토타이핑(close-ended prototyping)이라고도 한다. 폐기(Throwaway) 또는 신속한 프로토타이핑(Rapid Prototyping)은 최종 제공 소프트웨어의 일부가 되지 않고 결국 폐기될 모델을 만드는 것을 의미한다. 사전 요구사항 수집이 완료된 후 시스템의 간단한 작업 모델을 구축하여 사용자에게 요구사항이 완성된 시스템으로 구현될 때 어떤 모습일지 시각적으로 보여준다. 이것을 신속한 프로토타이핑이라고도 한다. 일회용 프로토타이핑을 사용하는 가장 분명한 이유는 매우 초기 단계에서 신속하게 수행할 수 있기 때문이다. 사용자들이 요구사항에 대한 빠른 피드백을 받을 수 있다면 소프트웨어 개발 초기에 이를 개선할 수 있다. 개발 라이프사이클 초기에 변경하는 것은 그 시점에서 다시 실행할 것이 없기 때문에 매우 비용 효율적이다. 상당한 양의 작업을 수행한 후에 프로젝트가 변경되면 소프트웨어 시스템에 많은 종속성을 가지기 때문에 작은 변경을 구현하는 것만으로도 많은 노력이 필요할 수 있다. 시간과 비용의 한정된 예산으로 인해 폐기될 프로토타입에 비용을 많이 지출할 수 없기 때문에 일회용 프로토타입을 구현하는 데는 속도가 매우 중요하다.
프로토타입은 외관, 상호작용 및 타이밍 측면에서 실제 제품과 유사한 충실도에 따라 분류할 수 있다. 충실도가 낮은 일회용 프로토타입을 만드는 한 가지 방법은 종이 프로토타입(paper prototyping)이다. 프로토타입은 종이와 연필을 사용하여 구현해 실제 제품의 기능을 모방한 것이지만 전혀 닮지 않았다. 고밀도 일회용 프로토타입을 쉽게 제작할 수 있는 또다른 제작 방법은 GUI Builder를 사용하여 클릭 더미(click dummy)를 만드는 것이다. 클릭 더미는 목표 시스템과 유사하지만 어떤 기능도 제공하지 않는 프로토타입이다.
스토리보드, 애니매틱스, 드로잉의 사용은 일회용 프로토타이핑과 동일하지는 않지만 같은 계열에 속한다. 이것들은 비기능적인 구현이지만 시스템이 어떻게 보일지 보여준다.
일회용 프로토타입에서는 프로토타입은 폐기되고 최종 시스템은 구축될 것이라는 생각으로 제작되고 이 접근법의 단계는 다음과 같다.
- 예비 요구사항 작성
- 프로토타입 디자인
- 사용자 경험 / 프로토타입 사용, 새로운 요구사항 지정
- 필요한 경우 반복
- 최종 요구사항 작성[1]
신속한 프로토타이핑(Rapid Prototyping)
신속한 프로토타이핑은 비교적 짧은 조사 후 매우 초기 단계에서 시스템의 다양한 부분의 작업 모델을 만드는 것을 포함한다. 구축에 사용되는 방법은 일반적으로 매우 비공식적이며, 가장 중요한 요소는 모델이 제공되는 속도이다. 그 후 모델은 사용자가 자신의 기대치를 재점검하고 요구사항을 명확히 할 수 있는 출발점이 된다. 이 목표가 달성되면, 프로토타입 모델은 'thrown away'(버려지기)되고, 확인된 요구사항을 기반으로 시스템이 공식적으로 개발된다.[1]
종이 프로토타이핑(paper prototyping)
인간과 컴퓨터의 상호작용에서 종이 프로토타이핑은 사용자 중심 설계 프로세스에서 널리 사용되는 방법이며, 특히 사용자 인터페이스를 설계하고 테스트하기 위해 개발자가 사용자의 기대와 요구에 부합하는 소프트웨어를 만들 수 있도록 돕는 프로세스다. 그것은 버려지는 프로토타입핑이며 손으로 제작한 시제품이나 모델의 모델로 사용할 인터페이스 도면을 만드는 것을 포함한다. 종이 프로토타이핑은 간단해 보이지만, 사용적합성 시험 방법은 사용하기 쉬운 제품의 설계에 도움이 되는 유용한 피드백을 제공할 수 있다. 이것은 많은 사용적합성 전문가들이 지원한다.[3]
GUI Builder
GUI 디자이너라고도 알려진 그래픽 사용자 인터페이스 빌더(또는 GUI 빌더)는 WYSIWYG 편집기를 사용하여 설계자가 그래픽 제어 요소(흔히 위젯이라고 함)를 정렬할 수 있도록 하여 GUI 생성을 단순화하는 소프트웨어 개발 툴이다. GUI 빌더가 없는 경우, 프로그램이 실행될 때까지 시각적 피드백 없이 소스 코드에 각 위젯의 파라미터를 수동으로 지정하여 GUI를 구축해야 한다. 사용자 인터페이스는 일반적으로 이벤트 중심 아키텍처를 사용하여 프로그래밍되므로 GUI 구축자는 이벤트 중심 코드 생성도 단순화한다. 이 지원 코드는 위젯을 애플리케이션 로직을 제공하는 기능을 트리거하는 송신 및 수신 이벤트와 연결한다. Glade Interface Designer와 같은 일부 그래픽 사용자 인터페이스 빌더는 그래픽 제어 요소에 대한 모든 소스 코드를 자동으로 생성한다. Interface Builder와 같은 다른 것들은 애플리케이션에 의해 로드되는 직렬화된 개체 인스턴스를 생성한다.[4]
진화형 프로토타이핑
진화형 프로토타이핑(브레드보드 프로토타이핑이라고도 함)은 일회용 프로토타이핑과는 상당히 다르다. 진화형 프로토타이핑을 사용할 때의 주요 목표는 구조화된 방식으로 매우 견고한 프로토타입을 제작하여 지속적으로 개선하는 것이다. 이러한 접근방식의 이유는 진화형 프로토타입이 구축되면 새로운 시스템의 핵심이 되고, 개선사항과 추가 요구사항이 구축되기 때문이다. 진화형 프로토타이핑을 사용하여 시스템을 개발할 때 시스템은 지속적으로 개선되고 재구축된다. 진화형 프로토타입은 기능적 시스템이라는 점에서 일회용 프로토타입보다 장점이 있다. 사용자가 계획한 모든 기능이 제공되지는 않지만 최종 시스템이 제공될 때까지 임시로 사용할 수 있다. 진화형 프로토타이핑에서 개발자는 전체 시스템을 개발하는 대신 이해하는 시스템의 일부를 개발하는 데 집중할 수 있다.[1]
증분 프로토타이핑
최종 제품은 별도의 프로토타입으로 제작된다. 결국 개별 프로토타입은 전체 설계에 통합된다. 증분 프로토타이핑을 통해 사용자와 소프트웨어 개발자 간의 시간 간격이 줄어든다.[1]
익스트림 프로토타이핑
개발 과정으로서의 익스트림 프로토타이핑은 특히 웹 애플리케이션 개발에 사용된다.기본적으로 웹 개발은 앞의 단계를 기준으로 3단계로 세분화한다. 1단계는 주로 HTML 페이지로 구성된 정적 프로토타입이다. 2단계는 시뮬레이션 된 서비스 계층을 사용하여 프로그래밍되고 완전한 기능을 한다. 3단계는 서비스가 구현된다. 이 프로세스를 익스트림 프로토타이핑이라고 하며 두 번째 단계에 주의를 기울여야 한다. 이 프로세스는 계약 이외의 서비스에 대해서는 거의 관계없이 완전한 기능의 UI가 개발된다.[1]
장단점
장점
- 오류를 초기에 발견할 수 있다.
- 수정과 보완이 용이하다.[2]
- 개발 시간과 비용을 줄일 수 있다.
프로토타이핑은 개발자에게 제공되는 요구사항 및 사양의 품질을 향상 시킬 수 있다. 변경 사항은 나중에 개발 단계에서 발견될 때 구현하는 데 더 많은 비용이 들기 때문에 사용자가 진정으로 원하는 것을 조기에 결정하면 소프트웨어가 더 빠르고 저렴해질 수 있다.
- 프로토타이핑은 사용자 중심의 개발 방법으로 사용자의 요구 만족을 극대화할 수 있다.
프로토타입 제작은 사용자 참여를 필요로 하며, 더 우수하고 완벽한 피드백과 사양을 제공할 수 있도록 프로토타입과 상호작용을 가능하게 한다. 서용자가 검토 중인 프로토타입의 존재는 서로가 상대방이 말한 것을 이해한다고 믿을 때 발생하는 많은 오해와 의사소통의 오류를 방지한다. 사용자는 개발팀의 누구보다 문제 영역을 더 잘 알고 있기 때문에 사용작용을 증가시키면 유형 및 무형의 품질이 더 우수난 최종 제품이 될 수 있다. 최종 제품은 모양, 느낌 및 성느에 대한 사용자의 욕구를 충족시킬 가능성이 높다.[1]
단점
- 시스템의 유지보수에 필수적인 시스템의 문서화 과정이 지나치게 축소되거나 생략될 수 있다.
- 프로토타이핑으로 완성된 시스템은 컴퓨터 자원의 활용 측면에서 볼 때 효율적이지 못하다. 그러나 최근 컴퓨터 관련 기기들의 성능은 좋아지는 반면, 가격은 하락하면서 이 문제의 비중은 크게 감소되고 있다.[2]
- 불충분한 분석
제한된 프로토타입에 초점을 맞추면 개발자가 전체 프로젝트를 제대로 분석하지 못할 수도 있다. 이로 인해 더 나은 솔루션을 간과하거나, 불완전한 사양을 준비하거나, 제한된 프로토 타입을 유지관리하기 어려운 잘못 설계된 최종젝트로 변경될 수도 있다. 또한 프로토타입은 기능이 제한되어 있기 때문에 프로토타입이 최종 결과물의 기반으로 사용되는 경우 제대로 확장되지 않을 수도 있으며, 개발자가 프로토타입을 모델로 구축하는 데 너무 집중하면 눈에 띄지 않을 수 있다.
- 프로토타입과 완성된 시스텝의 사용자 혼돈
사용자는 버려질 목적으로 만들어진 프로토타입이 실제로 완성되거나 다음기만 하면 되는 최종시스템이라고 생각하기 시작할 수 있다. 예를 들어 사용자는 프로토타입에 없을 수 있는 오류 검사나 보안 기능을 추가하는 데 필요한 노력을 인식하지 못한다. 이로 인해 개발자의 의도가 아닌 경우 프로토타입이 최종 시스템의 성능을 프로토타입이 정확하게 모델링할 것으로 예상할 수 있다. 또한 사용자는 검토를 위해 프로토타입에 포함된 기능에 연결한 다음 최종 시스템의 사양에서 제거할 수 있다. 사용자가 제안된 모든 기능을 최종 시스템에 포함하도록 요구할 수 있는 경우 충돌이 발생할 수 있다.
- 사용자 목표에 대한 개발자의 오해
개발자는 광범위한 상업적 무넺를 이해하지 않고 사용자가 자신의 목표(예:액심 기능을 제 시간에 예산 내에서 제공)를 공유한다고 가정할 수 있다. 예를 들어 엔터프라이즈 소프트웨어 이벤트에 참석하는 사용자 대표는 이 기능에 추가 코딩을 요구하며 종종 추가 데이터베이스 액세스를 처리하기 위해 더 많은 하드웨어를 요구한다는 말을 듣지 않고 트랜잭션 감사(transaction advising)의 데모를 보았을 수도 있다. 사용자들은 모든 분야에서 감사를 요구할 수 있다고 믿는 반면, 개발자들은 사용자의 요구사항의 정도에 대해 가정했기 때문에 이것이 기능상 이상하다고 생각할 수 있다. 사용자 요구사항을 검토하지 전에 개발자가 전달을 약속했다면, 특히 사용자 관리가 요구사항을 이행하지 않음으로써 어느 정도 이점을 얻는 경우에 개발자는 난처한 상황에 있게 된다.
- 프로토타입에 대한 개발자 애착
개발자는 제작에 많은 노력을 기울인 프로토타입에 애착을 가질 수 있다. 이것은 제한된 프로토타입을 적절한 기본 아키텍처를 가지고 있지 않을 때 최종 시스템으로 변환하려고 시도하는 것과 같은 문제를 발생시킬 수 있다. (이는 진화형 프로토타이핑이 아닌 일회용 프로토타이핑을 사용해야한다는 것을 시사할 수 있다.)
- 프로토타입의 과도한 개발 시간
프로토타이핑의 핵심 속성은 신속하게 수행되어야한다는 사실이다. 만약 개발자가 이를 잊어 버리면 너무 복잡한 프로토타입을 개발하려고 할 수 있다. 프로토타입을 폐기할 때, 시제품이 제공하는 정밀하게 개발된 요구사항으로 인해 시제품 개발에 소용되는 시간을 보충할만큼 충분한 생산성 향상이 이루어지지 않을 수 있다. 사용자는 프로토타입의 세부 사항에 대한 논쟁에 갇혀 개발 팀을 잡고 최종 제품을 지연지킬 수 있다.
- 프로토타입 구현 비용
프로토타이핑에 중점을 둔 개발 팀을 구성하기 위한 시작 비용이 높을 수 있다. 많은 기업들이 개발 방법론을 시행하고 있으며, 이를 변경하는 것은 재교육, 재설계 또는 둘다를 의미할 수 있다. 많은 회사가 작업자를 재교육하지 않고 프로토타이핑을 시작하는 경향이 있다.
- 프로토타이핑 기술을 채택할 때 공통적으로 발생하는 문제는 학습 곡선 뒤에 충분한 노력을 기울이지 않고 생산성에 대한 높은 기대다. 프로토타이핑 기법의 사용을 위한 교육 외에도, 기술을 지원하기 위한 기업 및 프로젝트별 기초 구조를 개발해야 할 필요성이 종종 간과되고 있다. 이러한 기본 구조를 생략하면 생산성이 저하되는 경우가 많다.[1]
각주
참고자료
- WIKIPEDIA,〈Software prototyping〉, 《WIKIPEDIA》, 2020-08-08
- WIKIPEDIA,〈Paper prototyping〉, 《WIKIPEDIA》, 2020-07-09
- WIKIPEDIA,〈Graphical user interface builder〉, 《WIKIPEDIA》, 2020-08-2
- 위키백과,〈프로토타입〉, 《위키백과》, 2020-08-16
- 〈프로토타입〉, 《나무위키》
같이 보기
- 프로그래밍
- 소프트웨어 개발 방법론(SDM)