반복 설계

Iterative design

반복 설계는 제품 또는 공정을 프로토타이핑, 테스트, 분석 및 정제하는 주기적 프로세스를 기반으로 하는 설계 방법론입니다.설계의 최신 반복 테스트 결과를 기반으로 변경 및 개선 작업이 이루어집니다.이 과정은 궁극적으로 설계의 품질과 기능을 개선하기 위한 것입니다.반복 설계에서 설계 시스템과의 상호작용은 후속 버전 또는 설계의 반복이 구현될 때 프로젝트에 대한 정보 및 진화를 위한 연구 형태로서 사용된다.

역사

반복 설계는 공학 분야에서 오랫동안 사용되어 왔습니다.한 가지 예는 1960년대에 시행된 계획-실행-체크-액트 주기이다.대부분의 신제품 개발 또는 기존 제품 개선 프로그램에는 반복적인 목적으로 사용되는 체크 루프가 있습니다.DMAIC는 Six Sigma 프레임워크를 사용하며 이러한 체크 기능을 가지고 있습니다.

객체 지향 프로그래밍

반복적인 디자인은 객체 지향 프로그래밍의 실천과 연결되어 있으며,[1] 이 문구는 1990년에 컴퓨터 과학 문헌에 등장했습니다.이 아이디어는 배리 [2]보엠이 고안한 나선형 개발에 뿌리를 두고 있다.

반복 설계 프로세스

반복적인 설계 프로세스는 신제품 개발 프로세스 전체에 적용될 수 있습니다.그러나 변경은 개발 초기 단계에서 구현하기 쉽고 비용도 저렴합니다.반복 설계 프로세스의 첫 번째 단계는 프로토타입을 개발하는 것입니다.시제품은 편향되지 않은 의견을 전달하기 위해 포커스 그룹 또는 제품과 관련되지 않은 그룹에 의해 평가되어야 한다.포커스 그룹의 정보는 통합되고 설계의 다음 반복에 통합되어야 한다.사용자 문제가 허용 가능한 수준으로 줄어들 때까지 이 프로세스를 반복해야 합니다.

응용 프로그램:휴먼 컴퓨터 인터페이스

반복 설계는 인간 컴퓨터 인터페이스 개발에 일반적으로 사용됩니다.이를 통해 설계자는 사용자 인터페이스가 널리 사용되기 전에 사용자 인터페이스에서 발생할 수 있는 사용성 문제를 식별할 수 있습니다.최고의 사용적합성 전문가도 한 번의 시도만으로 완벽한 사용자 인터페이스를 설계할 수 없기 때문에 [3]반복이라는 개념을 바탕으로 사용적합성 엔지니어링 라이프사이클을 구축해야 합니다.

사용자 인터페이스에서 반복 설계의 일반적인 단계는 다음과 같습니다.

  1. 초기 인터페이스 설계 완료
  2. 여러 테스트 사용자에게 설계를 제시하다
  3. 테스트 유저에 의한 문제를 적어 둡니다.
  4. 문제를 설명/수정하기 위한 인터페이스 개선
  5. 사용자 인터페이스의 문제가 해결될 때까지 순서 2~4를 반복합니다.

사용자 인터페이스의 반복 설계는 다양한 방법으로 구현될 수 있습니다.컴퓨터 소프트웨어에서 반복 설계를 사용하는 일반적인 방법 중 하나는 소프트웨어 테스트입니다.여기에는 사용자 인터페이스 이외의 기능에 대한 제품 테스트도 포함되지만, 인터페이스에 대한 중요한 피드백은 프로그램의 초기 버전을 테스트하는 것으로 얻을 수 있습니다.이를 통해 소프트웨어 회사는 더 나은 품질의 제품을 일반에 출시할 수 있으며 출시 후 제품 수정이 필요하지 않습니다.

온라인(웹 사이트) 인터페이스에서의 반복 설계는 사용자에게 공개된 후 웹 사이트 변경이 소프트웨어 설계보다 훨씬 더 실행 가능하기 때문에 보다 지속적인 프로세스입니다.웹 사이트에서는 종종 사용자를 인터페이스 설계의 테스트 대상으로 사용하여 사이트에 대한 방문자의 권장 사항에 따라 수정합니다.

반복 설계 사용

