신속한 응용 프로그램 개발

Rapid application development
여기서 "RAD 툴" 및 "Rapid Application Development Tool"을 수정합니다.그래피컬 유저 인터페이스 작성에 초점을 맞춘 개발에 대해서는, 그래피컬 유저 인터페이스 빌더를 참조해 주세요.
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

RAD(Rapid Application Building)는 적응형 소프트웨어 개발 접근방식의 일반적인 용어이자 James Martin의 신속한 개발 방법의 명칭이기도 합니다.일반적으로 소프트웨어 개발에 대한 RAD 접근법은 계획보다는 적응형 프로세스에 중점을 둡니다.프로토타입은 종종 설계 사양에 추가되거나 설계 사양 대신 사용됩니다.

RAD는 특히 사용자 인터페이스 요건에 의해 구동되는 소프트웨어 개발에 적합합니다(단, 이에 한정되는 것은 아닙니다).그래픽 사용자 인터페이스 빌더는 종종 신속한 애플리케이션 개발 도구라고 불립니다.신속한 개발을 위한 다른 접근 방식으로는 적응형, 민첩성, 나선형 및 통합 모델이 있습니다.

역사

신속한 애플리케이션 개발은 1970년대와 1980년대에 개발된 구조화 시스템 분석 및 설계 방법(SSADM)과 같은 계획 중심의 워터폴 프로세스에 대한 대응이었습니다.이 방법의 문제점 중 하나는 교량이나 건물 등의 설계 및 구축에 사용되는 기존의 엔지니어링 모델을 기반으로 한다는 것입니다.소프트웨어는 본질적으로 다른 종류의 인공물이다.소프트웨어는 문제 해결에 사용되는 전체 프로세스를 근본적으로 바꿀 수 있습니다.그 결과 개발 프로세스 자체에서 얻은 지식은 솔루션의 [1]요건과 설계에 반영될 수 있습니다.계획 중심 접근 방식은 요구사항, 솔루션 및 구현 계획을 엄격하게 정의하고 변화를 방해하는 프로세스를 갖습니다.한편, RAD의 어프로치는, 소프트웨어 개발이 지식 집약적인 프로세스인 것을 인식하고, 프로젝트중에 습득한 지식을 활용해 솔루션을 개선하거나 적응시키는 유연한 프로세스를 제공합니다.

그러한 최초의 RAD 대안은 Barry Boehm에 의해 개발되었으며 나선형으로 알려져 있다.Boehm 및 기타 후속 RAD 접근 방식은 엄격한 설계 사양 대신 프로토타입 개발을 강조했습니다.프로토타입은 기존 사양에 비해 다음과 같은 몇 가지 이점이 있었습니다.

  • 리스크 경감프로토타입은 시스템의 가장 어려운 잠재적 부품 중 일부를 수명 주기 초기에 테스트할 수 있습니다.이를 통해 설계의 실현 가능성에 관한 귀중한 정보를 얻을 수 있으며, 팀이 구현하기에 너무 복잡하고 시간이 많이 걸리는 솔루션을 추구하는 것을 방지할 수 있습니다.라이프 사이클에서 문제를 나중에가 아니라 조기에 발견하는 이점이 RAD 접근법의 핵심 이점이었다.문제를 조기에 발견할수록 대처 비용이 저렴해집니다.
  • 사용자는 사양 작성보다 사용 및 대응에 더 능숙합니다.워터폴 모델에서는 사용자가 일련의 요건을 승인하는 것이 일반적이지만, 구현된 시스템을 제시하면 특정 설계에 중요한 기능이 없거나 너무 복잡하다는 것을 갑자기 깨닫게 됩니다.일반적으로 대부분의 사용자는 실행 중인 시스템의 프로토타입을 경험할 수 있을 때 시스템이 무엇인지 추상적으로 정의하기 보다는 훨씬 더 유용한 피드백을 제공합니다.
  • 프로토타입을 사용할 수 있고 완성된 제품으로 진화할 수 있습니다.일부 RAD 방법에 사용된 한 가지 접근방식은 시스템을 최소 기능에서 최종 완성된 시스템에 중간 정도 유용한 시제품으로 구축하는 것이었습니다.위의 두 가지 장점 외에 이 장점은 사용자가 프로세스 [2]초기에 유용한 비즈니스 기능을 얻을 수 있다는 것입니다.

