소프트웨어 프로토타이핑

시리즈의 일부
소프트웨어 개발
핵심 활동 과정 요구 사항들 설계. 건설 공학 기술 테스트 디버깅 도입 유지
패러다임 및 모델 소프트웨어 엔지니어링 민첩성 클린룸 증분 시제품 제작 나선형 V모델 폭포
방법론 및 프레임워크 Asd. DevOps 아빠. DSDM FDD 아이디 칸반 린 SD 더 적은 MDD MSF PSP RAD RUP 안전한 스크럼 세마토 TSP 열어 보세요. 업. XP
지원 분야 구성 관리 문서 소프트웨어 품질 보증 프로젝트 관리 사용자 경험
프랙티스 ATDD BDD CCO CI CD Ddd. PP SBE 스탠드업 TDD
도구들 컴파일러 디버거 프로파일러 GUI 디자이너 모델링. IDE 자동화 구축 릴리스 자동화 코드로서의 인프라스트럭처 테스트
지식의 표준과 본문 바복 CMMI IEEE 표준 ISO 9001 ISO/IEC 표준 PMBOK 스웨복 IT 인식하다
용어집 인공지능 컴퓨터 공학 전기전자공학
개요 소프트웨어 개발의 개요
v t

소프트웨어 프로토타이핑은 개발 중인 소프트웨어 프로그램의 불완전한 버전 등 소프트웨어 애플리케이션의 프로토타입을 만드는 활동입니다.소프트웨어 개발에서 발생할 수 있는 활동이며 기계 공학 또는 제조와 같은 다른 분야에서 알려진 프로토타이핑에 필적합니다.

프로토타입은 일반적으로 최종 제품의 일부 측면만 시뮬레이션하며, 최종 제품과 완전히 다를 수 있습니다.

프로토타이핑에는 몇 가지 이점이 있습니다. 소프트웨어 설계자와 구현자는 프로젝트 초기에 사용자로부터 귀중한 피드백을 받을 수 있습니다.클라이언트와 청부업자는 작성된 소프트웨어가 소프트웨어 사양과 일치하는지 여부를 비교할 수 있습니다.이것에 따라 소프트웨어 프로그램이 구축됩니다.또한 소프트웨어 엔지니어는 초기 프로젝트 견적의 정확성과 제안된 마감일 및 이정표를 성공적으로 충족할 수 있는지 여부를 파악할 수 있습니다.시제품 제작의 완성도와 기술은 1970년대 ^[1]초 제안 이후 개발 및 논의되어 왔습니다.

개요

프로토타입의 목적은 소프트웨어 사용자가 설명에 따라 설계를 해석하고 평가하는 것이 아니라 최종 제품 설계에 대한 개발자의 제안을 실제로 시험함으로써 평가할 수 있도록 하는 것입니다.소프트웨어 프로토타이핑을 통해 소프트웨어의 기능과 잠재적인 위협 또는 ^[2]문제를 파악할 수 있습니다.프로토타이핑은 최종 사용자가 고려되지 않은 요구사항을 설명하고 입증하는 데 사용할 수도 있으며, 이는 개발자와 ^[3]고객 간의 상업적 관계에 중요한 요소가 될 수 있습니다.특히 인터랙션 설계는 이러한 목표를 위해 프로토타이핑을 많이 활용합니다.

이 프로세스는 프로그램 전체를 먼저 구축한 후 설계와 구현 간의 불일치를 해결하던 1960년대와 1970년대의 획일적인 개발 사이클과는 대조적입니다.그 결과 소프트웨어 비용이 상승하고 시간과 비용이 ^{[citation needed]}적게 듭니다.소프트웨어 설계자와 개발자가 혼자서 드래곤 전체를 죽여야 하는 단 한 명의 영웅이라고 가정해 일명 '드래곤 슬레이잉(소프트웨어) 기술'로 불린다.프로토타이핑은 또한 완성된 소프트웨어 제품을 변경해야 하는 큰 비용과 어려움을 피할 수 있습니다.

시제품 제작의 실천은 Frederick P. Brooks가 1975년 저서 The Mysterious Man-Month와 10주년 기념 기사 "No Silver Bullet"에서 언급한 사항 중 하나입니다.

대규모 소프트웨어 프로토타이핑의 초기 예는 Ada 프로그래밍 ^[4]언어에 대한 NYU의 Ada/ED 번역기의 구현이었습니다.속도와 효율성보다 설계와 사용자 인터페이스의 명확성을 강조하면서 Ada 언어를 위한 실행 가능한 의미 모델을 만들기 위해 SETL에서 구현되었습니다.NYU Ada/ED 시스템은 1983년 ^[5]4월 11일 인증된 최초의 Ada 구현입니다.

개요

프로토타이핑 프로세스에는 다음과 ^{[citation needed]}같은 단계가 포함됩니다.

1. 기본적인 요건을 특정하다

   필요한 입력 및 출력 정보를 포함한 기본 요건을 결정합니다.일반적으로 보안과 같은 세부 사항은 무시해도 됩니다.

2. 초기 프로토타입 개발

   초기 프로토타입은 사용자 인터페이스만 포함하는 형태로 개발되었습니다.(아래 수평 프로토타입 참조)

