진화론 대 던지는 프로토 타이핑 [폐쇄

Question

"낮은 대 충실도 프로토 타이핑"토론에서 누가 승리하고 있습니까? 프로토 타입 제로 (P0)가 최종 제품의 첫 번째 버전이어야합니까? 아니면 항상 P-0이어야합니까? 업계는 어떤 접근 방식이 선호됩니까?

Wikipedia의 탁월한 기사 : 소프트웨어 프로토 타이핑

Answer 1

프로토 타입은 항상 버려야합니다. 프로토 타입은 개념을 신속하게 증명하고 실제 제품의 디자인에 영향을 미치는 데 사용됩니다. 따라서 실제 제품 (생각 아웃 아키텍처 및 디자인, 신뢰성, 보안, 유지 가능성 등)에 중요한 많은 것들이 길가에 따라 떨어집니다. 프로토 타입을 만들 때 이러한 것들을 고려하면 더 이상 프로토 타입을 구축하지 않습니다.

코드가 실제 제품으로 직접 진화 한 프로토 타입에 대한 나의 경험에 따르면, 엔드-레지 ult가 그로 인해 고통을 겪고 있음을 보여줍니다. 실제 아키텍처가 없기 때문에 새로운 기능을 추가하기 위해 끊임없이 해킹 해야하는 많은 양의 자갈과 같은 코드가 생겼습니다. 프로토 타입의 빠른 개발을 위해 선택된 원래 기술이 실제 제품에 가장 적합한 선택이 아니며 V2에 완전한 재 작성이 필요했습니다.

Answer 2

프로토 타입을 작성한 다음 제품이 될 때까지 리팩토링을 계속하십시오. 열쇠는 필요할 때 주저하지 않는 것입니다.

처음에는 거의 일하는 사람이 거의 없습니다. 너무 많은 사람들이 무언가를 작업하면 리팩토링이 더 어려워집니다.

Answer 3

우리는 Pedants 가이 특별한 전투를 잃어버린 것 같아요. "프로토 타입"( 정의에 따라 처음부터 다시 작성해야합니다 !!!-)는 실제로 (종종 반 구운 "베타스")로 "진화"되고 있습니다.

오늘도, 나는 내 동료의 스마트 시도에 박수를 보냈습니다. 개념,이 용어가 잃어버린 전투 인 경우에도 : 그는 방법을 설정하고 있습니다. 개념의 증거 소규모 프로젝트를 개발하고 개념이 입증되면 실제 프로토 타이핑을 위해 소프트웨어 엔지니어에게 전학 한 다음 개발).

아이디어는 우리 부서에는 그렇지 않은 많은 사람들이 있다는 것입니다. 추정된 소프트웨어 개발자이지만 매우 똑똑하고 컴퓨터에 정통하며 현실과 매일 "트렌치"와 접촉합니다. 그들 한때 "생산 준비"소프트웨어 프로젝트로 구현 된 실질적인 영향을 미칠 수있는 잠재적 혁신의 기회를 냄새 맡을 가능성이 가장 높은 사람들입니다. 영업 사원, 계정 관리자, 비즈니스 분석가, 기술 관리자 - 회사에서는 모두이 설명에 적합합니다.

그러나 그들은 C ++, Java, 아마도 파이썬에서는 거의 "생산"에서 멀리 떨어져 있지 않을 것입니다. 실제로 PHP, JavaScript, Perl에서 현명한 개념 증명을 채울 가능성이 훨씬 높습니다. , Bash, Excel+VBA 및 Sundry 기타 "빠르고 더러운"기술이 원하지 않는 기술 꿈 영원히 생산 및 지원에 대해!-)

따라서 프로토 타입을 "개념의 증거"라고 부름으로써, 우리는 그들에게 대담한 개념을 구체적인 형태로 구현하도록 격려하기를 희망합니다 (모호한 자연 언어 휘발과 손을 많이 흔들며 회사의 문화에 외계인 ;-). 그러나 그러한 프로젝트는 소프트웨어 엔지니어의 목표와 우선 순위 중에 존재하도록 촉진된다면 처음부터 프로그래밍해야한다는 점을 선명하게 나타냅니다. 엔지니어들은 분명히 점진적으로 풍부하지는 않지만 뿌리 위로에서 재정의를 목표로하고 있습니다!-).

이 아이디어가 얼마나 잘 작동하는지 말하기는 일찍입니다. 3 개월 후에 분기의 노력을 평가할 때 3 개월 후에 저에게 물어봐 마지막 분기의 부서 및 회사 별 사업!-).

Answer 4

Bundallah, Hamisi의 응답