반복적인 디자인은 설계의 전면적이고 근본적인 변화를 초래할 수 있는 예측할 수 없는 사용자의 요구와 행동의 현실에 맞서는 방법입니다.사용자 테스트에서는 신중하게 평가된 아이디어도 사용자 테스트에 직면했을 때 불충분하다는 것을 알 수 있습니다.따라서, 반복 설계의 구현 접근법의 유연성이 가능한 한 시스템으로 확장되는 것이 중요하다.설계자는 사용자 테스트 결과가 설계자가 오래된 아이디어를 완전히 버리고 사용자의 요구에 더 적합한 새로운 아이디어를 위해 준비해야 하는 근본적인 변화를 제시할 수 있다는 점을 더욱 인식해야 합니다.반복적인 디자인은 칼을 만드는 것부터 로켓에 이르기까지 다양한 분야에 적용된다.예를 들어 특정 작업을 수행해야 하며 최종적으로 회로 기판의 좁은 공간에 설치되어야 하는 전자회로의 설계를 고려합니다.이러한 독립 태스크는 기능 태스크와 공간 및 중량 태스크의 두 가지 작고 단순한 태스크로 분할하면 유용합니다.브레드보드는 공간과 무게를 걱정할 필요 없이 전자회로를 임시로 구현하는 유용한 방법입니다.

회로가 작동하면 브레드보드에 개선 또는 증분 변경을 적용하여 원래 설계보다 기능을 높이거나 개선할 수 있습니다.설계가 완료되면 공간 및 중량 기준에 맞는 적절한 회로 기판을 설계할 수 있다.회로 기판의 회로를 압축하려면 와이어와 컴포넌트의 전기적 특성을 변경하지 않고 교묘하게 조정해야 합니다.이 저글링은 회로 자체의 설계보다 단순한 규칙을 따르며, 많은 경우 자동화됩니다.가능한 한 기성 컴포넌트를 사용하지만 공간이나 성능상의 이유로 필요한 경우 맞춤형 컴포넌트를 개발할 수 있습니다.

반복 설계의 몇 가지 예는 다음과 같습니다.

  • Wiki: Wiki는 반복 설계를 위한 자연스러운 저장소입니다.'페이지 이력' 기능을 통해 이전 버전으로 추적할 수 있습니다.수정은 대부분 증분이며 텍스트의 상당 부분은 변경되지 않습니다.
  • 커먼 로:법률 판례의 원칙은 과거의 경험에 기초한다.따라서 법률은 법률적 사고의 발전에 대한 명확한 감사 흔적이 있어야 하는 반복적 설계의 한 형태가 됩니다.
  • 진화:자연선택의 반복과 이론 사이에는 유사점이 있다.둘 다 가장 적합한 설계가 다음 세대로 발전하는 시행착오 과정을 수반하지만 적합하지 않은 설계는 도중에 소멸됩니다.제품의 후속 버전도 생산자가 개선 및 지속적인 개선 과정에서 어떤 것이 효과가 있고 어떤 것이 효과가 없는지를 알게 되면 점차적으로 개선될 것입니다.

빠른 프로토타이핑 도구

반복 설계에 대한 한 가지 접근법은 초기 세대 제품을 개발하기 위해 최고 수준의 추상화를 사용하는 것입니다.여기서의 원칙은 급속한 개발이 효율적인 코드를 생성하지 못할 수 있지만, 기술의 최적화보다 피드백을 얻는 것이 더 중요하다는 것입니다.이 접근방식의 예로는 기능하지 않는 코드, 오브젝트 데이터베이스, 저코드 플랫폼 등의 사용을 들 수 있습니다.이를 통해 최적화 문제가 해결되기 전에 설계를 신속하게 테스트할 수 있습니다.

혜택들

적절하게 적용되면 반복 설계를 통해 제품 또는 프로세스가 가능한 최고의 솔루션임을 보장할 수 있습니다.개발 초기에 적용하면 비용을 크게 절감할 [4]수 있습니다.

반복 설계의 다른 이점은 다음과 같습니다.

  1. 심각한 오해는 라이프 사이클의 초기에 나타나며, 그 오해에 대응할 수 있게 됩니다.
  2. 시스템의 실제 요구사항을 도출하기 위해 사용자 피드백을 활성화하고 장려합니다.
  3. 작업이 계약되어 있는 경우, 반복 설계는 설계 프로세스를 둘러싼 복잡성에 클라이언트를 보다 효과적으로 참여시키기 위한 증분 방법을 제공합니다.
  4. 개발팀은 프로젝트에 가장 중요한 문제에 집중해야 하며, 팀원들은 프로젝트의 실제 위험으로부터 주의를 분산시키고 주의를 딴 데로 돌리게 하는 문제로부터 보호받아야 합니다.
  5. 지속적인 테스트를 통해 프로젝트 상태를 객관적으로 평가할 수 있습니다.
  6. 요건, 설계 및 구현 간의 불일치는 조기에 발견됩니다.
  7. 팀, 특히 테스트 팀의 워크로드는 라이프 사이클 전체에 걸쳐 보다 균등하게 분산됩니다.
  8. 이 접근방식을 통해 팀은 학습한 교훈을 활용하여 프로세스를 지속적으로 개선할 수 있습니다.
  9. 프로젝트의 이해관계자에게는 라이프 사이클 전체에 걸친 프로젝트 상태에 대한 구체적인 증거를 제공할 수 있습니다.