3. 검토

   최종 사용자를 포함한 고객이 프로토타입을 검토하고 추가 또는 변경 가능성에 대한 피드백을 제공합니다.

4. 프로토타입 수정 및 개선

   피드백을 활용하면 사양과 프로토타입 모두를 개선할 수 있습니다.계약/제품 범위 내에서의 협상이 필요할 수 있습니다.변경이 있을 경우 스텝3과 스텝4를 반복해야 할 수 있습니다.

치수

Nielsen은 자신의 저서 Usability Engineering에서 프로토타입의 다양한 차원을 요약합니다.

수평 프로토타입

사용자 인터페이스 프로토타입의 일반적인 용어는 수평 프로토타입입니다.데이터베이스 액세스와 같은 낮은 수준의 시스템 기능보다 사용자 상호 작용에 초점을 맞춘 전체 시스템 또는 하위 시스템을 폭넓게 볼 수 있습니다.수평 프로토타입은 다음과 같은 경우에 유용합니다.

• 사용자 인터페이스 요건 및 시스템 범위 확인
• 기업으로부터 매입을 취득하기 위한 시스템의 데모 버전,
• 개발 시간, 비용 및 노력에 대한 예비 견적을 작성합니다.

세로형 프로토타입

수직 프로토타입은 단일 서브시스템 또는 기능을 완전히 정교하게 만든 것입니다.이는 특정 기능에 대한 세부 요건을 취득하는 데 유용하며 다음과 같은 이점이 있습니다.

• 데이터베이스 설계 개선,
• 네트워크 사이징 및 퍼포먼스 엔지니어링을 위해 데이터 볼륨 및 시스템 인터페이스 요구에 대한 정보를 입수합니다.
• 실제 시스템 기능을 드릴다운하여 복잡한 요건을 명확히 합니다.

종류들

소프트웨어 프로토타이핑에는 다양한 종류가 있습니다.그러나 모든 방법은 두 가지 주요 프로토타이핑 형태인 일회용 프로토타이핑과 진화적 프로토타이핑을 기반으로 합니다.

일회용 시제품 제작

클로즈 엔드 프로토타이핑이라고도 합니다.일회용 또는 신속한 프로토타이핑은 최종 제공된 소프트웨어의 일부가 아닌 최종적으로 폐기될 모델을 만드는 것을 의미합니다.예비요건 수집이 이루어진 후, 시스템의 간단한 작업모델을 구축하여 완성된 시스템에 구현되었을 때 사용자의 요건이 어떻게 보일지 시각적으로 보여준다.이것은 또한 신속한 프로토타이핑의 한 형태입니다.

신속한 프로토타이핑은 비교적 짧은 조사 후에 매우 이른 단계에서 시스템의 다양한 부품에 대한 작업 모델을 만드는 것을 포함합니다.건설에 사용되는 방법은 대개 상당히 비공식적이며, 가장 중요한 요소는 모델이 제공되는 속도입니다.이 모델은 사용자가 기대치를 재검토하고 요건을 명확히 하는 출발점이 됩니다.이 목표가 달성되면, 프로토타입 모델은 '삭감'되고, 시스템은 식별된 ^[6]요구 사항에 따라 정식으로 개발됩니다.

일회용 프로토타이핑을 사용하는 가장 확실한 이유는 프로토타이핑이 빠르게 이루어질 수 있기 때문입니다.사용자가 요건에 대한 피드백을 신속하게 얻을 수 있다면 소프트웨어 개발 초기에 요건을 개선할 수 있을 것입니다.개발 라이프 사이클 초기에 변경을 가하는 것은 재실행할 필요가 없기 때문에 매우 비용 효율적입니다.상당한 양의 작업이 완료된 후 프로젝트를 변경할 경우 소프트웨어 시스템의 의존성이 크기 때문에 작은 변경에도 큰 노력이 필요할 수 있습니다.시간과 비용이 한정되어 있기 때문에 폐기되는 프로토타입에는 거의 비용을 들이지 않기 때문에 일회용 프로토타입을 구현하는 데 속도는 매우 중요합니다.

일회용 프로토타이핑의 또 다른 강점은 사용자가 테스트할 수 있는 인터페이스를 구성할 수 있다는 것입니다.유저 인터페이스는 유저에게 있어서 시스템이라고 생각되는 것으로, 유저 인터페이스 앞에서 보는 것으로, 시스템이 어떻게 기능하는지를 파악하는 것이 훨씬 쉬워집니다.

…혁신적인 신속한 프로토타이핑이 사용자 요구사항과 관련된 문제를 보다 효과적으로 처리할 수 있는 방법이며, 따라서 소프트웨어 생산성이 전반적으로 크게 향상된다는 주장이 있습니다.진화 가능성, 유지보수성 및 소프트웨어 구조의 문제가 무시될 경우 요구사항을 훨씬 빠르고 저렴하게 식별, 시뮬레이션 및 테스트할 수 있습니다.그 결과, 기존의 소프트웨어 개발 ^[7]모델을 통해 요건의 정확한 지정과 사용자의 관점에서 유효하고 사용 가능한 시스템의 구축으로 이어집니다.