프로토 타입은 일반적으로 최종 프로그램의 기능의 몇 가지 측면 만 시뮬레이션하며 최종 구현과 완전히 다를 수 있습니다. 내 다른 동료들이 위에서 제안한 것과는 달리, 나는 상사에게 던져 버리는 프로토 타입 모델을 선택하도록 조언하지 않을 것입니다. 나는 이것에 대해 Anita와 함께 있습니다. 두 개의 프로토 타입 모델과 제공된 상황을 감안할 때, 나는 경영진 (내 상사)에게 진화 프로토 타입 모델을 선택하도록 강력히 권고 할 것입니다. 회사는 코드의 복잡성, 사용될 프로그래밍 언어의 새로운 기능과 같은 다른 모든 변수에 크게 크고, Throw Away 프로토 타입 모델을 사용하지 않을 것입니다. Throw Away 프로토 타입 모델은 사용자가 기대치를 재검토하고 요구 사항을 명확하게 할 수있는 출발점이됩니다. 이것이 달성되면 프로토 타입 모델이 '버려지고'시스템은 식별 된 요구 사항에 따라 공식적으로 개발됩니다 (Crinnion, 1991). 그러나 이러한 상황에서는 사용자 가이 특정 상황에서 주어진 요인의 복잡성으로 인해 한 번에 모든 요구 사항을 알지 못할 수 있습니다. 진화론 적 프로토 타이핑은 점진적인 개선 과정에 의해 컴퓨터 시스템을 개발하는 과정입니다. 시스템의 각 정제에는 시스템 사양 및 소프트웨어 개발 단계가 포함됩니다. 전통적인 폭포 접근과 증분 프로토 타이핑과 달리,이 접근 방식이 처음으로 모든 것을 올바르게 얻을 수 있어야했기 때문에 참가자는 이전주기에서 배운 교훈을 반영 할 수있었습니다. 점진적으로 정제 된 세 가지주기를 거치는 것이 일반적입니다. 그러나 지속적인 진화 과정을 막는 것은 아무것도 없으며, 이는 종종 많은 시스템에서 발생합니다. Davis (1992)에 따르면, 진화론 적 프로토 타이핑은 우리가 모든 요구 사항을 이해하지 못한다는 것을 인정합니다 (위에서 시스템이 복잡하고 회사가 크고 코드가 복잡하며 언어가 상당히 새롭다는 말을 들었습니다. 프로그래밍 팀). 진화론 적 프로토 타이핑을 사용할 때의 주요 목표는 구조화 된 방식으로 매우 강력한 프로토 타입을 구축하고 지속적으로 개선하는 것입니다. 그 이유는 진화론 적 프로토 타입이 구축 될 때 새로운 시스템의 핵심을 형성하고 개선 및 추가 요구 사항이 구축되기 때문입니다. 이 기술을 통해 개발 팀은 요구 사항 및 설계 단계에서 고안 할 수없는 기능을 추가하거나 변경할 수 있습니다. 시스템이 유용하기 위해서는 의도 된 운영 환경에서 사용을 통해 진화해야합니다. 제품은 결코 "완료"되지 않습니다. 사용 환경이 바뀌면서 항상 성숙합니다. 개발자는 종종 가장 친숙한 참조 프레임 (현재 현재 시스템 상태)을 사용하여 시스템을 정의하려고합니다. 그들은 비즈니스 수행 방식과 비즈니스가 구현 될 기술 기반에 대해 가정합니다. 기능을 개발하기위한 계획이 제정되었으며 조만간 구상 된 시스템과 비슷한 것이 전달됩니다. (SPC, 1997). 진화론 적 프로토 타입은 기능 시스템이라는 점에서 버거리 프로토 타입보다 이점이 있습니다. 사용자가 계획 한 모든 기능이 없을 수도 있지만 최종 시스템이 전달 될 때까지 중간에 사용될 수 있습니다. 진화론 적 프로토 타이핑에서 개발자는 전체 시스템을 개발하는 대신 이해하는 시스템의 일부를 개발하는 데 집중할 수 있습니다. 위험을 최소화하기 위해 개발자는 잘 이해되지 않은 기능을 구현하지 않습니다. 부분 시스템은 고객 사이트로 전송됩니다. 사용자가 시스템과 협력함에 따라 새로운 기능에 대한 기회를 감지하고 개발자에게 이러한 기능에 대한 요청을 제공합니다. 그런 다음 개발자는 이러한 향상된 요청을 자체적으로 가져 와서 사운드 구성 관리 관행을 사용하여 소프트웨어보고 사양을 변경하고 설계를 업데이트하고 재조정 및 재시험합니다. (Bersoff and Davis, 1991). 그러나 진화론 적 프로토 타이핑의 주요 문제는 관리가 열악한 것입니다. 정의 된 이정표 부족, 성취 부족 - 항상 다음 프로토 타입까지의 프로토 타입, 적절한 평가 부족, 프로토 타입의 명확성 부족 및 구현 된 시스템, 사용자의 지속적인 헌신 부족. 이 프로세스는 전통적으로 요구하는 것보다 더 긴 시간 동안 사용자의 지속적인 헌신을 더 많이 필요로합니다. 사용자는 무슨 일이 일어나고 있는지에 대해 지속적으로 알리고 '프로토 타입'의 기대를 완전히 알고 있어야합니다.

참조

Bersoff, E., Davis, A. (1991). 소프트웨어 구성 관리의 수명주기 모델의 영향. 통신. ACM.

Crinnion, J. (1991). 진화 시스템 개발, 구조화 된 시스템 방법론 내에서 프로토 타이핑 사용에 대한 실질적인 안내서. Plenum Press, 뉴욕.

Davis, A. (1992). 운영 프로토 타이핑 : 새로운 개발 접근법. IEEE 소프트웨어.

소프트웨어 생산성 컨소시엄 (SPC). (1997). 진화 적 빠른 발전. SPC 문서 SPC-97057-CMC, 버전 01.00.04.