James Martin은 Barry Boehm 등의 아이디어를 시작으로 1980년대 IBM에서 신속한 애플리케이션 개발 방식을 개발했으며 1991년 Rapid Application Development라는 책을 출판하여 이를 공식화했습니다.이로 인해 IT 전문가들 사이에서도 RAD라는 용어에 대한 혼란이 발생하고 있습니다.폭포 모델의 일반적인 대안으로서의 RAD와 마틴이 개발한 특정 방법으로서의 RAD를 구별하는 것이 중요하다.Martin 방식은 지식 집약적인 비즈니스 시스템과 UI 집약적인 비즈니스 시스템에 맞게 조정되었습니다.

이러한 아이디어는 James Ker와 Richard Hunter와 같은 RAD 선구자들에 의해 더욱 발전되고 개선되었으며, 그는 이 주제에 대한 중요한 책인 Inside [3]RAD를 함께 집필했습니다. Inside RAD는 실제 RAD 프로젝트에서 RAD 방법론을 실시간으로 운전하고 개선했습니다.이러한 실무자 및 그와 같은 실무자들은 RAD가 기존의 시스템 프로젝트 수명 주기 접근법에 대한 대안으로 인기를 얻는 데 도움을 주었습니다.

RAD 접근방식은 비즈니스 재구축에 대한 관심이 최고조에 달한 시기에도 성숙했습니다.비즈니스 프로세스 재엔지니어링의 개념은 IT의 새로운 기능을 염두에 두고 영업 및 고객 지원과 같은 핵심 비즈니스 프로세스를 근본적으로 재고하는 것이었습니다.RAD는 종종 대규모 비즈니스 리엔지니어링 프로그램에서 필수적인 부분이었습니다.RAD의 신속한 프로토타이핑 접근법은 사용자와 분석가가 핵심 비즈니스 프로세스를 [4][5]획기적으로 재창조할 수 있는 혁신적인 방법에 대해 "즉각적으로 생각할 수 있도록" 지원하는 핵심 도구였습니다.[6]

James Martin이 RAD에 만족한 것은 Dupont의 정보 엔지니어링 부문과 그 리더 Scott Schultz, 그리고 호주와 홍콩에서 많은 성공적인 RAD 프로젝트를 개척한 맞춤형 RAD 개발 회사를 이끌었던 John Underwood와의 관계에서 비롯되었습니다.

ANZ은행, 대여리스, BHP, 코카콜라아마틸, 알칸, 홍콩자키클럽 등 성공 프로젝트

Scott Shultz와 James Martin은 모두 John Underwood와 함께 호주에서 중요한 미션 크리티컬 RAD 프로젝트 구현에 성공했던 방법과 세부 사항을 이해하게 되었습니다.

James Martin RAD 방식

RAD에 대한 James Martin 접근 단계

RAD에 대한 James Martin 접근법은 프로세스를 4가지 단계로 나눕니다.

  1. 요건 계획 단계– 시스템 개발 라이프 사이클(SDLC)의 시스템 계획 및 시스템 분석 단계 요소를 결합합니다.사용자, 관리자 및 IT 직원은 비즈니스 요구, 프로젝트 범위, 제약 및 시스템 요구사항에 대해 논의하고 이에 동의합니다.팀이 주요 이슈에 대해 합의하고 경영진의 승인을 얻으면 계속 진행됩니다.
  2. 사용자 설계 단계 – 이 단계에서 사용자는 시스템 분석가와 상호 작용하여 모든 시스템 프로세스, 입력 및 출력을 나타내는 모델 및 프로토타입을 개발합니다.RAD 그룹 또는 하위 그룹은 일반적으로 공동 애플리케이션 설계(JAD) 기법과 CASE 도구를 결합하여 사용자의 요구를 작업 모델로 변환합니다.사용자 설계는 사용자가 자신의 요구를 충족하는 시스템의 작업 모델을 이해, 변경 및 최종 승인할 수 있도록 하는 연속적인 대화형 프로세스입니다.
  3. 구축 단계 – SDLC와 유사한 프로그램 및 애플리케이션 개발 태스크에 초점을 맞춥니다.그러나 RAD에서는 사용자가 계속 참여하며 실제 화면이나 보고서가 개발될 때 변경이나 개선을 제안할 수 있습니다.이 회사의 업무는 프로그래밍 및 애플리케이션 개발, 코딩, 유닛 통합 및 시스템 테스트입니다.
  4. 컷오버 단계– 데이터 변환, 테스트, 새로운 시스템으로의 전환, 사용자 트레이닝 등 SDLC 구현 단계의 최종 태스크와 유사합니다.기존 방법에 비해 전체 프로세스가 압축되어 있습니다.그 결과, 새로운 시스템이 구축, 제공 및 가동되는 시간이 [7]훨씬 단축됩니다.

이점