프로토타입은 외관, 상호작용 및 타이밍 면에서 실제 제품과 유사한 충실도에 따라 분류할 수 있습니다.저충실도 일회용 프로토타입을 만드는 한 가지 방법은 종이 프로토타이핑입니다.시제품은 종이와 연필을 사용하여 구현되어 실제 제품의 기능을 모방하고 있지만 겉모습은 전혀 닮지 않았습니다.고충실도 일회용 프로토타입을 쉽게 제작하는 또 다른 방법은 GUI Builder를 사용하여 클릭 더미를 만드는 것입니다. 클릭 더미는 목표 시스템과 비슷하지만 기능을 제공하지 않는 프로토타입입니다.

스토리보드, 애니메이션 또는 그림의 용도는 일회용 프로토타이핑과 정확히 동일하지는 않지만, 확실히 같은 계열에 속합니다.이것들은 기능하지 않는 실장입니다만, 시스템의 외관을 나타내고 있습니다.

요약:.이 접근 방식에서는 프로토타입이 폐기되고 최종 시스템이 처음부터 구축된다는 생각으로 제작됩니다.이 어프로치의 순서는 다음과 같습니다.

1. 예비 요건을 기입하다
2. 프로토타입 설계
3. 사용자가 프로토타입을 경험/사용하여 새로운 요건을 지정하다
4. 필요한 경우 반복합니다.
5. 최종 요건을 기입하다

진화적 프로토타이핑

진화적 프로토타이핑(일명 브레드보드 프로토타이핑)은 일회용 프로토타이핑과는 상당히 다릅니다.진화적 프로토타이핑을 사용할 때의 주요 목표는 매우 견고한 프로토타입을 구조화된 방식으로 제작하고 지속적으로 정교하게 만드는 것입니다.이러한 접근방식을 사용하는 이유는 진화적 프로토타입을 구축하면 새로운 시스템의 핵심이 되고 개선사항과 추가 요구사항이 구축되기 때문입니다.

진화적 프로토타이핑을 사용하여 시스템을 개발할 때 시스템은 지속적으로 개선되고 재구축됩니다.

"…기본 프로토타이핑은 우리가 모든 요구 사항을 이해하지 못하고 ^[8]잘 이해된 요구 사항만 구축한다는 것을 인정합니다.

이 기술을 통해 개발 팀은 요구 사항 및 설계 단계에서 생각할 수 없는 기능을 추가하거나 변경할 수 있습니다.

시스템이 유용하게 쓰이려면 의도된 운영 환경에서 사용을 통해 진화해야 합니다.제품은 결코 '완성'되는 것이 아닙니다.사용환경의 변화에 따라 항상 성숙합니다.현재의 가장 친숙한 기준 프레임을 사용하여 시스템을 정의하려고 하는 경우가 많습니다.델은, 비즈니스의 실시 방법이나, 비즈니스의 실장 기반이 되는 테크놀로지 베이스에 대해 전제를 실시합니다.능력을 개발하기 위한 계획이 수립되고, 조만간 구상된 시스템과 유사한 것이 ^[9]전달된다.

진화형 프로토타입은 기능적 시스템이라는 점에서 일회용 프로토타입보다 유리합니다.사용자가 계획한 모든 기능을 갖추고 있지는 않지만 최종 시스템이 제공될 때까지 임시로 사용할 수 있습니다.

"프로토타이핑 환경에서 사용자가 더 발전된 버전을 기다리는 동안 초기 프로토타입을 실용화하는 것은 드문 일이 아닙니다.사용자는 시스템이 아예 ^[6]없는 것보다는 '날개가 달린' 시스템이 낫다고 판단할 수 있습니다."

진화적 프로토타이핑에서 개발자는 전체 시스템을 개발하는 대신 자신이 이해하는 시스템의 일부를 개발하는 데 집중할 수 있습니다.

위험을 최소화하기 위해 개발자는 제대로 이해되지 않은 기능을 구현하지 않습니다.일부 시스템은 고객 사이트로 전송됩니다.사용자는 시스템을 사용하여 작업할 때 새로운 기능에 대한 기회를 감지하고 이러한 기능에 대한 요청을 개발자에게 제공합니다.그런 다음 개발자는 이러한 확장 요청을 자신의 요구와 함께 받아들이고 적절한 구성 관리 방식을 사용하여 소프트웨어 요구 사양 변경, 설계 업데이트, 재코딩 및 ^[10]재테스트를 수행합니다.

증분 프로토타이핑

최종 제품은 별도의 시제품으로 제작됩니다.마지막으로 개별 프로토타입이 전체 설계로 병합됩니다.증분 프로토타이핑을 통해 사용자와 소프트웨어 개발자 간의 시간 차이를 줄일 수 있습니다.

익스트림 프로토타이핑

개발 프로세스로서의 익스트림 프로토타이핑은 특히 웹 애플리케이션 개발에 사용됩니다.기본적으로 웹 개발을 세 단계로 나누는데, 각 단계는 앞서 말한 단계를 기반으로 합니다.첫 번째 단계는 주로 HTML 페이지로 구성된 정적 프로토타입입니다.두 번째 단계에서는 시뮬레이션된 서비스 계층을 사용하여 화면이 프로그래밍되고 완전히 기능합니다.세 번째 단계에서는 서비스를 구현합니다.

