위키원
"프로토타입"의 두 판 사이의 차이
(내용 다듬기) |
|||
| (사용자 2명의 중간 판 28개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | '''프로토타입'''<!--프로토 타입-->(prototype)은 '원형' 또는 '기본형'이라는 | + | '''프로토타입'''<!--프로토 타입-->(prototype)은 '원형' 또는 '기본형'이라는 뜻으로, 다수의 [[사이트]]나 [[시스템]]을 개발하는 데 필요한 기본 형태이다. [[정보시스템]]의 미완성 버전 및 중요한 기능들이 포함된 시스템의 초기 모델이다. 또한, 일반적으로 양산형으로 제작되기 전에 미리 제작해보는 초기 모델로, 사용자의 모든 요구사항이 정확하게 반영할 때까지 계속해서 개선 및 보완된다. 실제로 많은 [[애플리케이션]]들이 지속적인 프로토타입의 확장과 보강을 통해 최종 설계가 승인된다. 복제하는 방식으로 사이트를 대량 제작을 할 수 있으며, 개발 방법론은 [[소프트웨어 개발 방법론]](SDM)의 일종이다. '''시제품'''(試製品), '''견본품''', '''초기형''', '''시작형'''이라고도 불린다. |
| − | == | + | ==개요== |
| − | + | 프로토타입은 [[소프트웨어]] 사용자가 설명을 기반으로 디자인을 해석하고 평가할 필요 없이 최종 제품의 디자인에 대한 개발자의 제안을 실제로 시도하여 평가하는 것을 목표로 하고 있다. 소프트웨어 프로토타입은 소프트웨어의 기능과 잠재적인 위협과 문제에 대한 이해를 제공한다. 프로토타입은 최종 사용자가 고려하지 않은 요구 사항을 설명하고 증명하는 데 사용할 수 있으며, 개발자와 클라이언트 간의 상업적 관계에서 핵심 요소가 될 수 있다. 특히, 인터랙션 설계는 이러한 목표를 가지고 프로토타이핑을 많이 사용한다.<ref name="wiki_en">Software prototyping WIKIPEDIA - https://en.wikipedia.org/wiki/Software_prototyping#Outline_of_the_prototyping_process</ref> | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | == 특징 == | ||
=== 장점 === | === 장점 === | ||
| − | + | 프로토타입은 오류를 초기에 발견할 수 있고, 수정과 보완이 용이하여 개발 시간과 비용을 줄일 수 있다. 또한, 프로토타이핑은 개발자에게 제공되는 요구사항 및 사양의 품질을 향상시킬 수 있다. 변경 사항은 나중에 개발 단계에서 발견될 때 구현하는 데 더 큰 비용이 들기 때문에 사용자가 진정으로 원하는 것을 조기에 결정하면 소프트웨어가 더 빠르고 저렴해질 수 있다. 프로토타이핑은 사용자 중심의 개발 방법으로 사용자의 요구 만족을 극대화할 수 있어 프로토타입 제작은 사용자 참여가 필요하며, 더 우수하고 완벽한 피드백과 사양을 제공할 수 있도록 프로토타입과 상호작용을 가능하게 한다. 사용자가 검토 중인 프로토타입의 존재는 서로가 상대방이 말한 것을 이해한다고 믿을 때 발생하는 많은 오해와 의사소통의 오류를 방지한다. 사용자는 개발팀의 누구보다 문제 영역을 더 잘 알고 있으므로 사용작용을 증가시키면 유형 및 무형의 품질이 더 우수한 최종 제품이 될 수 있다. 최종 제품은 모양, 느낌 및 성능에 대한 사용자의 욕구를 충족시킬 가능성이 크다.<ref name="wiki_en"></ref><ref name="wiki_ko"></ref> | |
| − | |||
| − | |||
| − | |||
=== 단점 === | === 단점 === | ||
| − | + | 프로토타입은 [[시스템 유지관리]]에 필수적인 시스템의 문서화 과정이 지나치게 축소되거나 생략될 수 있다는 단점이 있다. 프로토타이핑으로, 완성된 시스템은 컴퓨터 자원의 활용 측면에서 볼 때 효율적이지 못하지만, [[컴퓨터]] 관련 기기들의 성능은 좋아졌으며, 가격은 하락하면서 이 문제의 비중은 많이 감소하고 있다. 제한된 프로토타입에 초점을 맞추면, 개발자가 전체 프로젝트를 제대로 분석하지 못할 수도 있다. 이로 인해 더욱 나은 솔루션을 간과하고, 불완전한 사양을 준비하며, 제한된 프로토타입을 유지 관리하기 어려운 잘못 설계된 최종 프로젝트로 변경될 수도 있다. 또한, 프로토타입은 기능이 제한되어 있으므로 프로토타입이 최종 결과물의 기반으로 사용되는 경우 제대로 확장되지 않을 수도 있으며, 개발자가 프로토타입을 모델로 구축하는 데 너무 집중하면 눈에 띄지 않을 수 있다. 프로토타입과 완성된 시스템의 사용자 혼돈으로, 사용자는 버려질 목적으로 만들어진 프로토타입이 실제로 완성되거나 다듬기만 하면 되는 최종시스템이라고 생각할 수 있다. 예를 들어, 사용자는 프로토타입에 없을 수 있는 오류 검사나 보안 기능을 추가하는 데 필요한 노력을 인식하지 못한다. 이로 인해 개발자의 의도가 아닌 경우 프로토타입이 최종 시스템의 성능을 프로토타입이 정확하게 모델링 할 것으로 예상할 수 있다. 또한, 사용자는 검토를 위해 프로토타입에 포함된 기능에 연결한 다음 최종 시스템의 사양에서 제거할 수 있다. 사용자가 제안된 모든 기능을 최종 시스템에 포함하도록 요구할 수 있는 경우 충돌이 발생할 수도 있다. | |
| − | + | ||
| − | + | 개발자는 광범위한 상업적 문제를 이해하지 않고 사용자가 자신의 목표를 공유한다고 가정할 수 있다. 예를 들어, 엔터프라이즈 소프트웨어 이벤트에 참석하는 사용자 대표는 이 기능에 추가 코딩을 요구하며, 종종 추가 [[데이터베이스]] 액세스를 처리하기 위해 더 많은 하드웨어를 요구한다는 말을 듣지 않아 트랜잭션 감사(transaction advising)의 데모를 보았을 수도 있다. 사용자들은 모든 분야에서 감사를 요구할 수 있다고 믿지만, 개발자들은 사용자의 요구사항의 정도에 대해 가정했기 때문에 이것이 기능상 이상하다고 생각할 수 있다. 사용자 요구사항을 검토하기 전에 개발자가 전달을 약속했다면, 특히 사용자 관리가 요구사항을 이행하지 않음으로써 어느 정도 이점을 얻는 경우에 개발자는 난처한 상황에 있게 된다. 개발자는 제작에 많은 노력을 기울인 프로토타입에 애착을 둘 수 있다. 이것은 제한된 프로토타입을 적절한 기본 아키텍처를 가지고 있지 않을 때 최종 시스템으로 변환하려고 시도하는 것과 같은 문제를 발생시킬 수 있다. | |
| + | |||
| + | 프로토타이핑의 핵심 속성은 신속하게 수행되어야 한다. 만약, 개발자가 이를 잊어버리면 너무 복잡한 프로토타입을 개발하려고 할 수 있다. 프로토타입을 폐기할 때, 시제품이 제공하는 정밀하게 개발된 요구사항으로 인해 시제품 개발에 소용되는 시간을 보충할 만큼 충분한 생산성 향상이 이루어지지 않을 수 있다. 사용자는 프로토타입의 세부 사항에 대한 논쟁에 갇혀 개발팀을 잡고 최종 제품을 지연시킬 수 있다. 프로토타입의 구현 비용으로, 프로토타이핑에 중점을 둔 개발팀을 구성하기 위한 시작 비용이 높을 수 있다. 많은 기업이 개발 방법론을 시행하고 있으며, 이를 변경하는 것은 재교육, 재설계 또는 둘 다를 의미할 수 있다. 많은 회사가 작업자를 재교육하지 않고 프로토타이핑을 시작하는 경향이 있다. 프로토타이핑 기술을 채택할 때 공통으로 발생하는 문제는 학습 곡선 뒤에 충분한 노력을 기울이지 않고 생산성에 대한 높은 기대이다. 프로토타이핑 기법의 사용을 위한 교육 외에도, 기술을 지원하기 위한 기업 및 프로젝트별 기초 구조를 개발해야 할 필요성이 종종 간과되고 있으며, 이러한 기본 구조를 생략하면 생산성이 저하되는 경우가 많다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | == 프로토타이핑 == | ||
| + | 소프트웨어 프로토타입에는 다양한 변형이 있으며, 포로토타이핑(prototyping) 에서 사용된다. 모든 방법은 어떤 식으로든 일회용 프로토타이핑과 진화형 프로토타이핑이라는 두 가지 주요한 형태의 프로토타입에 기반을 둔다. 또한, 프로토 타이핑의 과정은 다음과 같은 4단계로 구분된다. | ||
| + | |||
| + | '''1단계''' : 사용자의 요구사항을 분석하며 시스템 설계자는 기본적인 요구사항이 도출되기까지 사용자와 함께 작업한다. | ||
| + | '''2단계''' : 1단계에서 도출된 요구사항을 만족하게 하는 프로토타입을 개발하여 앞으로 개발될 시스템의 가장 핵심적인 기능 위주로 개발한다. | ||
| + | '''3단계''' : 사용자가 개발된 프로토타입을 검토 및 사용을 통해 요구사항이 이행되고 있는지 확인하고, 보완을 위해 피드백을 제안한다. | ||
| + | '''4단계''' : 수정과 보완이 이루어지며 수정된 후에는 3단계로 돌아가 사용자가 만족할 때까지 3단계와 4단계를 반복한다.<ref name="wiki_ko">프로토타입 위키백과 - https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9C%ED%86%A0%ED%83%80%EC%9E%85</ref> | ||
| + | |||
| + | 또한, [[사용자 인터페이스]](UI) 프로타입의 일반적인 용어는 수평 프로토타입이다. 데이터베이스 액세스와 같은 저수준 시스템 기능보다 사용자 상호 작용에 초점을 맞추어 전체 시스템 또는 서브 시스템에 대한 넓은 시야를 제공한다. 수평 프로토타이핑은 다음의 목록에 유용하며, 사용자 인터페이스 요구 사항 및 시스템 범위를 확인하고, 비즈니스로부터 인수를 얻기 위한 시스템의 데모 버전 등 개발 시간과 비용 및 노력에 대한 예비 추정치를 개발한다. 수직 프로토타이핑은 단일 서브 시스템 또는 기능의 환전한 정교함을 강화한 것이다. 특정 기능에 대한 상세 요구사항을 얻는 데 유용하며, 데이터베이스 설계 개선과 네트워크 크기 조정 및 성능 엔지니어링을 위한 데이터 볼륨 및 시스템 인터페이스 요구에 대한 정보 얻기 및 실제 시스템 기능까지 드릴 다운하여 복잡한 요구사항을 명확히 한다는 장점이 있다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | ===일회용 프로토타이핑=== | ||
| + | 일회용 프로토타이핑은 폐쇄형 프로토타이핑(close-ended prototyping)이라고도 불린다. 폐기(Throwaway) 또는 신속한 프로토타이핑(Rapid Prototyping)은 최종 제공 소프트웨어의 일부가 되지 않고 결국 폐기될 모델을 만드는 것을 의미한다. 사전 요구사항 수집이 완료된 후 시스템의 간단한 작업 모델을 구축하여 사용자에게 요구사항이 완성된 시스템으로 구현될 때 어떤 모습일지 시각적으로 보여준다. 이것을 신속한 프로토타이핑이라고도 한다. 일회용 프로토타이핑을 사용하는 가장 분명한 이유는 매우 초기 단계에서 신속하게 수행할 수 있기 때문이다. 사용자들이 요구사항에 대한 빠른 피드백을 받을 수 있다면 소프트웨어 개발 초기에 이를 개선할 수 있다. 개발 생명주기 초기에 변경하는 것은 그 시점에서 다시 실행할 것이 없으므로 매우 비용 효율적이다. 상당한 양의 작업을 수행한 후에 프로젝트가 변경되면 소프트웨어 시스템에 많은 종속성을 가지기 때문에 작은 변경을 구현하는 것만으로도 많은 노력이 필요할 수 있다. 시간과 비용의 한정된 예산으로 인해 폐기될 프로토타입에 비용을 많이 지출할 수 없으므로 일회용 프로토타입을 구현하는 데는 속도가 매우 중요하다. | ||
| + | |||
| + | 프로토타입은 외관, 상호작용 및 타이밍 측면에서 실제 제품과 유사한 충실도에 따라 분류할 수 있다. 충실도가 낮은 일회용 프로토타입을 만드는 한 가지 방법은 종이 프로토타입(paper prototyping)이다. 프로토타입은 종이와 연필을 사용하여 구현해 실제 제품의 기능을 모방한 것이지만 전혀 다르다. 고밀도 일회용 프로토타입을 쉽게 제작할 수 있는 또 다른 제작 방법은 [[그래픽 사용자 인터페이스]](GUI) 빌더(Builder)를 사용하여 클릭 더미(click dummy)를 만드는 것이다. 클릭 더미는 목표 시스템과 유사하지만 어떤 기능도 제공하지 않는 프로토타입이다. 스토리보드, 애니매틱스, 드로잉의 사용은 일회용 프로토타이핑과 동일하지는 않지만 같은 계열에 속하며, 이것들은 비기능적인 구현이지만 시스템이 어떻게 보일지 보여준다. 일회용 프로토타입에서는 프로토타입은 폐기되고 최종 시스템은 구축될 것이라는 생각으로 제작되는 이 접근법은 예비 요구사항 작성, 프로토타입 디자인, [[사용자 경험]](UX) 및 프로토타입 사용과 새로운 요구사항을 지정한다. 또한, 필요한 경우 반복되어 최종 요구사항을 작성해야 한다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | ====신속한 프로토타이핑==== | ||
| + | 신속한 프로토타이핑(Rapid Prototyping)은 비교적 짧은 조사 후 매우 초기 단계에서 시스템의 다양한 부분의 작업 모델을 만드는 것을 포함한다. 구축에 사용되는 방법은 일반적으로 매우 비공식적이며, 가장 중요한 요소는 모델이 제공되는 속도이다. 그 후 모델은 사용자가 자신의 기대치를 재점검하고 요구사항을 명확히 할 수 있는 출발점이 된다. 이 목표가 달성되면, 프로토타입 모델은 'thrown away'(버려지기) 되고, 확인된 요구사항을 기반으로 시스템이 공식적으로 개발된다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | ====종이 프로토타이핑==== | ||
| + | 인간과 컴퓨터의 상호작용에서 종이 프로토타이핑(paper prototyping)은 사용자 중심 설계 프로세스에서 널리 사용되는 방법이며, 특히 사용자 인터페이스를 설계하고 테스트하기 위해 개발자가 사용자의 기대와 요구에 부합하는 소프트웨어를 만들 수 있도록 돕는 프로세스다. 그것은 버려지는 프로토타이핑이며 손으로 제작한 시제품이나 모델의 모델로 사용할 인터페이스 도면을 만드는 것을 포함한다. 종이 프로토타이핑은 간단해 보이지만, 사용 적합성 시험 방법은 사용하기 쉬운 제품의 설계에 도움이 되는 유용한 피드백을 제공할 수 있다. 이것은 많은 사용 적합성 전문가들이 지원한다.<ref>Paper prototyping WIKIPEDIA - https://en.wikipedia.org/wiki/Paper_prototyping</ref> | ||
| + | |||
| + | ====그래픽 사용자 인터페이스 빌더==== | ||
| + | 그래픽 사용자 빌더(GUI Builder)는 디자이너라고도 알려진 그래픽 사용자 인터페이스 빌더는 위지위그(WYSIWYG) 편집기를 사용하여 설계자가 그래픽 제어 요소를 정렬할 수 있도록 하여 그래픽 사용자 인터페이스 생성을 단순화하는 소프트웨어 개발 도구이다. 빌더가 없는 그래픽 사용자 인터페이스는 프로그램이 실행될 때까지 시각적 피드백 없이 소스 코드에 각 위젯의 파라미터를 수동으로 지정하여 그래픽 사용자 인터페이스를 구축해야 한다. 사용자 인터페이스는 일반적으로 이벤트 중심 아키텍처를 사용하여 프로그래밍이 되므로, 그래픽 사용자 인터페이스 구축자는 이벤트 중심 코드 생성도 단순화한다. 이 지원 코드는 위젯을 애플리케이션 로직을 제공하는 기능을 트리거하는 송신 및 수신 이벤트와 연결한다. 글레이드 인터페이스 디자이너(Glade Interface Designer)와 같은 일부 그래픽 사용자 인터페이스 빌더는 그래픽 제어 요소에 대한 모든 소스 코드를 자동으로 생성한다. 인터페이스 빌더와 같은 다른 것들은 [[애플리케이션]]에 의해 로드되는 직렬화된 개체 인스턴스를 생성한다.<ref>Graphical user interface builder WIKIPEDIA - https://en.wikipedia.org/wiki/Graphical_user_interface_builder</ref> | ||
| + | |||
| + | ===진화형 프로토타이핑=== | ||
| + | 진화형 프로토타이핑(Evolutionary prototyping)은 일회용 프로토타이핑과는 상당히 다르다. 진화형 프로토타이핑을 사용할 때의 주요 목표는 구조화된 방식으로 매우 견고한 프로토타입을 제작하여 지속해서 개선하는 것이다. 이러한 접근방식의 이유는 진화형 프로토타입이 구축되면 새로운 시스템의 핵심이 되고, 개선사항과 추가 요구사항이 구축되기 때문이다. 진화형 프로토타이핑을 사용하여 시스템을 개발할 때 시스템은 지속해서 개선되고 재구축된다. 진화형 프로토타입은 기능적 시스템이라는 점에서 일회용 프로토타입보다 장점이 있다. 사용자가 계획한 모든 기능이 제공되지는 않지만, 최종 시스템이 제공될 때까지 임시로 사용할 수 있다. 진화형 프로토타이핑에서 개발자는 전체 시스템을 개발하는 대신 이해하는 시스템 일부를 개발하는 데 집중할 수 있다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | ===증분 프로토타이핑=== | ||
| + | 최종 제품은 별도의 프로토타입(Incremental prototyping)으로 제작된다. 결국, 개별 프로토타입은 전체 설계에 통합된다. 증분 프로토타이핑을 통해 사용자와 소프트웨어 개발자 간의 시간 간격이 줄어든다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | ===익스트림 프로토타이핑=== | ||
| + | 개발 과정으로서의 익스트림 프로토타이핑(Extreme prototyping)은 특히 웹 애플리케이션 개발에 사용된다. 기본적으로 웹 개발은 앞의 단계를 기준으로 3단계로 세분화한다. 1단계는 주로 [[HTML]] 페이지로 구성된 정적 프로토타입이다. 2단계는 시뮬레이션 된 서비스 계층을 사용하여 프로그래밍이 되고 완전한 기능을 한다. 3단계는 서비스가 구현된다. 이 프로세스를 익스트림 프로토타이핑이라고 하며 두 번째 단계에 주의를 기울여야 한다. 이 프로세스는 계약 이외의 서비스에 대해서는 거의 관계없이 완전한 기능의 사용자 인터페이스가 개발된다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | ==활용== | ||
| + | ===프로젝트=== | ||
| + | 프로토타입은 어떤 형태로든 항상 사용해야 한다. 그러나, 프로토타이핑은 사용자와 많은 상호 작용이 있는 시스템에서 가장 유용하다. 프로토타이핑은 온라인 시스템의 분석 및 설계, 특히 화면 대화 상자의 사용이 더 많은 증거가 있는 [[트랜잭션]] 처리에 매우 효과적이라는 사실이 밝혀졌다. 컴퓨터와 사용자 간의 상호 작용이 클수록 빠른 시스템을 구축하고 사용자가 함께 플레이할 수 있는 이점이 더 커진다. 일괄 처리(batch processing)나 대부분 계산을 수행하는 시스템과 같이 사용자 상호작용이 거의 없는 시스템은 프로토타이핑 이점의 의미가 없다. 때때로 시스템의 기능을 수행하는 데 필요한 코딩이 너무 집약적일 수 있고 프로토타이핑이 제공할 수 있는 잠재적 이득이 너무 작을 수 있다. 프로토타이핑은 사람과 컴퓨터의 인터페이스(human-computer interfaces)를 설계하는 데 특히 유용하다. | ||
| + | |||
| + | ;배치 프로세싱 | ||
| + | 배치 프로세싱<!--일괄처리, 일괄 처리, 배치 프로세스-->(batch processing)은 컴퓨터 프로그램 흐름에 따라 순차적으로 자료를 처리하는 방식을 뜻한다. 초기의 일괄처리 방식은 사용자와 상호작용하는 것이 불가능했지만, 운영 체제가 발전함에 따라 프로그램 입출력을 통해 상호작용하는 것이 가능해졌다. 일괄 처리는 1950년대 전자 컴퓨팅 초기 시절 이후 메인프레임 컴퓨터와 함께하고 있다. 일괄 처리 시스템은 일정 기간마다 주기적으로 한꺼번에 처리할 필요가 있고, 그룹별로 분류시킬 수 있는 성질을 가지고 있으며, 순차 접근방법을 사용할 수 있는 업무. 즉, 처리 요건이 일괄적인 업무에 대해 유사한 자료를 한데 모아 일정한 형식으로 분류한 뒤 한번에 일괄 처리함으로써 시간과 비용을 절감하여 업무의 효율성을 향상시킨다. 데이터 처리의 경우, 급여명세서나 봉급계산, 전화요금, 전기요금, 수도세, 성적처리 등이 일반적으로 이용되는 곳이다.<ref>일괄 처리 위키백과 - https://ko.wikipedia.org/wiki/%EC%9D%BC%EA%B4%84_%EC%B2%98%EB%A6%AC</ref> | ||
| + | |||
| + | ===동적 시스템 개발 방법=== | ||
| + | 동적 시스템 개발 방법(DSDM, Dynamic System Development Method)은 핵심 기법으로 프로토타이핑에 크게 의존하는 비즈니스 솔루션을 제공하기 위한 프레임워크로, 자체적으로 ISO 9001이 승인되었다. 그것은 프로토타입의 가장 잘 이해되는 정의로 확장한다. 동적 시스템 개발 방법에 따르면 프로토타입은 다이어그램, 비즈니스 프로세스 또는 생산에 투입된 시스템일 수 있다. 동적 시스템 개발 방법 프로토타입은 단순한 형태에서보다 포괄적인 형태로 진화하는 점진적 형태로 만들어졌으며, 동적 시스템 개발 방법 프로토타입은 폐기되거나 진화될 수 있다. 진화형 프로토타입은 수평 및 수직으로 진화할 수 있다. 프로토타입 범주의 동적 시스템 개발 방법에서는 자동화되는 비즈니스 프로세스를 설계하고 시연하는 데 사용되는 비즈니스 프로토타입, 사용자 인터페이스 설계의 사용성, 접근성, 모양 및 느낌을 정의, 개선 및 시연하는 데 사용되는 사용성 프로토타입을 권장한다. 또한, 시스템의 최대 부하 시스템 성능을 정의와 시연 및 예측하고 시스템의 기타 비기능적 측면을 시연 및 평가하는 데 사용하는 성능 및 용량 프로토타입, 설계 접근 방식 및 개념을 개발과 시연 및 평가하는 데 사용되는 기능 및 기술의 프로토타입을 권장한다. 프로토타입의 동적 시스템 개발 방법 수명주기는 다음과 같다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | #프로토타입 식별 | ||
| + | #계획에 동의 | ||
| + | #프로토타입 만들기 | ||
| + | #프로토타입 검토 | ||
| + | |||
| + | ===운영 프로토타이핑=== | ||
| + | 운영 프로토타이핑(Operational prototyping)은 일회용 및 진화형 프로토타이핑을 기존의 시스템 개발과 통합하는 방법으로, 앨런 데이비스(Alan Davis)에 의해 제안되었다. 앨런 데이비스의 신념은 "급속한 프로토타입에 품질을 재적합"하려고 하는 것이 두 접근법을 결합하려고 할 때 올바른 방법이 아니라는 것이다. 그의 아이디어는 진화형 프로토타이핑 방법론에 참여하여 각각의 진화 후에 시스템의 특징을 신속하게 프로토타입 화하는 것이다. 구체적인 방법론 단계 방법의 핵심은 잘 훈련된 프로토타입 제작자가 사용자 사이트에 접속할 수 있도록 하는 것이다. 운영 프로토타이핑 방법론은 복잡하고 사전에 알려진 요구사항이 거의 없는 시스템에서 많은 이점을 가지며, 구체적인 방법론 단계는 다음과 같다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | # 진화형 프로토타입은 기존의 개발 전략을 사용하여 구성되고 기준으로 만들어지며 잘 이해되는 요구사항만 지정하고 구현한다. | ||
| + | # 베이스라인 사본은 훈련된 프로토타입과 함께 여러 고객 사이트로 전송된다. | ||
| + | # 각 사이트에서 프로토타입 제작자는 시스템의 사용자를 감시한다. | ||
| + | # 사용자가 문제를 발견하거나 새로운 기능이나 요구 사항을 생각할 때마다 프로토타입이 이를 기록한다. 이를 통해 사용자는 문제를 기록하지 않아도 되고 작업을 계속할 수 있다. | ||
| + | # 사용자 세션이 끝나면 프로토타입은 기본 시스템 위에 일회용 프로토타입을 구성한다. | ||
| + | # 사용자는 이제 새로운 시스템을 사용하고 평가한다. 새로운 변경 사항이 적용되지 않거나 효과적이지 않다면 프로토타입 제작자는 이를 제거한다. | ||
| + | # 사용자가 변경 사항을 좋아하며 프로토타입 제작자는 기능향상 요청을 작성하여 개발팀에 전달한다. | ||
| + | # 개발팀은 모든 사이트에서 변경 요청을 받은 다음 기존 방법을 사용하여 새로운 진화형 프로토타입을 생성한다. | ||
| + | |||
| + | ===진화 시스템 개발=== | ||
| + | 진화 시스템 개발(Evolutional Systems Development)은 진화 프로토타이핑을 공식적으로 구현하려는 방법론의 한 종류다. 시스템 크래프트(Systemscraft)라고 불리는 특정 유형은 존 크리니온(John Crinnion)의 저서 '진화 시스템 개발(Evolutionary Systems Development)'에서 설명한다. 시스템 크래프트는 구현된 특정 환경에 맞게 수정하고 조정되어야 하는 프로토타입 방법론으로 설계되었다. 진화형 프로토타이핑과 달리 초기 요구사항부터 작업 시스템을 만들어 일련의 개정으로 구축하는 것이다. 또한, 시스템 개발 전반에 걸쳐 사용되고 있는 전통적인 분석에 큰 중점을 두고 있다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | ===진화적 급속한 발전=== | ||
| + | 진화적 급속한 발전(Evolutionary Rapid Development, ERD)은 국방고등연구사업청(DARPA) 정보기술사무소의 기술 개발 및 통합대리인인 소프트웨어 생산성 컨소시엄에 의해 개발되었다. ERD의 기본은 구성요소의 재사용, 소프트웨어 템플릿의 사용 및 아키텍처 템플릿에 기반을 둔 소프트웨어 시스템을 구성하는 개념이다. 변화하는 사용자 요구와 기술에 신속하게 대응하는 시스템 기능의 지속인 진화는 솔루션 클래스를 대표하는 진화가 가능한 아키텍처에 의해 강조된다. 이 프로세스는 소프트웨어 및 시스템 엔지니어링 분야를 통합하여 소규모 기술자 기반팀의 사용에 중점을 둔다. ERD 기반 프로젝트 성공의 핵심은 기술, 시장 또는 고객 요구사항의 변화에 신속하게 대응할 수 있는 첨단 기술과 기능, 인프라 및 구성 요소의 병렬 탐색 분석 밑 개발과 채택이다. 사용자의 의견을 이끌어내기 위해, 이해 관계자와 자주 예정된 임시 및 즉시 회의를 개최한다. 설계 및 구현 결정이 확정되기 전에 피드백을 요청하기 위해 시스템 기능 시연을 한다. 시스템이 사용자나 고객 요구를 더 잘 지원할 방법에 대한 통찰력을 제공하기 위해 빈번한 릴리스를 사용할 수 있도록 제공된다. 이를 통해 시스템이 기존의 사용자 요구를 충족시키기 위해 발전할 수 있다. | ||
| + | |||
| + | 시스템에 대한 설계 프레임워크는 기존의 발표된 표준 또는 사실상의 표준을 사용하는 것에 기반을 둔다. 시스템은 성능, 용량 및 기능에 대한 고려 사항을 포함하는 일련의 기능을 발전시킬 수 있도록 구성되어 있다. 아키텍처는 서비스 및 해당 구현을 캡슐화하는 추상 인터페이스 측면에서 정의된다. 아키텍처는 하나 이상의 시스템 인스턴스 개발을 안내하는 데 사용되는 템플릿 역할을 한다. 서비스를 구현하기 위해 여러 [[응용프로그램]] 구성요소를 사용할 수 있도록 한다. 변경 가능성이 없는 핵심 기능 집합도 식별 및 설정된다. ERD [[프로세스]]는 이해관계자가 자신의 요구와 기대를 전달하는 방법으로 종이제품보다는 입증된 기능을 사용하도록 구성된다. 이러한 빠른 전송 목표의 핵심은 타임박스(timebox) 방법의 사용이다. 타임박스는 특정 작업(예:기능성의 집합 개발)이 수행되어야 하는 고정된 기간이다. 어떤 막연한 목표를 충족시키기 위해 시간을 확장하는 것을 허용하기보다는, 시간은 고정되어 있고(달력 주와 사람 시간의 측면에서 모두) 이러한 제약 내에서 현실적으로 달성할 수 있는 일련의 목표를 정한다. 개발이 랜덤워크(random walk)로 전락하는 것을 방지하기 위해 장기 계획을 정의해 반복을 유도한다. 이 계획들은 전체 시스템에 대한 비전을 제공하고 프로젝트에 대한 경계(예:제약조건)를 설정한다. 프로세스 내의 각 반복은 이러한 장기 계획의 맥락에서 수행된다. | ||
| + | |||
| + | 아키텍처가 구축되면 소프트웨어가 통합되고 매일 테스트 된다. 이를 토대로 팀은 진행 상황을 객관적으로 평가하고 잠재적인 문제를 신속하게 파악할 수 있다. 소량의 시스템이 한 번에 통합되기 때문에 결함을 진단하고 제거하는 속도가 빠르다. 일반적으로 시스템이 항상 활동할 준비가 되어 있으므로 사용자 데모는 단기간에 개최할 수 있다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | ;타임박스 | ||
| + | 타임박스(timebox)는 계획된 활동이 이루어지는 시간 박스라고 불리는 일정한 기간을 할당한다. 여러 프로젝트 관리 접근법과 개인 시간 관리를 위해 사용된다. 프로젝트 관리에서는 프로젝트 계획 기법으로 사용되면 일정은 여러 개의 별도 기간으로 나뉘며, 각 파트에는 자체 산출물, 마감일, 예산이 있다. 타임박스 없이 프로젝트는 대개 일정한 범위까지 작동하는데, 이 경우 계획된 시간 범위 내에서 일부 결과물을 완료할 수 없다는 것이 명확해지면 마감일을 연장하거나 더 많은 사람이 참여해야 하며 종종 두 가지 모두 발생한다. 이때 프로젝트의 일정이 지연되고 비용이 증가하며, 품질이 저하될 수 있다. 프로젝트에서 타임박스는 마감일이 정해져 있어 범위를 줄여야 한다는 의미이다. 이는 조직이 가장 중요한 산출물을 먼저 완성하는 데 집중해야 함을 의미하기 때문에, 타임박스는 산출물의 우선순위를 정하는 계획과 연계된다. 타임박스는 리스크 관리를 위해 사용되는데, 불확실한 업무/시간 관계, 즉 마감일을 쉽게 넘길 수 있는 작업을 명시적으로 식별하기 위해 리스크 관리의 한 형태로 사용된다. <ref>Timeboxing WIKIPEDIA - https://en.wikipedia.org/wiki/Timeboxing Timeboxing</ref> | ||
| + | |||
| + | ==도구== | ||
| + | 프로토타이핑을 효율적으로 사용하려면 조직에 적절한 도구와 이러한 도구를 사용하도록 교육을 받은 직원이 있어야 한다. 프로토타이핑에 사용되는 도구는 신속한 시제품 제작에 사용되는 4세대 프로그래밍 언어와 같은 개별 도구에서 복잡한 통합케이스 도구까지 다양할 수 있다. 비주얼 베이직이나 콜드퓨전 같은 4세대 비주얼 프로그래밍 언어는 가격이 저렴하고 잘 알려졌으며, 비교적 사용하기 쉽고 빠르게 사용할 수 있어 자주 사용된다. 요구사항 엔지니어링 환경과 요구사항 분석을 지원하는 케이스(CASE) 도구는 군대 또는 대규모 조직에 의해 개발되거나 선택된다. GE 연구개발센터의 LYMB와 같은 객체지향 도구도 개발되고 있다. 사용자는 스프레드시트에서 응용프로그램의 구성요소를 직접 프로토타입으로 작성할 수 있다. | ||
| + | 웹 기반 응용프로그램의 인기가 계속 증가함에 따라 이러한 응용프로그램의 프로토타이핑을 위한 도구도 갖추게 된다. [[부트스트랩]](Bootstrap), [[파운데이션]](Foundation (framework)) 및 [[AngularJS]]와 같은 프레임워크는 개념 증명을 신속하게 구성하는 데 필요한 도구를 제공한다. 이러한 프레임워크는 일반적으로 개발자가 웹 애플리케이션을 신속하게 프로토타이핑할 수 있도록 하는 일련의 제어, 상호작용 및 설계 지침으로 구성된다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | *부트스트랩(Bootstrap (front-end framework)) : 부트스트랩은 모바일 최초의 반응형 프론트 엔드 웹 개발을 위한 무료 오픈 소스 CSS 프레임워크다. 부트스트랩은 웹 앱과 반대로 유익한 웹 페이지 개발을 단순화하는 데 초점을 맞춘 웹 프레임워크다. 웹 프로젝트에 부트스트랩을 추가하는 주된 목적은 색상, 크기, 글꼴 및 레이아웃에 대한 Bootstrap의 선택을 해당 프로젝트에 적용하는 것이다. 부트스트랩은 개발자들이 원하는 대로 요소들에 대한 선택이 주된 요인이다. 프로젝트에 추가되면 Bootstrap은 모든 HTML 요소에 대한 기본 스타일 정의를 제공한다. 그 결과는 웹 브라우저를 가로지르는 산문, 테이블, 양식 요소들의 균일한 출현이다. 또한, 부트스트랩에는 jQuery 플러그인의 형태로 여러 자바스크립트 구성요소가 함께 제공된다. Bootstrap의 가장 눈에 띄는 구성 요소는 전체 웹 페이지에 영향을 미치는 레이아웃 구성 요소다. 페이지의 다른 모든 요소가 배치되므로 기본 레이아웃 구성 요소를 "컨테이너"라고 하는데, 개발자는 고정 너비 컨테이너와 유동 너비 컨테이너 중에서 선택할 수 있습니다.<ref>Bootstrap (front-end framework) WIKIPEDIA - https://en.wikipedia.org/wiki/Bootstrap_(front-end_framework)</ref> | ||
| + | |||
| + | *파운데이션(Froundation framework) : 파운데이션은 응답성이 뛰어난 프론트 엔트 프레임워크다. 파운데이션은 자바스크립트(JavaScript) 확장이 제공하는 선택적 기능뿐만 아니라 타이포그래피, 양식, 버튼, 내비게이션 및 기타 인터페이스를 포함한 반응형 그리드, HTML 및 CSS UI 구성요소, 템플릿 및 코드 스니펫을 제공한다. 파운데이션은 오픈소스 프로젝트로 ZRUB에서 관리하다가 2019년부터 자원봉사자들에 의해 유지되고 있다. Foundation은 수많은 브라우저와 장치를 위해 설계되고 테스트 되었다. 빠른 개발을 위한 모범 사례를 디자이너에게 제공하는 Sass / SCSS로 구축 된 모바일 최초의 반응 형 프레임 워크다. 프레임 워크에는 반응 형 사이트를 빠르게 프로토 타이핑하는 데 필요한 가장 일반적인 패턴이 포함되어 있다. Sass 믹스 인을 사용하여 Foundation 구성 요소는 쉽게 스타일을 지정하고 확장 할 수 있다.<ref>Foundation (framework) WIKIPEDIA - https://en.wikipedia.org/wiki/Foundation_(framework)</ref> | ||
| + | |||
| + | *AngularJS : AngulJS는 JavaScript 기반의 오픈소스 프런트 엔드 웹 프레임워크로, 주로 구글과 개인 및 기업 공동체가 단일 페이지 애플리케이션 개발 시 직면하는 많은 난제를 해결하기 위해 유지한다. 풍부한 인터넷 애플리케이션에서 일반적으로 사용되는 구성요소와 함께 클라이언트 측 모델-뷰-컨트롤러(MVC) 및 모델-뷰-뷰 모델(MVVM) 아키텍처에 대한 프레임워크를 제공하여 그러한 애플리케이션의 개발과 시험을 모두 단순화하는 것을 목표로 한다. MongoDB 데이터베이스, Express.js 웹 애플리케이션 서버 프레임워크, Angul.js 자체, Node.js 서버 런타임 환경으로 구성된 MEAND 스택의 프런트 엔드로 AngulJS가 사용된다.<ref>AngularJS WIKIPEDIA - https://en.wikipedia.org/wiki/AngularJS</ref> | ||
| + | |||
| + | ===화면 생성기, 설계 도구 및 소프트웨어 공장=== | ||
| + | 1985년부터 로마 연구소에서 개발 중인 요구사항 엔지니어링 환경(REE)은 복잡한 시스템의 중요한 측면 모델을 신속하게 표현, 구축 및 실행할 수 있는 통합 도구 세트를 제공한다. 시스템 분석가가 시스템 구성요소의 기능, 사용자 인터페이스 및 성능 프로토타입 모델을 신속하게 구축할 수 있는 통합 도구 세트이다. 이러한 모델링 활동은 복잡한 시스템에 대한 이해를 높이고 부정확한 요구사항의 사양이 시스템 개발 프로세스 동안 비용과 일정에 미치는 영향을 줄이기 위해 수행된다. 모델은 행사되는 모델의 특정한 행동 양상에 따라 다양한 수준의 추상화 또는 세분화로 쉽게 구성될 수 있다. | ||
| + | RIE는 세 부분으로 구성되어 있다. 첫 번째 프로토타입은 신속한 시제품을 지원하도록 특별히 설계된 CASE 도구다. 두 번째 부분은 RAP(Rapid Interface Protesting System) 또는 RIP(Rapid Interface Protesting System)로 불리며, 사용자 인터페이스의 생성을 용이하게 하는 도구 모음이다. RIE의 세 번째 부분은 RIP와 프로토타입에 대한 사용자 인터페이스로 그래픽화되어 사용이 용이하도록 고안되었다. | ||
| + | |||
| + | RIE의 개발자인 로마 연구소는 그들의 내부 요구사항 수집 방법론을 지원하기 위해 의도했다. 방법은 크게 세 부분으로 나뉜다. | ||
| + | *다양한 소스(사용자, 다른 시스템에 대한 인터페이스), 사양 및 일관성 검사에서 추출 | ||
| + | *다양한 사용자의 요구가 서로 상충하지 않고 기술적으로 경제적으로 실현 가능한 분석 | ||
| + | *파생된 요구 사항이 사용자 요구를 정확하게 반영하는지 검증[15] | ||
| + | 1996년 Roma Labs는 소프트웨어 생산성 솔루션(SPS)과 계약을 체결하여 "요구사항 사양, 시뮬레이션, 사용자 인터페이스 프로토타이핑, 하드웨어 아키텍처에 대한 요구 사항 매핑 및 코드 생성을 지원하는 상업적 품질 RIE"를 개발했다. 이 시스템은 Advanced Requirements Engineering Workstation 또는 AREW라고 한다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | ===비 관계형 환경=== | ||
| + | 데이터의 비 관계적 정의(예: Cache 또는 연관 모델 사용)는 시뮬레이션 반복 시마다 데이터를 정규화할 필요성을 지연시키거나 방지하여 최종 사용자 프로토타이핑의 생산성을 높일 수 있다. 이는 비즈니스 요구 사항이 더 일찍, 더 명확해질 수 있지만, 대상 프로덕션 시스템에서 요구 사항이 기술적으로 경제적으로 실행 가능한지 구체적으로 확인하지는 않는다.<ref name="wiki_en"></ref> | ||
| + | |||
| + | ===PSDL=== | ||
| + | PSLD은 실시간 소프트웨어를 설명하는 프로토타입 설명 언어다. 관련 도구 세트는 컴퓨터 보조 프로토타이핑 시스템(Computer Aided Prototyping System, CAPS)이다.<ref name="wiki_en"></ref> 타이밍 제약으로 인해 구현 및 하드웨어 종속성이 발생하기 때문에 엄격한 실시간 요구사항이 있는 소프트웨어 시스템을 프로토타이핑하는 것은 어렵다. PSDL은 선언적 타이밍 제약을 포함하는 제어 추상화를 도입하여 이러한 문제를 해결한다. CAPS는 이 정보를 사용하여 코드 및 관련 실시간 일정을 자동으로 생성하고, 프로토타입 실행 중에 타이밍 제약사항을 모니터링하며, 매개 변수화 된 하드웨어 모델 세트에 비례하여 실시간으로 실행을 시뮬레이션한다. 또한, 불완전한 프로토타입 설명의 실행을 가능하게 하는 기본 가정을 제공하고, 효율적인 구현을 신속하게 실현하기 위해 프로토타입 구성을 소프트웨어 재사용 저장소와 통합하며, 요구 사항 및 설계의 신속한 진화를 지원한다. <ref>Luqi (Naval Postgraduate School), 〈[https://zenodo.org/record/1232144#.X1ckd3kzaUk Software evolution through rapid prototyping]〉, 《zenodo》, 1989-05-01</ref> | ||
| + | |||
| + | {{각주}} | ||
| − | == | + | == 참고 자료 == |
| − | * | + | * Software prototyping WIKIPEDIA - https://en.wikipedia.org/wiki/Software_prototyping#Outline_of_the_prototyping_process |
| − | * | + | * 프로토타입 위키백과 - https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9C%ED%86%A0%ED%83%80%EC%9E%85 |
| + | * Paper prototyping WIKIPEDIA - https://en.wikipedia.org/wiki/Paper_prototyping | ||
| + | * Graphical user interface builder WIKIPEDIA - https://en.wikipedia.org/wiki/Graphical_user_interface_builder | ||
| + | * 일괄 처리 위키백과 - https://ko.wikipedia.org/wiki/%EC%9D%BC%EA%B4%84_%EC%B2%98%EB%A6%AC | ||
| + | * Timeboxing WIKIPEDIA - https://en.wikipedia.org/wiki/Timeboxing Timeboxing | ||
| + | * Bootstrap (front-end framework) WIKIPEDIA - https://en.wikipedia.org/wiki/Bootstrap_(front-end_framework) | ||
| + | * Foundation (framework) WIKIPEDIA - https://en.wikipedia.org/wiki/Foundation_(framework) | ||
| + | * AngularJS WIKIPEDIA - https://en.wikipedia.org/wiki/AngularJS | ||
| + | * Luqi (Naval Postgraduate School), 〈[https://zenodo.org/record/1232144#.X1ckd3kzaUk Software evolution through rapid prototyping]〉, 《zenodo》, 1989-05-01 | ||
| + | * 프로토타입 나무위키- https://namu.wiki/w/%ED%94%84%EB%A1%9C%ED%86%A0%ED%83%80%EC%9E%85 | ||
== 같이 보기 == | == 같이 보기 == | ||
| 29번째 줄: | 133번째 줄: | ||
* [[소프트웨어 개발 방법론]](SDM) | * [[소프트웨어 개발 방법론]](SDM) | ||
| − | + | {{프로그래밍|검토 필요}} | |
2020년 9월 11일 (금) 19:00 기준 최신판
프로토타입(prototype)은 '원형' 또는 '기본형'이라는 뜻으로, 다수의 사이트나 시스템을 개발하는 데 필요한 기본 형태이다. 정보시스템의 미완성 버전 및 중요한 기능들이 포함된 시스템의 초기 모델이다. 또한, 일반적으로 양산형으로 제작되기 전에 미리 제작해보는 초기 모델로, 사용자의 모든 요구사항이 정확하게 반영할 때까지 계속해서 개선 및 보완된다. 실제로 많은 애플리케이션들이 지속적인 프로토타입의 확장과 보강을 통해 최종 설계가 승인된다. 복제하는 방식으로 사이트를 대량 제작을 할 수 있으며, 개발 방법론은 소프트웨어 개발 방법론(SDM)의 일종이다. 시제품(試製品), 견본품, 초기형, 시작형이라고도 불린다.
목차
개요[편집]
프로토타입은 소프트웨어 사용자가 설명을 기반으로 디자인을 해석하고 평가할 필요 없이 최종 제품의 디자인에 대한 개발자의 제안을 실제로 시도하여 평가하는 것을 목표로 하고 있다. 소프트웨어 프로토타입은 소프트웨어의 기능과 잠재적인 위협과 문제에 대한 이해를 제공한다. 프로토타입은 최종 사용자가 고려하지 않은 요구 사항을 설명하고 증명하는 데 사용할 수 있으며, 개발자와 클라이언트 간의 상업적 관계에서 핵심 요소가 될 수 있다. 특히, 인터랙션 설계는 이러한 목표를 가지고 프로토타이핑을 많이 사용한다.[1]
특징[편집]
장점[편집]
프로토타입은 오류를 초기에 발견할 수 있고, 수정과 보완이 용이하여 개발 시간과 비용을 줄일 수 있다. 또한, 프로토타이핑은 개발자에게 제공되는 요구사항 및 사양의 품질을 향상시킬 수 있다. 변경 사항은 나중에 개발 단계에서 발견될 때 구현하는 데 더 큰 비용이 들기 때문에 사용자가 진정으로 원하는 것을 조기에 결정하면 소프트웨어가 더 빠르고 저렴해질 수 있다. 프로토타이핑은 사용자 중심의 개발 방법으로 사용자의 요구 만족을 극대화할 수 있어 프로토타입 제작은 사용자 참여가 필요하며, 더 우수하고 완벽한 피드백과 사양을 제공할 수 있도록 프로토타입과 상호작용을 가능하게 한다. 사용자가 검토 중인 프로토타입의 존재는 서로가 상대방이 말한 것을 이해한다고 믿을 때 발생하는 많은 오해와 의사소통의 오류를 방지한다. 사용자는 개발팀의 누구보다 문제 영역을 더 잘 알고 있으므로 사용작용을 증가시키면 유형 및 무형의 품질이 더 우수한 최종 제품이 될 수 있다. 최종 제품은 모양, 느낌 및 성능에 대한 사용자의 욕구를 충족시킬 가능성이 크다.[1][2]
단점[편집]
프로토타입은 시스템 유지관리에 필수적인 시스템의 문서화 과정이 지나치게 축소되거나 생략될 수 있다는 단점이 있다. 프로토타이핑으로, 완성된 시스템은 컴퓨터 자원의 활용 측면에서 볼 때 효율적이지 못하지만, 컴퓨터 관련 기기들의 성능은 좋아졌으며, 가격은 하락하면서 이 문제의 비중은 많이 감소하고 있다. 제한된 프로토타입에 초점을 맞추면, 개발자가 전체 프로젝트를 제대로 분석하지 못할 수도 있다. 이로 인해 더욱 나은 솔루션을 간과하고, 불완전한 사양을 준비하며, 제한된 프로토타입을 유지 관리하기 어려운 잘못 설계된 최종 프로젝트로 변경될 수도 있다. 또한, 프로토타입은 기능이 제한되어 있으므로 프로토타입이 최종 결과물의 기반으로 사용되는 경우 제대로 확장되지 않을 수도 있으며, 개발자가 프로토타입을 모델로 구축하는 데 너무 집중하면 눈에 띄지 않을 수 있다. 프로토타입과 완성된 시스템의 사용자 혼돈으로, 사용자는 버려질 목적으로 만들어진 프로토타입이 실제로 완성되거나 다듬기만 하면 되는 최종시스템이라고 생각할 수 있다. 예를 들어, 사용자는 프로토타입에 없을 수 있는 오류 검사나 보안 기능을 추가하는 데 필요한 노력을 인식하지 못한다. 이로 인해 개발자의 의도가 아닌 경우 프로토타입이 최종 시스템의 성능을 프로토타입이 정확하게 모델링 할 것으로 예상할 수 있다. 또한, 사용자는 검토를 위해 프로토타입에 포함된 기능에 연결한 다음 최종 시스템의 사양에서 제거할 수 있다. 사용자가 제안된 모든 기능을 최종 시스템에 포함하도록 요구할 수 있는 경우 충돌이 발생할 수도 있다.
개발자는 광범위한 상업적 문제를 이해하지 않고 사용자가 자신의 목표를 공유한다고 가정할 수 있다. 예를 들어, 엔터프라이즈 소프트웨어 이벤트에 참석하는 사용자 대표는 이 기능에 추가 코딩을 요구하며, 종종 추가 데이터베이스 액세스를 처리하기 위해 더 많은 하드웨어를 요구한다는 말을 듣지 않아 트랜잭션 감사(transaction advising)의 데모를 보았을 수도 있다. 사용자들은 모든 분야에서 감사를 요구할 수 있다고 믿지만, 개발자들은 사용자의 요구사항의 정도에 대해 가정했기 때문에 이것이 기능상 이상하다고 생각할 수 있다. 사용자 요구사항을 검토하기 전에 개발자가 전달을 약속했다면, 특히 사용자 관리가 요구사항을 이행하지 않음으로써 어느 정도 이점을 얻는 경우에 개발자는 난처한 상황에 있게 된다. 개발자는 제작에 많은 노력을 기울인 프로토타입에 애착을 둘 수 있다. 이것은 제한된 프로토타입을 적절한 기본 아키텍처를 가지고 있지 않을 때 최종 시스템으로 변환하려고 시도하는 것과 같은 문제를 발생시킬 수 있다.
프로토타이핑의 핵심 속성은 신속하게 수행되어야 한다. 만약, 개발자가 이를 잊어버리면 너무 복잡한 프로토타입을 개발하려고 할 수 있다. 프로토타입을 폐기할 때, 시제품이 제공하는 정밀하게 개발된 요구사항으로 인해 시제품 개발에 소용되는 시간을 보충할 만큼 충분한 생산성 향상이 이루어지지 않을 수 있다. 사용자는 프로토타입의 세부 사항에 대한 논쟁에 갇혀 개발팀을 잡고 최종 제품을 지연시킬 수 있다. 프로토타입의 구현 비용으로, 프로토타이핑에 중점을 둔 개발팀을 구성하기 위한 시작 비용이 높을 수 있다. 많은 기업이 개발 방법론을 시행하고 있으며, 이를 변경하는 것은 재교육, 재설계 또는 둘 다를 의미할 수 있다. 많은 회사가 작업자를 재교육하지 않고 프로토타이핑을 시작하는 경향이 있다. 프로토타이핑 기술을 채택할 때 공통으로 발생하는 문제는 학습 곡선 뒤에 충분한 노력을 기울이지 않고 생산성에 대한 높은 기대이다. 프로토타이핑 기법의 사용을 위한 교육 외에도, 기술을 지원하기 위한 기업 및 프로젝트별 기초 구조를 개발해야 할 필요성이 종종 간과되고 있으며, 이러한 기본 구조를 생략하면 생산성이 저하되는 경우가 많다.[1]
프로토타이핑[편집]
소프트웨어 프로토타입에는 다양한 변형이 있으며, 포로토타이핑(prototyping) 에서 사용된다. 모든 방법은 어떤 식으로든 일회용 프로토타이핑과 진화형 프로토타이핑이라는 두 가지 주요한 형태의 프로토타입에 기반을 둔다. 또한, 프로토 타이핑의 과정은 다음과 같은 4단계로 구분된다.
1단계 : 사용자의 요구사항을 분석하며 시스템 설계자는 기본적인 요구사항이 도출되기까지 사용자와 함께 작업한다. 2단계 : 1단계에서 도출된 요구사항을 만족하게 하는 프로토타입을 개발하여 앞으로 개발될 시스템의 가장 핵심적인 기능 위주로 개발한다. 3단계 : 사용자가 개발된 프로토타입을 검토 및 사용을 통해 요구사항이 이행되고 있는지 확인하고, 보완을 위해 피드백을 제안한다. 4단계 : 수정과 보완이 이루어지며 수정된 후에는 3단계로 돌아가 사용자가 만족할 때까지 3단계와 4단계를 반복한다.[2]
또한, 사용자 인터페이스(UI) 프로타입의 일반적인 용어는 수평 프로토타입이다. 데이터베이스 액세스와 같은 저수준 시스템 기능보다 사용자 상호 작용에 초점을 맞추어 전체 시스템 또는 서브 시스템에 대한 넓은 시야를 제공한다. 수평 프로토타이핑은 다음의 목록에 유용하며, 사용자 인터페이스 요구 사항 및 시스템 범위를 확인하고, 비즈니스로부터 인수를 얻기 위한 시스템의 데모 버전 등 개발 시간과 비용 및 노력에 대한 예비 추정치를 개발한다. 수직 프로토타이핑은 단일 서브 시스템 또는 기능의 환전한 정교함을 강화한 것이다. 특정 기능에 대한 상세 요구사항을 얻는 데 유용하며, 데이터베이스 설계 개선과 네트워크 크기 조정 및 성능 엔지니어링을 위한 데이터 볼륨 및 시스템 인터페이스 요구에 대한 정보 얻기 및 실제 시스템 기능까지 드릴 다운하여 복잡한 요구사항을 명확히 한다는 장점이 있다.[1]
일회용 프로토타이핑[편집]
일회용 프로토타이핑은 폐쇄형 프로토타이핑(close-ended prototyping)이라고도 불린다. 폐기(Throwaway) 또는 신속한 프로토타이핑(Rapid Prototyping)은 최종 제공 소프트웨어의 일부가 되지 않고 결국 폐기될 모델을 만드는 것을 의미한다. 사전 요구사항 수집이 완료된 후 시스템의 간단한 작업 모델을 구축하여 사용자에게 요구사항이 완성된 시스템으로 구현될 때 어떤 모습일지 시각적으로 보여준다. 이것을 신속한 프로토타이핑이라고도 한다. 일회용 프로토타이핑을 사용하는 가장 분명한 이유는 매우 초기 단계에서 신속하게 수행할 수 있기 때문이다. 사용자들이 요구사항에 대한 빠른 피드백을 받을 수 있다면 소프트웨어 개발 초기에 이를 개선할 수 있다. 개발 생명주기 초기에 변경하는 것은 그 시점에서 다시 실행할 것이 없으므로 매우 비용 효율적이다. 상당한 양의 작업을 수행한 후에 프로젝트가 변경되면 소프트웨어 시스템에 많은 종속성을 가지기 때문에 작은 변경을 구현하는 것만으로도 많은 노력이 필요할 수 있다. 시간과 비용의 한정된 예산으로 인해 폐기될 프로토타입에 비용을 많이 지출할 수 없으므로 일회용 프로토타입을 구현하는 데는 속도가 매우 중요하다.
프로토타입은 외관, 상호작용 및 타이밍 측면에서 실제 제품과 유사한 충실도에 따라 분류할 수 있다. 충실도가 낮은 일회용 프로토타입을 만드는 한 가지 방법은 종이 프로토타입(paper prototyping)이다. 프로토타입은 종이와 연필을 사용하여 구현해 실제 제품의 기능을 모방한 것이지만 전혀 다르다. 고밀도 일회용 프로토타입을 쉽게 제작할 수 있는 또 다른 제작 방법은 그래픽 사용자 인터페이스(GUI) 빌더(Builder)를 사용하여 클릭 더미(click dummy)를 만드는 것이다. 클릭 더미는 목표 시스템과 유사하지만 어떤 기능도 제공하지 않는 프로토타입이다. 스토리보드, 애니매틱스, 드로잉의 사용은 일회용 프로토타이핑과 동일하지는 않지만 같은 계열에 속하며, 이것들은 비기능적인 구현이지만 시스템이 어떻게 보일지 보여준다. 일회용 프로토타입에서는 프로토타입은 폐기되고 최종 시스템은 구축될 것이라는 생각으로 제작되는 이 접근법은 예비 요구사항 작성, 프로토타입 디자인, 사용자 경험(UX) 및 프로토타입 사용과 새로운 요구사항을 지정한다. 또한, 필요한 경우 반복되어 최종 요구사항을 작성해야 한다.[1]
신속한 프로토타이핑[편집]
신속한 프로토타이핑(Rapid Prototyping)은 비교적 짧은 조사 후 매우 초기 단계에서 시스템의 다양한 부분의 작업 모델을 만드는 것을 포함한다. 구축에 사용되는 방법은 일반적으로 매우 비공식적이며, 가장 중요한 요소는 모델이 제공되는 속도이다. 그 후 모델은 사용자가 자신의 기대치를 재점검하고 요구사항을 명확히 할 수 있는 출발점이 된다. 이 목표가 달성되면, 프로토타입 모델은 'thrown away'(버려지기) 되고, 확인된 요구사항을 기반으로 시스템이 공식적으로 개발된다.[1]
종이 프로토타이핑[편집]
인간과 컴퓨터의 상호작용에서 종이 프로토타이핑(paper prototyping)은 사용자 중심 설계 프로세스에서 널리 사용되는 방법이며, 특히 사용자 인터페이스를 설계하고 테스트하기 위해 개발자가 사용자의 기대와 요구에 부합하는 소프트웨어를 만들 수 있도록 돕는 프로세스다. 그것은 버려지는 프로토타이핑이며 손으로 제작한 시제품이나 모델의 모델로 사용할 인터페이스 도면을 만드는 것을 포함한다. 종이 프로토타이핑은 간단해 보이지만, 사용 적합성 시험 방법은 사용하기 쉬운 제품의 설계에 도움이 되는 유용한 피드백을 제공할 수 있다. 이것은 많은 사용 적합성 전문가들이 지원한다.[3]
그래픽 사용자 인터페이스 빌더[편집]
그래픽 사용자 빌더(GUI Builder)는 디자이너라고도 알려진 그래픽 사용자 인터페이스 빌더는 위지위그(WYSIWYG) 편집기를 사용하여 설계자가 그래픽 제어 요소를 정렬할 수 있도록 하여 그래픽 사용자 인터페이스 생성을 단순화하는 소프트웨어 개발 도구이다. 빌더가 없는 그래픽 사용자 인터페이스는 프로그램이 실행될 때까지 시각적 피드백 없이 소스 코드에 각 위젯의 파라미터를 수동으로 지정하여 그래픽 사용자 인터페이스를 구축해야 한다. 사용자 인터페이스는 일반적으로 이벤트 중심 아키텍처를 사용하여 프로그래밍이 되므로, 그래픽 사용자 인터페이스 구축자는 이벤트 중심 코드 생성도 단순화한다. 이 지원 코드는 위젯을 애플리케이션 로직을 제공하는 기능을 트리거하는 송신 및 수신 이벤트와 연결한다. 글레이드 인터페이스 디자이너(Glade Interface Designer)와 같은 일부 그래픽 사용자 인터페이스 빌더는 그래픽 제어 요소에 대한 모든 소스 코드를 자동으로 생성한다. 인터페이스 빌더와 같은 다른 것들은 애플리케이션에 의해 로드되는 직렬화된 개체 인스턴스를 생성한다.[4]
진화형 프로토타이핑[편집]
진화형 프로토타이핑(Evolutionary prototyping)은 일회용 프로토타이핑과는 상당히 다르다. 진화형 프로토타이핑을 사용할 때의 주요 목표는 구조화된 방식으로 매우 견고한 프로토타입을 제작하여 지속해서 개선하는 것이다. 이러한 접근방식의 이유는 진화형 프로토타입이 구축되면 새로운 시스템의 핵심이 되고, 개선사항과 추가 요구사항이 구축되기 때문이다. 진화형 프로토타이핑을 사용하여 시스템을 개발할 때 시스템은 지속해서 개선되고 재구축된다. 진화형 프로토타입은 기능적 시스템이라는 점에서 일회용 프로토타입보다 장점이 있다. 사용자가 계획한 모든 기능이 제공되지는 않지만, 최종 시스템이 제공될 때까지 임시로 사용할 수 있다. 진화형 프로토타이핑에서 개발자는 전체 시스템을 개발하는 대신 이해하는 시스템 일부를 개발하는 데 집중할 수 있다.[1]
증분 프로토타이핑[편집]
최종 제품은 별도의 프로토타입(Incremental prototyping)으로 제작된다. 결국, 개별 프로토타입은 전체 설계에 통합된다. 증분 프로토타이핑을 통해 사용자와 소프트웨어 개발자 간의 시간 간격이 줄어든다.[1]
익스트림 프로토타이핑[편집]
개발 과정으로서의 익스트림 프로토타이핑(Extreme prototyping)은 특히 웹 애플리케이션 개발에 사용된다. 기본적으로 웹 개발은 앞의 단계를 기준으로 3단계로 세분화한다. 1단계는 주로 HTML 페이지로 구성된 정적 프로토타입이다. 2단계는 시뮬레이션 된 서비스 계층을 사용하여 프로그래밍이 되고 완전한 기능을 한다. 3단계는 서비스가 구현된다. 이 프로세스를 익스트림 프로토타이핑이라고 하며 두 번째 단계에 주의를 기울여야 한다. 이 프로세스는 계약 이외의 서비스에 대해서는 거의 관계없이 완전한 기능의 사용자 인터페이스가 개발된다.[1]
활용[편집]
프로젝트[편집]
프로토타입은 어떤 형태로든 항상 사용해야 한다. 그러나, 프로토타이핑은 사용자와 많은 상호 작용이 있는 시스템에서 가장 유용하다. 프로토타이핑은 온라인 시스템의 분석 및 설계, 특히 화면 대화 상자의 사용이 더 많은 증거가 있는 트랜잭션 처리에 매우 효과적이라는 사실이 밝혀졌다. 컴퓨터와 사용자 간의 상호 작용이 클수록 빠른 시스템을 구축하고 사용자가 함께 플레이할 수 있는 이점이 더 커진다. 일괄 처리(batch processing)나 대부분 계산을 수행하는 시스템과 같이 사용자 상호작용이 거의 없는 시스템은 프로토타이핑 이점의 의미가 없다. 때때로 시스템의 기능을 수행하는 데 필요한 코딩이 너무 집약적일 수 있고 프로토타이핑이 제공할 수 있는 잠재적 이득이 너무 작을 수 있다. 프로토타이핑은 사람과 컴퓨터의 인터페이스(human-computer interfaces)를 설계하는 데 특히 유용하다.
- 배치 프로세싱
배치 프로세싱(batch processing)은 컴퓨터 프로그램 흐름에 따라 순차적으로 자료를 처리하는 방식을 뜻한다. 초기의 일괄처리 방식은 사용자와 상호작용하는 것이 불가능했지만, 운영 체제가 발전함에 따라 프로그램 입출력을 통해 상호작용하는 것이 가능해졌다. 일괄 처리는 1950년대 전자 컴퓨팅 초기 시절 이후 메인프레임 컴퓨터와 함께하고 있다. 일괄 처리 시스템은 일정 기간마다 주기적으로 한꺼번에 처리할 필요가 있고, 그룹별로 분류시킬 수 있는 성질을 가지고 있으며, 순차 접근방법을 사용할 수 있는 업무. 즉, 처리 요건이 일괄적인 업무에 대해 유사한 자료를 한데 모아 일정한 형식으로 분류한 뒤 한번에 일괄 처리함으로써 시간과 비용을 절감하여 업무의 효율성을 향상시킨다. 데이터 처리의 경우, 급여명세서나 봉급계산, 전화요금, 전기요금, 수도세, 성적처리 등이 일반적으로 이용되는 곳이다.[5]
동적 시스템 개발 방법[편집]
동적 시스템 개발 방법(DSDM, Dynamic System Development Method)은 핵심 기법으로 프로토타이핑에 크게 의존하는 비즈니스 솔루션을 제공하기 위한 프레임워크로, 자체적으로 ISO 9001이 승인되었다. 그것은 프로토타입의 가장 잘 이해되는 정의로 확장한다. 동적 시스템 개발 방법에 따르면 프로토타입은 다이어그램, 비즈니스 프로세스 또는 생산에 투입된 시스템일 수 있다. 동적 시스템 개발 방법 프로토타입은 단순한 형태에서보다 포괄적인 형태로 진화하는 점진적 형태로 만들어졌으며, 동적 시스템 개발 방법 프로토타입은 폐기되거나 진화될 수 있다. 진화형 프로토타입은 수평 및 수직으로 진화할 수 있다. 프로토타입 범주의 동적 시스템 개발 방법에서는 자동화되는 비즈니스 프로세스를 설계하고 시연하는 데 사용되는 비즈니스 프로토타입, 사용자 인터페이스 설계의 사용성, 접근성, 모양 및 느낌을 정의, 개선 및 시연하는 데 사용되는 사용성 프로토타입을 권장한다. 또한, 시스템의 최대 부하 시스템 성능을 정의와 시연 및 예측하고 시스템의 기타 비기능적 측면을 시연 및 평가하는 데 사용하는 성능 및 용량 프로토타입, 설계 접근 방식 및 개념을 개발과 시연 및 평가하는 데 사용되는 기능 및 기술의 프로토타입을 권장한다. 프로토타입의 동적 시스템 개발 방법 수명주기는 다음과 같다.[1]
- 프로토타입 식별
- 계획에 동의
- 프로토타입 만들기
- 프로토타입 검토
운영 프로토타이핑[편집]
운영 프로토타이핑(Operational prototyping)은 일회용 및 진화형 프로토타이핑을 기존의 시스템 개발과 통합하는 방법으로, 앨런 데이비스(Alan Davis)에 의해 제안되었다. 앨런 데이비스의 신념은 "급속한 프로토타입에 품질을 재적합"하려고 하는 것이 두 접근법을 결합하려고 할 때 올바른 방법이 아니라는 것이다. 그의 아이디어는 진화형 프로토타이핑 방법론에 참여하여 각각의 진화 후에 시스템의 특징을 신속하게 프로토타입 화하는 것이다. 구체적인 방법론 단계 방법의 핵심은 잘 훈련된 프로토타입 제작자가 사용자 사이트에 접속할 수 있도록 하는 것이다. 운영 프로토타이핑 방법론은 복잡하고 사전에 알려진 요구사항이 거의 없는 시스템에서 많은 이점을 가지며, 구체적인 방법론 단계는 다음과 같다.[1]
- 진화형 프로토타입은 기존의 개발 전략을 사용하여 구성되고 기준으로 만들어지며 잘 이해되는 요구사항만 지정하고 구현한다.
- 베이스라인 사본은 훈련된 프로토타입과 함께 여러 고객 사이트로 전송된다.
- 각 사이트에서 프로토타입 제작자는 시스템의 사용자를 감시한다.
- 사용자가 문제를 발견하거나 새로운 기능이나 요구 사항을 생각할 때마다 프로토타입이 이를 기록한다. 이를 통해 사용자는 문제를 기록하지 않아도 되고 작업을 계속할 수 있다.
- 사용자 세션이 끝나면 프로토타입은 기본 시스템 위에 일회용 프로토타입을 구성한다.
- 사용자는 이제 새로운 시스템을 사용하고 평가한다. 새로운 변경 사항이 적용되지 않거나 효과적이지 않다면 프로토타입 제작자는 이를 제거한다.
- 사용자가 변경 사항을 좋아하며 프로토타입 제작자는 기능향상 요청을 작성하여 개발팀에 전달한다.
- 개발팀은 모든 사이트에서 변경 요청을 받은 다음 기존 방법을 사용하여 새로운 진화형 프로토타입을 생성한다.
진화 시스템 개발[편집]
진화 시스템 개발(Evolutional Systems Development)은 진화 프로토타이핑을 공식적으로 구현하려는 방법론의 한 종류다. 시스템 크래프트(Systemscraft)라고 불리는 특정 유형은 존 크리니온(John Crinnion)의 저서 '진화 시스템 개발(Evolutionary Systems Development)'에서 설명한다. 시스템 크래프트는 구현된 특정 환경에 맞게 수정하고 조정되어야 하는 프로토타입 방법론으로 설계되었다. 진화형 프로토타이핑과 달리 초기 요구사항부터 작업 시스템을 만들어 일련의 개정으로 구축하는 것이다. 또한, 시스템 개발 전반에 걸쳐 사용되고 있는 전통적인 분석에 큰 중점을 두고 있다.[1]
진화적 급속한 발전[편집]
진화적 급속한 발전(Evolutionary Rapid Development, ERD)은 국방고등연구사업청(DARPA) 정보기술사무소의 기술 개발 및 통합대리인인 소프트웨어 생산성 컨소시엄에 의해 개발되었다. ERD의 기본은 구성요소의 재사용, 소프트웨어 템플릿의 사용 및 아키텍처 템플릿에 기반을 둔 소프트웨어 시스템을 구성하는 개념이다. 변화하는 사용자 요구와 기술에 신속하게 대응하는 시스템 기능의 지속인 진화는 솔루션 클래스를 대표하는 진화가 가능한 아키텍처에 의해 강조된다. 이 프로세스는 소프트웨어 및 시스템 엔지니어링 분야를 통합하여 소규모 기술자 기반팀의 사용에 중점을 둔다. ERD 기반 프로젝트 성공의 핵심은 기술, 시장 또는 고객 요구사항의 변화에 신속하게 대응할 수 있는 첨단 기술과 기능, 인프라 및 구성 요소의 병렬 탐색 분석 밑 개발과 채택이다. 사용자의 의견을 이끌어내기 위해, 이해 관계자와 자주 예정된 임시 및 즉시 회의를 개최한다. 설계 및 구현 결정이 확정되기 전에 피드백을 요청하기 위해 시스템 기능 시연을 한다. 시스템이 사용자나 고객 요구를 더 잘 지원할 방법에 대한 통찰력을 제공하기 위해 빈번한 릴리스를 사용할 수 있도록 제공된다. 이를 통해 시스템이 기존의 사용자 요구를 충족시키기 위해 발전할 수 있다.
시스템에 대한 설계 프레임워크는 기존의 발표된 표준 또는 사실상의 표준을 사용하는 것에 기반을 둔다. 시스템은 성능, 용량 및 기능에 대한 고려 사항을 포함하는 일련의 기능을 발전시킬 수 있도록 구성되어 있다. 아키텍처는 서비스 및 해당 구현을 캡슐화하는 추상 인터페이스 측면에서 정의된다. 아키텍처는 하나 이상의 시스템 인스턴스 개발을 안내하는 데 사용되는 템플릿 역할을 한다. 서비스를 구현하기 위해 여러 응용프로그램 구성요소를 사용할 수 있도록 한다. 변경 가능성이 없는 핵심 기능 집합도 식별 및 설정된다. ERD 프로세스는 이해관계자가 자신의 요구와 기대를 전달하는 방법으로 종이제품보다는 입증된 기능을 사용하도록 구성된다. 이러한 빠른 전송 목표의 핵심은 타임박스(timebox) 방법의 사용이다. 타임박스는 특정 작업(예:기능성의 집합 개발)이 수행되어야 하는 고정된 기간이다. 어떤 막연한 목표를 충족시키기 위해 시간을 확장하는 것을 허용하기보다는, 시간은 고정되어 있고(달력 주와 사람 시간의 측면에서 모두) 이러한 제약 내에서 현실적으로 달성할 수 있는 일련의 목표를 정한다. 개발이 랜덤워크(random walk)로 전락하는 것을 방지하기 위해 장기 계획을 정의해 반복을 유도한다. 이 계획들은 전체 시스템에 대한 비전을 제공하고 프로젝트에 대한 경계(예:제약조건)를 설정한다. 프로세스 내의 각 반복은 이러한 장기 계획의 맥락에서 수행된다.
아키텍처가 구축되면 소프트웨어가 통합되고 매일 테스트 된다. 이를 토대로 팀은 진행 상황을 객관적으로 평가하고 잠재적인 문제를 신속하게 파악할 수 있다. 소량의 시스템이 한 번에 통합되기 때문에 결함을 진단하고 제거하는 속도가 빠르다. 일반적으로 시스템이 항상 활동할 준비가 되어 있으므로 사용자 데모는 단기간에 개최할 수 있다.[1]
- 타임박스
타임박스(timebox)는 계획된 활동이 이루어지는 시간 박스라고 불리는 일정한 기간을 할당한다. 여러 프로젝트 관리 접근법과 개인 시간 관리를 위해 사용된다. 프로젝트 관리에서는 프로젝트 계획 기법으로 사용되면 일정은 여러 개의 별도 기간으로 나뉘며, 각 파트에는 자체 산출물, 마감일, 예산이 있다. 타임박스 없이 프로젝트는 대개 일정한 범위까지 작동하는데, 이 경우 계획된 시간 범위 내에서 일부 결과물을 완료할 수 없다는 것이 명확해지면 마감일을 연장하거나 더 많은 사람이 참여해야 하며 종종 두 가지 모두 발생한다. 이때 프로젝트의 일정이 지연되고 비용이 증가하며, 품질이 저하될 수 있다. 프로젝트에서 타임박스는 마감일이 정해져 있어 범위를 줄여야 한다는 의미이다. 이는 조직이 가장 중요한 산출물을 먼저 완성하는 데 집중해야 함을 의미하기 때문에, 타임박스는 산출물의 우선순위를 정하는 계획과 연계된다. 타임박스는 리스크 관리를 위해 사용되는데, 불확실한 업무/시간 관계, 즉 마감일을 쉽게 넘길 수 있는 작업을 명시적으로 식별하기 위해 리스크 관리의 한 형태로 사용된다. [6]
도구[편집]
프로토타이핑을 효율적으로 사용하려면 조직에 적절한 도구와 이러한 도구를 사용하도록 교육을 받은 직원이 있어야 한다. 프로토타이핑에 사용되는 도구는 신속한 시제품 제작에 사용되는 4세대 프로그래밍 언어와 같은 개별 도구에서 복잡한 통합케이스 도구까지 다양할 수 있다. 비주얼 베이직이나 콜드퓨전 같은 4세대 비주얼 프로그래밍 언어는 가격이 저렴하고 잘 알려졌으며, 비교적 사용하기 쉽고 빠르게 사용할 수 있어 자주 사용된다. 요구사항 엔지니어링 환경과 요구사항 분석을 지원하는 케이스(CASE) 도구는 군대 또는 대규모 조직에 의해 개발되거나 선택된다. GE 연구개발센터의 LYMB와 같은 객체지향 도구도 개발되고 있다. 사용자는 스프레드시트에서 응용프로그램의 구성요소를 직접 프로토타입으로 작성할 수 있다. 웹 기반 응용프로그램의 인기가 계속 증가함에 따라 이러한 응용프로그램의 프로토타이핑을 위한 도구도 갖추게 된다. 부트스트랩(Bootstrap), 파운데이션(Foundation (framework)) 및 AngularJS와 같은 프레임워크는 개념 증명을 신속하게 구성하는 데 필요한 도구를 제공한다. 이러한 프레임워크는 일반적으로 개발자가 웹 애플리케이션을 신속하게 프로토타이핑할 수 있도록 하는 일련의 제어, 상호작용 및 설계 지침으로 구성된다.[1]
- 부트스트랩(Bootstrap (front-end framework)) : 부트스트랩은 모바일 최초의 반응형 프론트 엔드 웹 개발을 위한 무료 오픈 소스 CSS 프레임워크다. 부트스트랩은 웹 앱과 반대로 유익한 웹 페이지 개발을 단순화하는 데 초점을 맞춘 웹 프레임워크다. 웹 프로젝트에 부트스트랩을 추가하는 주된 목적은 색상, 크기, 글꼴 및 레이아웃에 대한 Bootstrap의 선택을 해당 프로젝트에 적용하는 것이다. 부트스트랩은 개발자들이 원하는 대로 요소들에 대한 선택이 주된 요인이다. 프로젝트에 추가되면 Bootstrap은 모든 HTML 요소에 대한 기본 스타일 정의를 제공한다. 그 결과는 웹 브라우저를 가로지르는 산문, 테이블, 양식 요소들의 균일한 출현이다. 또한, 부트스트랩에는 jQuery 플러그인의 형태로 여러 자바스크립트 구성요소가 함께 제공된다. Bootstrap의 가장 눈에 띄는 구성 요소는 전체 웹 페이지에 영향을 미치는 레이아웃 구성 요소다. 페이지의 다른 모든 요소가 배치되므로 기본 레이아웃 구성 요소를 "컨테이너"라고 하는데, 개발자는 고정 너비 컨테이너와 유동 너비 컨테이너 중에서 선택할 수 있습니다.[7]
- 파운데이션(Froundation framework) : 파운데이션은 응답성이 뛰어난 프론트 엔트 프레임워크다. 파운데이션은 자바스크립트(JavaScript) 확장이 제공하는 선택적 기능뿐만 아니라 타이포그래피, 양식, 버튼, 내비게이션 및 기타 인터페이스를 포함한 반응형 그리드, HTML 및 CSS UI 구성요소, 템플릿 및 코드 스니펫을 제공한다. 파운데이션은 오픈소스 프로젝트로 ZRUB에서 관리하다가 2019년부터 자원봉사자들에 의해 유지되고 있다. Foundation은 수많은 브라우저와 장치를 위해 설계되고 테스트 되었다. 빠른 개발을 위한 모범 사례를 디자이너에게 제공하는 Sass / SCSS로 구축 된 모바일 최초의 반응 형 프레임 워크다. 프레임 워크에는 반응 형 사이트를 빠르게 프로토 타이핑하는 데 필요한 가장 일반적인 패턴이 포함되어 있다. Sass 믹스 인을 사용하여 Foundation 구성 요소는 쉽게 스타일을 지정하고 확장 할 수 있다.[8]
- AngularJS : AngulJS는 JavaScript 기반의 오픈소스 프런트 엔드 웹 프레임워크로, 주로 구글과 개인 및 기업 공동체가 단일 페이지 애플리케이션 개발 시 직면하는 많은 난제를 해결하기 위해 유지한다. 풍부한 인터넷 애플리케이션에서 일반적으로 사용되는 구성요소와 함께 클라이언트 측 모델-뷰-컨트롤러(MVC) 및 모델-뷰-뷰 모델(MVVM) 아키텍처에 대한 프레임워크를 제공하여 그러한 애플리케이션의 개발과 시험을 모두 단순화하는 것을 목표로 한다. MongoDB 데이터베이스, Express.js 웹 애플리케이션 서버 프레임워크, Angul.js 자체, Node.js 서버 런타임 환경으로 구성된 MEAND 스택의 프런트 엔드로 AngulJS가 사용된다.[9]
화면 생성기, 설계 도구 및 소프트웨어 공장[편집]
1985년부터 로마 연구소에서 개발 중인 요구사항 엔지니어링 환경(REE)은 복잡한 시스템의 중요한 측면 모델을 신속하게 표현, 구축 및 실행할 수 있는 통합 도구 세트를 제공한다. 시스템 분석가가 시스템 구성요소의 기능, 사용자 인터페이스 및 성능 프로토타입 모델을 신속하게 구축할 수 있는 통합 도구 세트이다. 이러한 모델링 활동은 복잡한 시스템에 대한 이해를 높이고 부정확한 요구사항의 사양이 시스템 개발 프로세스 동안 비용과 일정에 미치는 영향을 줄이기 위해 수행된다. 모델은 행사되는 모델의 특정한 행동 양상에 따라 다양한 수준의 추상화 또는 세분화로 쉽게 구성될 수 있다. RIE는 세 부분으로 구성되어 있다. 첫 번째 프로토타입은 신속한 시제품을 지원하도록 특별히 설계된 CASE 도구다. 두 번째 부분은 RAP(Rapid Interface Protesting System) 또는 RIP(Rapid Interface Protesting System)로 불리며, 사용자 인터페이스의 생성을 용이하게 하는 도구 모음이다. RIE의 세 번째 부분은 RIP와 프로토타입에 대한 사용자 인터페이스로 그래픽화되어 사용이 용이하도록 고안되었다.
RIE의 개발자인 로마 연구소는 그들의 내부 요구사항 수집 방법론을 지원하기 위해 의도했다. 방법은 크게 세 부분으로 나뉜다.
- 다양한 소스(사용자, 다른 시스템에 대한 인터페이스), 사양 및 일관성 검사에서 추출
- 다양한 사용자의 요구가 서로 상충하지 않고 기술적으로 경제적으로 실현 가능한 분석
- 파생된 요구 사항이 사용자 요구를 정확하게 반영하는지 검증[15]
1996년 Roma Labs는 소프트웨어 생산성 솔루션(SPS)과 계약을 체결하여 "요구사항 사양, 시뮬레이션, 사용자 인터페이스 프로토타이핑, 하드웨어 아키텍처에 대한 요구 사항 매핑 및 코드 생성을 지원하는 상업적 품질 RIE"를 개발했다. 이 시스템은 Advanced Requirements Engineering Workstation 또는 AREW라고 한다.[1]
비 관계형 환경[편집]
데이터의 비 관계적 정의(예: Cache 또는 연관 모델 사용)는 시뮬레이션 반복 시마다 데이터를 정규화할 필요성을 지연시키거나 방지하여 최종 사용자 프로토타이핑의 생산성을 높일 수 있다. 이는 비즈니스 요구 사항이 더 일찍, 더 명확해질 수 있지만, 대상 프로덕션 시스템에서 요구 사항이 기술적으로 경제적으로 실행 가능한지 구체적으로 확인하지는 않는다.[1]
PSDL[편집]
PSLD은 실시간 소프트웨어를 설명하는 프로토타입 설명 언어다. 관련 도구 세트는 컴퓨터 보조 프로토타이핑 시스템(Computer Aided Prototyping System, CAPS)이다.[1] 타이밍 제약으로 인해 구현 및 하드웨어 종속성이 발생하기 때문에 엄격한 실시간 요구사항이 있는 소프트웨어 시스템을 프로토타이핑하는 것은 어렵다. PSDL은 선언적 타이밍 제약을 포함하는 제어 추상화를 도입하여 이러한 문제를 해결한다. CAPS는 이 정보를 사용하여 코드 및 관련 실시간 일정을 자동으로 생성하고, 프로토타입 실행 중에 타이밍 제약사항을 모니터링하며, 매개 변수화 된 하드웨어 모델 세트에 비례하여 실시간으로 실행을 시뮬레이션한다. 또한, 불완전한 프로토타입 설명의 실행을 가능하게 하는 기본 가정을 제공하고, 효율적인 구현을 신속하게 실현하기 위해 프로토타입 구성을 소프트웨어 재사용 저장소와 통합하며, 요구 사항 및 설계의 신속한 진화를 지원한다. [10]
각주[편집]
- ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16 Software prototyping WIKIPEDIA - https://en.wikipedia.org/wiki/Software_prototyping#Outline_of_the_prototyping_process
- ↑ 2.0 2.1 프로토타입 위키백과 - https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9C%ED%86%A0%ED%83%80%EC%9E%85
- ↑ Paper prototyping WIKIPEDIA - https://en.wikipedia.org/wiki/Paper_prototyping
- ↑ Graphical user interface builder WIKIPEDIA - https://en.wikipedia.org/wiki/Graphical_user_interface_builder
- ↑ 일괄 처리 위키백과 - https://ko.wikipedia.org/wiki/%EC%9D%BC%EA%B4%84_%EC%B2%98%EB%A6%AC
- ↑ Timeboxing WIKIPEDIA - https://en.wikipedia.org/wiki/Timeboxing Timeboxing
- ↑ Bootstrap (front-end framework) WIKIPEDIA - https://en.wikipedia.org/wiki/Bootstrap_(front-end_framework)
- ↑ Foundation (framework) WIKIPEDIA - https://en.wikipedia.org/wiki/Foundation_(framework)
- ↑ AngularJS WIKIPEDIA - https://en.wikipedia.org/wiki/AngularJS
- ↑ Luqi (Naval Postgraduate School), 〈Software evolution through rapid prototyping〉, 《zenodo》, 1989-05-01
참고 자료[편집]
- Software prototyping WIKIPEDIA - https://en.wikipedia.org/wiki/Software_prototyping#Outline_of_the_prototyping_process
- 프로토타입 위키백과 - https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9C%ED%86%A0%ED%83%80%EC%9E%85
- Paper prototyping WIKIPEDIA - https://en.wikipedia.org/wiki/Paper_prototyping
- Graphical user interface builder WIKIPEDIA - https://en.wikipedia.org/wiki/Graphical_user_interface_builder
- 일괄 처리 위키백과 - https://ko.wikipedia.org/wiki/%EC%9D%BC%EA%B4%84_%EC%B2%98%EB%A6%AC
- Timeboxing WIKIPEDIA - https://en.wikipedia.org/wiki/Timeboxing Timeboxing
- Bootstrap (front-end framework) WIKIPEDIA - https://en.wikipedia.org/wiki/Bootstrap_(front-end_framework)
- Foundation (framework) WIKIPEDIA - https://en.wikipedia.org/wiki/Foundation_(framework)
- AngularJS WIKIPEDIA - https://en.wikipedia.org/wiki/AngularJS
- Luqi (Naval Postgraduate School), 〈Software evolution through rapid prototyping〉, 《zenodo》, 1989-05-01
- 프로토타입 나무위키- https://namu.wiki/w/%ED%94%84%EB%A1%9C%ED%86%A0%ED%83%80%EC%9E%85
같이 보기[편집]
- 프로그래밍
- 소프트웨어 개발 방법론(SDM)