마시멜로 챌린지

마시멜로 우승작에 도전합니다.

마시멜로 챌린지는 유익한 디자인 과제입니다.그것은 마시멜로를 꼭대기에 두고 가능한 한 가장 높은 자립형 구조물을 건설하는 작업을 수반한다.구조물은 스파게티 20개, 테이프 1야드, 끈 [5][6]1야드만 사용하여 18분 이내에 완성되어야 한다.

참가자에 대한 관찰과 연구에 따르면 유치원생들은 경영대학원 졸업자 그룹에 비해 정기적으로 더 높은 건물을 지을 수 있다.이것은 아이들이 마시멜로를 단번에 단순한 구조물 위에 붙이고, 시제품을 시험하고, 그것을 계속 개선하려는 경향으로 설명된다.반면 비즈니스 스쿨 학생들은 권력을 놓고 경쟁하고, 계획을 세우고, 최종적으로 마시멜로를 [7]추가하는 구조를 만드는 데 시간을 보내는 경향이 있습니다.이 과제는 시제품 제작, 팀워크, 리더십 및 혁신 기술을 구축하고 개발하는 데 도움이 되며, 인기 있는 STEM 활동입니다.Palm, Inc.의 Peter Skillman이 고안하고 오토데스크의 [8][9][10][11][12]Tom Wujec이 대중화했습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Gossain, Sanjiv; Anderson, Bruce (1990). "An iterative-design model for reusable object-oriented software". Proceedings of the European conference on object-oriented programming on Object-oriented programming systems, languages, and applications - OOPSLA/ECOOP '90. pp. 12–27. doi:10.1145/97945.97949. ISBN 0-89791-411-2. S2CID 551413.
  2. ^ "Summary of Spiral Model" (PDF).
  3. ^ Nielsen, J. (1993). "Iterative User Interface Design". IEEE Computer. 26 (11): 32–41. doi:10.1109/2.241424. S2CID 17748574.
  4. ^ Mantei, Marilyn M.; Teorey, Toby J. (1988). "Cost/Benefit analysis for incorporating human factors in the software lifecycle". Communications of the ACM. 31 (4): 428–439. doi:10.1145/42404.42408. S2CID 2031965.
  5. ^ "The Marshmallow Challenge". The Marshmallow Challenge. Retrieved 2010-08-10.
  6. ^ "The Marshmallow Challenge". CA: BPWrap. 2010-04-22. Retrieved 2010-08-10.
  7. ^ Jerz, Dennis G. (2010-05-10). "The Marshmallow Challenge - Jerz's Literacy Weblog". Jerz.setonhill.edu. Retrieved 2010-08-10.
  8. ^ Cameron, Chris (2010-04-23). "Marshmallows and Spaghetti: How Kindergartners Think Like Lean Startups". Readwriteweb.com. Archived from the original on 2010-08-21. Retrieved 2010-08-10.
  9. ^ "The Marshmallow Challenge". Engineeringrevision.com. 2010-05-02. Retrieved 2013-08-10.
  10. ^ "The Marshmallow Challenge". Selfish Programming. Retrieved 2013-08-10.
  11. ^ "Marshmallow challenge Faculty of Science University of Calgary". Ucalgary.ca. 2010-12-13. Retrieved 2013-08-10.
  12. ^ Original Design Challenge (2014-01-27), Peter Skillman Marshmallow Design Challenge, archived from the original on 2021-12-13, retrieved 2017-09-12
  • Boehm, Barry W.(1988년 5월), "소프트웨어 개발과 확장의 나선형 모델", Computer, IEEE, 페이지 61-72.
  • Gould, J.D.와 Lewis, C.(1985년).사용 편의성을 고려한 설계:주요 원칙과 설계자가 생각하는 것, ACM의 커뮤니케이션, 3월 28일(3), 300~311일.
  • 크루치텐, 필립합리적인 통합 프로세스: 개요
  • Kruchten, P. (2000). "From Waterfall to Iterative Development – A Challenging Transition for Project Managers" (PDF) (White paper). Rational Software Corporation. Retrieved 2019-08-17. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)

외부 링크