"^[11]프로세스의 두 번째 단계에 관심을 끌기 위해 Extreme Prototyping이라고 불리는 프로세스입니다. 두 번째 단계에서는 계약 이외의 서비스에 대해 거의 고려하지 않고 완전히 기능하는 UI가 개발됩니다."

이점

소프트웨어 개발에서 프로토타이핑을 사용하면 여러 가지 이점이 있습니다. 구체적이고 ^[12]추상적인 것도 있습니다.

시간과 비용 절감: 프로토타이핑을 통해 개발자에게 제공되는 요구사항 및 사양의 품질을 개선할 수 있습니다.변경은 나중에 개발 단계에서 발견될 때 구현 비용이 기하급수적으로 증가하므로 사용자가 진정으로 원하는 것을 조기에 결정하면 소프트웨어를 ^[7]더 빠르고 저렴하게 만들 수 있습니다.

사용자 참여도 향상 및 증가: 프로토타이핑은 사용자의 참여를 필요로 하며 프로토타입을 보고 상호 작용할 수 있으므로 더 좋고 완벽한 피드백과 ^[6]사양을 제공할 수 있습니다.사용자가 검사 중인 시제품의 존재는 양측이 그들이 말한 것을 이해한다고 믿을 때 발생하는 많은 오해와 잘못된 의사소통을 막는다.사용자는 개발팀의 누구보다도 문제 영역을 잘 알고 있기 때문에 상호작용을 늘리면 유무형의 품질이 뛰어난 최종 제품이 될 수 있습니다.최종 제품은 사용자의 외모, 느낌, 성능에 대한 욕구를 충족시킬 가능성이 높습니다.

단점들

프로토타이핑을 사용하거나 잘못 사용하면 단점도 있을 수 있습니다.

불충분한 분석:제한된 프로토타입에 초점을 맞추면 개발자가 프로젝트 전체를 제대로 분석하지 못할 수 있습니다.이로 인해 더 나은 솔루션을 간과하거나, 불완전한 사양을 준비하거나, 제한된 프로토타입을 유지보수가 어려운 부실 엔지니어링된 최종 프로젝트로 전환하는 결과를 초래할 수 있습니다.또한 프로토타입은 기능이 제한적이기 때문에 최종 성과물의 기준으로 프로토타입을 사용하는 경우 확장성이 좋지 않을 수 있습니다. 개발자가 프로토타입을 모델로 제작하는 데 너무 집중하면 이러한 현상이 나타나지 않을 수 있습니다.

시제품과 완성된 시스템의 사용자 혼란:사용자는 시제품은 폐기할 예정이지만 실제로는 완성이나 연마만 하면 되는 최종 시스템이라고 생각하기 시작할 수 있습니다(예를 들어 시제품에는 없는 오류 검사나 보안 기능을 추가하는 데 필요한 노력을 인식하지 못하는 경우가 많습니다).이를 통해 개발자의 의도가 아닌 경우 프로토타입이 최종 시스템의 성능을 정확하게 모델링할 것으로 예상할 수 있습니다.사용자는 또한 검토하기 위해 프로토타입에 포함된 기능에 애착을 갖고 최종 시스템 사양에서 제거할 수 있습니다.사용자가 제안된 모든 기능을 최종 시스템에 포함하도록 요구할 수 있는 경우 충돌이 발생할 수 있습니다.

사용자 목표에 대한 개발자의 오해:개발자는 사용자가 보다 광범위한 상업적 문제를 이해하지 않고 목표를 공유한다고 가정할 수 있습니다(예: 핵심 기능을 예산 내에서 제때 제공).예를 들어, 엔터프라이즈 소프트웨어(PeopleSoft 등) 이벤트에 참가한 사용자 담당자는 이 기능에 추가 코딩이 필요하며 추가 데이터베이스 액세스를 처리하기 위해 더 많은 하드웨어가 필요하다는 것을 알리지 않고 트랜잭션 감사(변경 내용이 기록되고 차분 그리드 뷰에 표시됨)의 데모를 볼 수 있습니다.사용자는 모든 분야에서 감사를 요구할 수 있다고 믿는 반면 개발자는 사용자 요구사항의 정도에 대해 가정했기 때문에 이것이 기능 크리프라고 생각할 수 있습니다.개발자가 사용자 요건을 검토하기 전에 제공하기로 약속했을 경우 개발자는 특히 사용자 관리가 요건을 구현하지 못한 것으로부터 어느 정도 이점을 얻을 수 있는 경우에는 곤란한 상황에 처하게 됩니다.

프로토타입에 대한 개발자 애착:또한 개발자는 많은 노력을 들인 프로토타입에 애착을 가질 수 있습니다. 따라서 적절한 기본 아키텍처가 없을 때 제한된 프로토타입을 최종 시스템으로 변환하려고 시도하는 등의 문제가 발생할 수 있습니다.(이는 진화적 프로토타이핑이 아닌 일회용 프로토타이핑을 사용해야 한다는 것을 의미할 수 있습니다.)

프로토타입의 과도한 개발 시간:프로토타이핑의 핵심 특성은 프로토타이핑이 신속하게 완료되어야 한다는 사실입니다.개발자들이 이 사실을 놓치면 너무 복잡한 프로토타입을 개발하려고 할 수도 있다.프로토타입을 폐기할 경우, 제공되는 정밀하게 개발된 요구사항은 프로토타입을 개발하는 데 소요된 시간을 보충하기에 충분한 생산성 향상을 가져오지 못할 수 있습니다.사용자는 프로토타입의 세부 사항에 대한 논쟁에 휘말려 개발팀의 발목을 잡고 최종 제품을 지연시킬 수 있습니다.