현대 정보기술 환경에서는 많은 시스템이 어느 정도의 신속한 애플리케이션 개발을[8] 사용하여 구축되고 있습니다(James Martin 접근 방식일 필요는 없습니다.RAD 개발에는 Martin의 방법 외에 신속한 변화를 위한 방법과 Rational Unified Process가 자주 사용됩니다.

RAD의 장점은 다음과 같습니다.

  • 품질이 향상되었습니다.사용자가 진화하는 프로토타입과 상호 작용하도록 함으로써 RAD 프로젝트의 비즈니스 기능은 종종 폭포수 모델을 통해 달성되는 것보다 훨씬 더 높아질 수 있습니다.소프트웨어의 사용성이 향상되어 개발자가 관심을 가지는 기술적인 문제보다 최종 사용자에게 중요한 비즈니스 문제에 집중할 수 있는 기회가 많아집니다.단, 이것은 보안 및 휴대성을 포함하여 통상 비기능적 요건(AKA 제약사항 또는 품질 속성)으로 알려진 다른 카테고리는 제외합니다.
  • 리스크 컨트롤RAD에 관한 문헌의 대부분은 속도와 사용자의 개입에 초점을 맞추고 있지만, 올바르게 이루어지는 RAD의 중요한 특징은 위험 완화이다.Boehm은 처음에 Spiral 모델을 위험 기반 접근법으로 특징지었습니다.RAD 접근방식은 핵심 위험 요소에 초기에 초점을 맞추고 프로세스의 초기 부분에서 수집된 경험적 증거에 기초하여 조정될 수 있다.예를 들어, 시스템의 가장 복잡한 부분 중 일부를 프로토타입으로 제작하는 복잡성입니다.
  • 더 많은 프로젝트가 예산 범위 내에서 제시간에 완료됩니다.증분 유닛의 개발에 집중함으로써 대형 폭포 프로젝트에 시달리던 치명적인 실패의 가능성을 줄일 수 있습니다.워터폴 모델에서는 6개월 이상의 분석과 개발 끝에 시스템 전체를 근본적으로 재고해야 하는 것이 일반적이었습니다.RAD를 사용하면 프로세스 [2][9]초기에 이러한 종류의 정보를 발견하고 처리할 수 있습니다.

단점들

RAD의 단점은 다음과 같습니다.

  • 새로운 접근법의 리스크.대부분의 IT 숍에서 RAD는 경험이 풍부한 전문가가 작업 방식을 재고해야 하는 새로운 접근 방식이었습니다.인간은 거의 항상 변화를 싫어하며, 새로운 도구나 방법을 사용하여 수행되는 프로젝트는 단순히 팀의 학습 요건 때문에 처음 실패하는 경우가 더 많습니다.
  • 통상적인 조작에서는 최종 사용자가 인식할 수 없는 기능 이외의 요건을 중시하지 않는다.
  • 자원이 부족한 시간이 필요합니다.RAD에 대한 거의 모든 접근방식의 공통점은 사용자와 개발자 간의 전체 라이프사이클에서 훨씬 더 많은 상호작용이 이루어진다는 것입니다.워터폴 모델에서 사용자는 요건을 정의하고 개발자가 시스템을 만들 때 대부분 사라집니다.RAD에서는 사용자가 처음부터 프로젝트 전체에 관여합니다.따라서 기업은 애플리케이션 도메인 전문가의 시간을 기꺼이 투자해야 합니다.역설적인 것은 전문가가 전문 분야에 정통할수록 실제로 비즈니스를 운영할 필요가 많아지고 상사에게 시간을 투자하도록 설득하는 것이 어려울 수 있다는 것입니다.그러한 약속 없이는 RAD 프로젝트는 성공하지 못할 것이다.
  • 통제가 약하다.RAD의 장점 중 하나는 유연한 적응 프로세스를 제공한다는 것입니다.이상적으로는 문제와 기회 모두에 빠르게 적응할 수 있어야 합니다.유연성과 통제 사이에는 필연적인 트레이드오프가 존재하며, 둘 중 하나가 다른 하나를 덜 의미합니다.프로젝트(예: 생명에 중요한 소프트웨어)의 가치가 민첩성 이상의 제어를 하는 경우 RAD는 적절하지 않습니다.
  • 디자인이 서투르다.일부 경우 프로토타입에 너무 집중하면 개발자가 개별 구성요소에 대해 지속적으로 사소한 변경을 가하고 시스템 아키텍처 문제를 무시하여 전체 설계를 개선할 수 있는 "핵 앤 테스트" 방법론이 발생할 수 있습니다.이는 특히 [10]마틴과 같은 방법론에서 시스템의 사용자 인터페이스에 매우 중점을 두고 있는 경우 문제가 될 수 있습니다.
  • 확장성의 결여되어 있다.RAD는 보통 중소규모 프로젝트 팀에 초점을 맞추고 있습니다.위에 언급된 다른 문제들(설계와 제어가 적음)은 매우 큰 [11][12][13]규모의 시스템에 RAD 접근방식을 사용할 때 특별한 문제를 제기한다.

「 」를 참조해 주세요.

RAD를 구현하기 위한 실용적인 개념:

기타 유사한 개념:

레퍼런스

  1. ^ Brooks, Fred (1986). Kugler, H.J. (ed.). No Silver Bullet Essence and Accidents of Software Engineering (PDF). Information Processing '86. Elsevier Science Publishers B.V (North-Holland). ISBN 0-444-70077-3. Retrieved 2 July 2014.
  2. ^ a b Boehm, Barry (May 1988). "A Spiral Model of Software Development" (PDF). IEEE Computer. doi:10.1109/2.59. S2CID 1781829. Archived from the original (PDF) on 29 March 2018. Retrieved 1 July 2014.
  3. ^ 커, 제임스 M. 헌터, 리처드(1993)내부 RAD: 90일 이내에 완전히 기능하는 시스템을 구축하는 방법.맥그로 힐.ISBN 0-07-034223-7.
  4. ^ Drucker, Peter (3 November 2009). Post-Capitalist Society. Harper Collins e-books. ISBN 978-0887306204.
  5. ^ Martin, James (1991). Rapid Application Development. Macmillan. ISBN 0-02-376775-8.
  6. ^ https://www.technobuz.tech/https/10/https.htps
  7. ^ Martin, James (1991). Rapid Application Development. Macmillan. pp. 81–90. ISBN 0-02-376775-8.
  8. ^ "The Disintegration of AD: Putting it Back Together Again" (PDF). gartner.com.br. Retrieved 13 April 2010.
  9. ^ Beck, Kent (2000). Extreme Programming Explained. Addison Wesley. pp. 3–7. ISBN 0201616416.
  10. ^ Gerber, Aurona; Van Der Merwe, Alta; Alberts, Ronell (16–18 November 2007). "Practical Implications of Rapid Development Methodologies". Proceedings of the Computer Science and Information technology Education Conference, CSITEd-2007. Computer Science and IT Education Conference. Mauritius. pp. 233–245. CiteSeerX 10.1.1.100.645. ISBN 978-99903-87-47-6.
  11. ^ Andrew Begel, Nachiappan Nagappan (September 2007). "Usage and Perceptions of Agile Software Development in an Industrial Context: An Exploratory Study" (PDF). First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007). pp. 255–264. doi:10.1109/esem.2007.12. ISBN 978-0-7695-2886-1. S2CID 1941370.
  12. ^ Maximilien, E.M.; Williams, L. (2003). "Assessing test-driven development at IBM". 25th International Conference on Software Engineering, 2003. Proceedings. pp. 564–569. doi:10.1109/icse.2003.1201238. ISBN 0-7695-1877-X. S2CID 16919353.
  13. ^ Stephens, Matt; Rosenberg, Doug (2003). Extreme Programming Refactored: The Case Against XP. doi:10.1007/978-1-4302-0810-5. ISBN 978-1-59059-096-6. S2CID 29042153.

추가 정보

  • 스티브 매코넬(1996년).신속한 개발: 야생 소프트웨어 일정 길들이기, Microsoft 프레스 북, ISBN 978-1-55615-900-8
  • Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in 90 Days or Less. McGraw-Hill. ISBN 0-07-034223-7.
  • 엘렌 고테스디너(1995).「RAD의 현실: RAD가 실제로 어떻게 기능하는지에 대한 과대 선전을 넘어" 애플리케이션 개발 동향
  • 켄 슈바버(1996년).Scrum을 통한 신속한 프로젝트 관리, Microsoft 프레스 북, ISBN 978-0-7356-1993-7
  • Steve McConnell (2003).프로페셔널 소프트웨어 개발: 일정 단축, 고품질 제품, 프로젝트 성공, 경력 강화, Addison-Wesley, ISBN 978-0-321-19367-4
  • Dean Leffingwell (2007).소프트웨어 민첩성 확장: 대기업을 위한 베스트 프랙티스, Adison-Wesley Professional, ISBN 978-0-321-45819-3
  • Scott Stiner (2016).Forbes 목록: "신속한 애플리케이션 개발(RAD): 소프트웨어 개발자를 위한 스마트하고 신속하며 가치 있는 프로세스"