프로토타이핑 구현 비용: 프로토타이핑에 초점을 맞춘 개발 팀을 구성하기 위한 초기 비용이 높을 수 있습니다.많은 기업이 개발 방법론을 도입하고 있으며, 이를 변경하면 재교육, 재교육 또는 둘 다 수행될 수 있습니다.많은 기업들이 직원을 필요한 만큼 재교육하지 않고 시제품 제작을 시작하는 경향이 있습니다.

프로토타이핑 기술을 채택할 때의 공통적인 문제는 학습 곡선에 대한 노력이 부족하여 생산성에 대한 기대가 높다는 것입니다.프로토타이핑 기술을 사용하기 위한 교육 외에도, 이 기술을 지원하기 위해 기업 및 프로젝트 고유의 기본 구조를 개발해야 하는 필요성이 간과되는 경우가 많습니다.이 기본 구조를 생략하면 생산성이 저하되는 ^[13]경우가 많습니다.

적용 가능성

어떤 형태로든 프로토타이핑을 항상 사용해야 한다는 주장이 제기되었습니다.그러나 프로토타이핑은 사용자와 많은 상호작용을 하는 시스템에서 가장 유용합니다.

프로토타이핑은 온라인 시스템의 분석 및 설계, 특히 화면 대화상자의 사용이 훨씬 더 많은 증거인 트랜잭션 처리에 매우 효과적인 것으로 나타났습니다.컴퓨터와 사용자 간의 상호작용이 클수록 빠른 시스템을 구축하고 사용자가 시스템을 ^[6]가지고 놀 수 있게 함으로써 얻을 수 있는 이점이 커집니다.

배치 처리나 계산을 주로 수행하는 시스템과 같이 사용자 상호 작용이 거의 없는 시스템은 프로토타이핑의 이점을 거의 얻지 못합니다.때로는 시스템 기능을 수행하는 데 필요한 코딩이 너무 집약적이고 프로토타이핑이 제공할 수 있는 잠재적 이득이 너무 ^[6]작을 수 있습니다.

프로토타이핑은 우수한 인간-컴퓨터 인터페이스를 설계하는 데 특히 유용합니다."지금까지 신속한 프로토타이핑의 가장 생산적인 사용 중 하나는 반복적인 사용자 요구사항 엔지니어링 및 인간-컴퓨터 인터페이스 ^[7]설계를 위한 도구였습니다."

동적 시스템 개발 방법

DSDM(^[14]Dynamic Systems Development Method)은 핵심 기술로 프로토타이핑에 크게 의존하는 비즈니스 솔루션을 제공하기 위한 프레임워크이며 ISO 9001의 승인을 받았습니다.이것은 프로토타입에 대해 가장 잘 알려진 정의를 확장합니다.DSDM에 따르면 프로토타입은 다이어그램, 비즈니스 프로세스 또는 실제 가동 중인 시스템일 수 있습니다.DSDM 프로토타입은 단순한 형태에서 보다 포괄적인 형태로 진화하는 증분형 프로토타입입니다.

DSDM 프로토타입은 일회용이거나 진화형일 수 있습니다.진화형 프로토타입은 수평(빵 크기 이후 깊이) 또는 수직(각 섹션은 후속 섹션을 세부적으로 설명하는 추가 반복으로 세부적으로 제작됨)으로 진화할 수 있습니다.진화적 프로토타입은 결국 최종 시스템으로 진화할 수 있습니다.

DSDM이 권장하는 시제품의 네 가지 범주는 다음과 같습니다.

• 비즈니스 프로토타입 – 자동화되는 비즈니스 프로세스를 설계하고 시연하는 데 사용됩니다.
• 사용 편의성 프로토타입 – 사용자 인터페이스 설계의 사용 편의성, 접근성, 외관 및 느낌을 정의, 세분화 및 시연하는 데 사용됩니다.
• 퍼포먼스 및 용량 프로토타입– 피크 부하에서 시스템이 어떻게 동작하는지 정의, 시연 및 예측하고 시스템의 기타 비기능적인 측면(트랜잭션 속도, 데이터 스토리지 볼륨, 응답 시간 등)을 시연 및 평가하는 데 사용됩니다.
• 기능/기술 프로토타입 – 설계 접근법 또는 개념을 개발, 시연 및 평가하는 데 사용됩니다.

시제품의 DSDM 라이프 사이클은 다음과 같습니다.

1. 시제품 식별
2. 계획에 동의하다
3. 프로토타입을 작성하다
4. 시제품 검토

운영 프로토타이핑

운영 프로토타이핑은 일회용 프로토타이핑과 진화적 프로토타이핑을 기존의 시스템 개발과 통합하는 방법으로 Alan Davis에 의해 제안되었습니다.「신속하고 더러운 세계와 종래의 개발 세계 양쪽의 장점을 합리적인 방법으로 제공합니다.디자이너는 진화적 기준선을 구축하는 과정에서 잘 이해된 기능만 개발하고 일회용 프로토타이핑을 사용하여 잘 이해되지 않는 ^[8]기능을 실험합니다."

데이비스는 "빠른 시제품에 품질을 재적합"하려고 하는 것은 두 가지 접근 방식을 결합할 때 올바른 방법이 아니라고 믿고 있습니다.그의 아이디어는 진화적 프로토타이핑 방법론에 참여하고 각 진화 후에 시스템의 특징을 신속하게 프로토타입화하는 것입니다.

구체적인 방법론은 다음 ^[8]단계를 따릅니다.

• 진화적 프로토타입을 구축하여 기존 개발 전략을 사용하여 베이스라인으로 만들고 잘 이해된 요구사항만 지정 및 구현합니다.
• 기준선의 복사본은 숙련된 프로토타입 제작자와 함께 여러 고객 사이트로 전송됩니다.
• 각 사이트에서 프로토타입 제작자는 시스템에서 사용자를 관찰합니다.
• 사용자가 문제에 부딪히거나 새로운 기능이나 요구 사항을 생각할 때마다 시제품 제작자는 이를 기록합니다.이것에 의해, 유저는 문제를 기록할 필요가 없어져, 작업을 계속할 수 있게 됩니다.
• 사용자 세션이 끝나면 프로토타이퍼는 기준선 시스템 위에 일회용 프로토타입을 구성합니다.
• 이제 사용자는 새로운 시스템을 사용하여 평가합니다.새로운 변경이 효과적이지 않을 경우 프로토타입 제작자가 이를 제거합니다.
• 사용자가 변경 사항을 마음에 들면 시제품 제작자는 기능 향상 요청을 작성하여 개발 팀에 전달합니다.
• 개발팀은 모든 사이트에서 변경 요청을 받은 후 기존 방법을 사용하여 새로운 진화형 프로토타입을 제작합니다.

이 방법의 핵심은 사용자 사이트에 갈 수 있도록 잘 훈련된 프로토타이퍼를 확보하는 것입니다.운영 프로토타이핑 방법론은 복잡하고 사전에 알려진 요구사항이 거의 없는 시스템에서 많은 이점을 제공합니다.

진화적 시스템 개발

Evolutionary Systems Development는 진화적 프로토타이핑을 공식적으로 구현하려는 방법론의 한 종류입니다.Systemscraft라고 불리는 한 가지 특별한 유형은 John Crinnion에 의해 그의 책인 Evolutionary Systems Development에서 묘사되었다.

Systemscraft는 '프로토타입' 방법론으로 설계되었으며, 이 방법은 구현된 특정 환경에 맞게 수정 및 조정되어야 합니다.

시스템 스크래프트는 개발 프로세스에 대한 엄격한 '쿡북' 접근 방식으로 설계되지 않았습니다.좋은 방법론은 모든 종류의 환경과 ^[6]상황에 맞게 조정할 수 있을 정도로 유연해야 한다는 것이 현재 일반적으로 인식되고 있다.

진화적 프로토타이핑과 달리 Systemscraft의 기본은 초기 요구사항에서 작업 시스템을 만들고 이를 기반으로 일련의 수정사항을 구축하는 것입니다.시스템 스크래프트는 시스템 개발 전반에 걸쳐 사용되는 기존 분석에 중점을 두고 있습니다.

진화의 급속한 발전

Evolutionary Rapid Development(ERD)^[15]는 DARPA(Defense Advanced Research Projects Agency)의 정보기술 사무소의 기술 개발 및 통합 에이전트인 Software Productivity Consortium에 의해 개발되었습니다.

ERD의 기본은 컴포넌트의 재사용, 소프트웨어 템플릿의 사용 및 아키텍처 템플릿을 기반으로 소프트웨어 시스템을 구성하는 개념입니다.변화하는 사용자 요구와 기술에 신속하게 대응하는 시스템 기능의 지속적인 진화는 솔루션 클래스를 나타내는 진화가 가능한 아키텍처에 의해 강조됩니다.이 프로세스는 소프트웨어 및 시스템 엔지니어링 분야를 통합하는 소규모 장인 기반 팀의 사용에 중점을 두고 있으며, 고객과의 빈번한 상호 작용이 수반되는 여러 개의 단기간 타임박스를 병행하는 경우가 많습니다.

ERD 기반 프로젝트의 성공 비결은 첨단 기술을 채택하여 기술, 시장 또는 고객 ^[9]요구사항의 변화에 신속하게 대응할 수 있도록 기능, 인프라 및 컴포넌트의 병렬 탐색 분석 및 개발입니다.

고객/사용자의 의견을 이끌어내기 위해 이해관계자와의 정기적인 임시/즉시 미팅을 자주 개최합니다.설계/실장 결정이 확정되기 전에 피드백을 얻기 위해 시스템 기능의 데모를 실시합니다.빈번한 릴리스(베타 등)를 사용하여 시스템이 사용자 및 고객의 요구를 보다 효과적으로 지원할 수 있는 방법을 파악할 수 있습니다.이것에 의해, 시스템은 기존의 유저의 요구를 만족시키기 위해서 진화합니다.

시스템의 설계 프레임워크는 기존의 공개 또는 사실상의 표준을 사용하는 것에 기초하고 있습니다.이 시스템은 성능, 용량 및 기능에 대한 고려사항을 포함하는 일련의 기능을 발전시킬 수 있도록 구성되어 있습니다.아키텍처는 서비스와 그 구현을 캡슐화하는 추상적인 인터페이스(COTS 애플리케이션 등)의 관점에서 정의됩니다.아키텍처는 시스템의 여러 인스턴스 개발을 안내하기 위해 사용되는 템플릿 역할을 합니다.이를 통해 여러 애플리케이션 구성 요소를 사용하여 서비스를 구현할 수 있습니다.변경 가능성이 없는 핵심 기능 세트도 식별 및 확립됩니다.

ERD 프로세스는 이해관계자가 자신의 요구와 기대를 전달할 수 있는 방법으로 종이 제품이 아닌 검증된 기능을 사용하도록 구성되어 있습니다.이러한 신속한 배송 목표의 중심에는 "타임박스" 방식을 사용하는 것이 있습니다.타임박스는 특정 태스크(예: 기능 세트 개발)를 수행해야 하는 고정 기간입니다.모호한 목표를 만족시키기 위해 시간을 확장하는 것이 아니라, 시간은 일정 주 단위와 인적 시간 단위로 고정되며, 이러한 제약 조건 내에서 현실적으로 달성할 수 있는 목표 세트가 정의됩니다.개발이 "랜덤 워크"로 전락하는 것을 방지하기 위해 반복을 안내하는 장기 계획을 정의합니다.이러한 계획은 전체 시스템에 대한 비전을 제공하고 프로젝트의 경계(예: 제약)를 설정합니다.프로세스 내의 각 반복은 이러한 장기 계획의 맥락에서 수행됩니다.

일단 아키텍처가 확립되면 소프트웨어는 매일 통합되고 테스트됩니다.이를 통해 팀은 진행 상황을 객관적으로 평가하고 잠재적인 문제를 신속하게 파악할 수 있습니다.소량의 시스템이 한 번에 통합되어 있기 때문에 결함을 신속하게 진단하고 제거할 수 있습니다.시스템은 일반적으로 항상 연습할 준비가 되어 있기 때문에 사용자 데모는 단기간에 실시할 수 있습니다.

도구들

프로토타이핑을 효율적으로 사용하려면 조직에 적절한 도구와 이러한 도구를 사용할 수 있는 교육을 받은 직원이 있어야 합니다.프로토타이핑에 사용되는 도구는 고속 프로토타이핑에 사용되는 4세대 프로그래밍 언어, 복잡한 통합 CASE 도구 등 개별 도구에서 다양할 수 있습니다.Visual Basic과 Cold Fusion과 같은 4세대 비주얼 프로그래밍 언어는 저렴하고 잘 알려져 있으며 비교적 쉽고 빠르게 사용할 수 있기 때문에 자주 사용됩니다.CASE 툴은 요건 엔지니어링 환경(아래 참조)과 같은 요건 분석을 지원하는 것으로, 군사기관이나 대규모 조직이 개발 또는 선택하는 경우가 많습니다.GE 연구개발센터의 LYMB와 같은 객체 지향 툴도 개발되고 있습니다.사용자는 스프레드시트에서 응용 프로그램 자체의 요소를 프로토타입으로 만들 수 있습니다.

웹 기반 애플리케이션의 인기가 계속 증가함에 따라 이러한 애플리케이션을 프로토타이핑할 수 있는 도구도 갖추게 되었습니다.부트스트랩, 기초, 각도 등의 프레임워크JS는 개념 증명을 신속하게 구성하는 데 필요한 도구를 제공합니다.이러한 프레임워크는 일반적으로 일련의 제어, 상호작용 및 설계 가이드라인으로 구성되어 개발자가 웹 애플리케이션을 신속하게 프로토타입으로 만들 수 있습니다.

화면 생성기, 설계 도구 및 소프트웨어 팩토리

화면 생성 프로그램도 일반적으로 사용되며, 프로토타입 제작자가 작동하지 않는 사용자의 시스템을 보여주지만 화면이 어떻게 보이는지 보여줄 수 있습니다.사용자에게는 인터페이스가 본질적으로 시스템이기 때문에 휴먼 컴퓨터 인터페이스 개발이 개발 노력의 중요한 부분이 될 수 있습니다.

소프트웨어 팩토리에서는 즉시 사용할 수 있는 모듈러 컴포넌트를 조합하여 코드를 생성할 수 있습니다.따라서 이러한 접근 방식은 최소한의 수동 코딩으로 원하는 동작의 프로그램을 신속하게 제공할 수 있기 때문에 프로토타이핑 애플리케이션에 이상적입니다.

응용 프로그램 정의 또는 시뮬레이션 소프트웨어

애플리케이션 정의 또는 시뮬레이션 소프트웨어라고 불리는 새로운 종류의 소프트웨어를 사용하면 코드를 작성하지 않고도 다른 컴퓨터 프로그램의 가볍고 애니메이션 시뮬레이션을 신속하게 구축할 수 있습니다.애플리케이션 시뮬레이션 소프트웨어를 사용하면 기술 사용자 및 비기술 사용자 모두 시뮬레이션 프로그램을 경험, 테스트, 협업 및 검증할 수 있으며 주석, 스크린샷 및 도식 등의 보고서를 제공합니다.솔루션 사양 기법으로서 애플리케이션 시뮬레이션은 종이 기반 프로토타이핑이라고 불리는 위험성이 낮지만 제한적인 텍스트 또는 도면 기반 목업(또는 와이어프레임)과 시간이 많이 걸리는 고위험 코드 기반 프로토타입 사이에 있으므로 소프트웨어 전문가가 개발 요청 전에 요구 사항을 조기에 검증하고 설계를 선택할 수 있습니다.이를 통해 소프트웨어 구현과 관련된 리스크와 비용을 대폭 ^[16]절감할 수 있습니다.

응용 프로그램을 시뮬레이션하려면 컴퓨터 기반 교육, 데모 및 고객 지원을 위해 실제 소프트웨어 프로그램을 시뮬레이션하는 소프트웨어(스크린캐스트 소프트웨어 등)를 사용할 수도 있습니다.

요건 엔지니어링 환경

"1985년부터 로마 연구소에서 개발 중인 Requirements Engineering Engineerment(REE)는 복잡한 ^[17]시스템의 중요한 측면을 신속하게 표현, 구축 및 실행하기 위한 통합 도구 세트를 제공합니다.

Requirements Engineering Environment는 현재 미 공군에 의해 시스템 개발에 사용되고 있습니다.그 이유는 다음과 같습니다.

시스템 분석가가 시스템 구성요소의 기능, 사용자 인터페이스 및 성능 프로토타입 모델을 신속하게 구축할 수 있도록 지원하는 통합 도구 세트입니다.이러한 모델링 활동은 복잡한 시스템을 보다 잘 이해하고 시스템 개발 프로세스 중에 부정확한 요구사항 사양이 비용과 일정에 미치는 영향을 줄이기 위해 수행됩니다.모델은 ^[17]실행 중인 모델의 특정 행동 측면에 따라 다양한 추상화 또는 세분화 수준에서 쉽게 구성할 수 있습니다.

REE는 3개의 파트로 구성되어 있습니다.첫 번째 프로토타입은 신속한 프로토타이핑을 지원하기 위해 특별히 설계된 CASE 도구입니다.두 번째 부분은 RIP(Rapid Interface Prototyping System)라고 하며, 사용자 인터페이스를 쉽게 만들 수 있는 도구 모음입니다.REE의 세 번째 부분은 RIP 및 프로토타입에 대한 사용자 인터페이스로 그래픽으로 사용하기 쉽게 되어 있습니다.

REE의 개발자인 Rome Laboratory는 내부 요구사항 수집 방법을 지원하고자 했습니다.이들의 방법은 크게 세 가지 부분으로 구성됩니다.

• 다양한 소스(사용자, 다른 시스템에 대한 인터페이스), 사양 및 일관성 검사에서 도출
• 다양한 사용자의 요구가 상충되지 않고 기술적, 경제적으로 실현 가능하다는 분석
• 요구 사항이 도출된 검증은 사용자의 ^[17]요구를 정확하게 반영하고 있습니다.

1996년, 로마 연구소(SPS)더"상업적인 품질 REE는 요구 사항 명세서, 시뮬레이션, 사용자 인터페이스의 원형 제작, 하드웨어 아키텍처기 위한 요건의 매핑, 그리고 코드 생성을 지원하는 REE을 향상시키기 위해 소프트웨어 생산성 솔루션에 걸렸다..."[18]이 시스템은 고급 요구 사항 공학 Worksta.or AREW 입니다.

비관계 환경

데이터의 비관계적 정의(예: Caché 또는 관련 모델 사용)는 시뮬레이션을 반복할 때마다 데이터를 정규화할 필요가 없도록 지연하거나 방지함으로써 최종 사용자의 프로토타이핑 생산성을 높이는 데 도움이 됩니다.이는 비즈니스 요건의 조기/확실한 결과를 가져올 수 있지만, 요건이 목표 생산 시스템에서 기술적으로나 경제적으로 실현 가능한지 구체적으로 확인하지는 못합니다.

PSDL

PSDL은 실시간 소프트웨어를 ^[19]기술하기 위한 프로토타입 기술 언어입니다.관련 도구 세트는 CAPS(컴퓨터 지원 프로토타이핑 시스템)^[20]입니다.타이밍 제약으로 인해 구현 및 하드웨어 의존성이 발생하기 때문에 실시간 요구사항이 까다로운 소프트웨어 시스템을 프로토타입으로 제작하는 것은 어렵습니다.PSDL은 선언적 타이밍 제약을 포함하는 제어 추상화를 도입함으로써 이러한 문제에 대처합니다.CAPS는 이 정보를 사용하여 코드 및 관련 실시간스케줄을 자동으로 생성하고 프로토타입 실행 중 타이밍 제약조건을 감시하며 파라미터화된 하드웨어 모델 세트와 관련된 비례적인 실시간 실행을 시뮬레이션합니다.또한 불완전한 프로토타입 설명의 실행을 가능하게 하는 기본 가정을 제공하고, 효율적인 구현을 신속하게 실현하기 위해 소프트웨어 재사용 저장소와 프로토타입 구축을 통합하며, 요구사항 및 ^[21]설계의 신속한 진화를 지원합니다.

레퍼런스