신속한 애플리케이션 개발 모델 이해

RAD(Rapid Application Development)는 사용자로부터 빠른 피드백을 얻기 위해 계획 및 프로토타입 단계를 강조하는 소프트웨어 개발 방법입니다. 예비 설계 및 후속 구현을 포함하는 보다 전통적인 소프트웨어 개발 방법과 비교하여 RAD는 더 많은 유연성을 강조합니다. 지속적인 사용자 입력과 빠른 점진적 개선은 하루가 끝날 때 더 나은 결과를 얻는 데 도움이 됩니다.

1990년대에 James Martin은 신속한 애플리케이션 개발을 기존의 폭포수 절차에 대한 대안으로 정의했습니다. 전통적인 폭포수 방식은 건설 산업 및 작업 범위 수정이 드물고 비용이 많이 드는 기타 여러 분야에 탁월한 솔루션입니다. 이미 다리 건설을 시작했다면 다리 건설 중간에 페리 건설로 전환할 가능성은 거의 없습니다.

소프트웨어의 발전은 더 큰 적응성을 허용합니다. 동일한 비즈니스 어려움을 해결하기 위해 더 넓은 범위의 접근 방식을 사용할 수 있으며 더 낮은 비용으로 수정할 수 있습니다. 결과적으로 기업은 시행착오를 사용하는 반복적인 프로세스를 위해 정확한 설계와 계획을 희생합니다. 또한 소비자는 개선 사항을 관찰할 때 건설적인 비판을 할 가능성이 더 높습니다.

신속한 애플리케이션 개발이 내 프로젝트에 적합한 접근 방식입니까?

이전에 설명했듯이 RAD는 융통성이 없는 상황에서 작동하지 않습니다. 다음 상황에서는 적용되지 않습니다.

• 재정적 제약과 시간표에 대한 사전 지식이 필요합니다.
• 사용자에 대한 일관된 액세스 권한이 없거나 사용자가 프로젝트에 시간과 노력을 투자할 동기가 없습니다.
• 범위 때문에 프로젝트에는 이해 관계자로 알려진 상당한 수의 사람들이 참여해야 합니다.

이러한 제한은 종종 정부가 운영하는 거대한 기업과 조직에 적용됩니다. 반면에 이러한 상황에서도 신속한 애플리케이션 개발 프로세스의 일부 측면이 적용됩니다. 예를 들어, 정해진 가격이 있는 프로젝트는 프로토타입 단계와 특정 수의 수정을 위해 자금을 할당할 수 있습니다. 적절한 사용자가 있다면 프로토타입의 범위를 가장 불분명한 부분으로 제한할 수 있습니다.

반면에 신속한 애플리케이션 개발 프레임워크는 중소기업 및 부서별 프로젝트에 매우 적합합니다. 이것은 비즈니스 사용자가 돈을 소유하고 결과를 달성하려는 추진력이 있는 한입니다. 이것은 많은 LOB(기간 업무) 앱의 주요 예입니다. 일반적인 문구는 회사의 특정 측면을 보다 효과적으로 자동화하고 운영하는 소프트웨어 프로그램을 나타냅니다.

마찬가지로 RAD는 웹 사이트를 개발하는 동안 효과적인 접근 방식입니다. 이들은 제한된 이해 관계자 그룹이 있는 소규모 프로젝트인 경우가 많지만 디자인은 논란의 여지가 많은 주제이고 모든 사람이 이에 대해 할 말이 있기 때문에 초기에 포함시키는 것이 중요합니다!

단계 및 방법론

신속한 애플리케이션 개발 접근 방식에서는 시간 소모적인 계획 단계가 더 저렴한 프로토타입 단계로 대체됩니다. 특히, RAD 모델은 프로세스를 다음 4단계로 분리할 것을 제안합니다.

요구사항 계획

사용자와 프로젝트 팀은 이 단계에서 협력하여 미래 시스템의 목표를 결정합니다. 회사의 성공이 최우선 관심사입니다. 기준은 그다지 엄격하지 않습니다. 프로토타입이 아직 개발되는 동안 수정하거나 적용할 수 있는 능력이 필수적입니다.

사용자 디자인

빠른 응용 프로그램 개발 기술은 프로세스의 기본 구성 요소로 사용자 디자인을 강조하여 기존의 폭포수 모델과 차별화됩니다. 이 단계에서 개발자가 가장 먼저 하는 일은 프로토타입 작업입니다. 목표는 시연해야 하는 모든 것을 고객에게 빠르고 저렴하게 보여주는 것입니다. 프로토타입이 일부 기준만 충족하거나 가능한 상황의 하위 집합만 처리할 수 있는 경우 거래 차단기가 아닙니다. 코딩과 관련하여 바로 가기를 사용할 수 있습니다.

프로토타입이 완성되면 피드백을 위해 사용자에게 표시됩니다. 팀은 가능한 한 많은 정보를 수집하며, 이 단계에서 필수 기준은 불가피하게 수정될 수 있습니다. 글로 적었을 때 의미가 있었던 것이 실제로 적용되면 다른 모습을 보일 수 있습니다. 개발자가 이 입력을 받으면 프로토타입 프로세스로 돌아가 소비자가 최종 결과에 만족할 때까지 계속합니다.

건설

이 시점에서 우리는 충족되어야 하는 요구 사항을 충분히 알고 있습니다. 이제 시스템 개발 및 테스트를 완료하여 프로덕션 환경에서 사용할 수 있도록 준비해야 합니다. 더 이상 지름길은 없습니다. 대신 품질, 확장성, 유지 관리 가능성 및 기타 요소에 중점을 둡니다. 하지만 이 늦은 시점에도 소비자들은 새로운 기능이 도입되면 댓글을 달며 소통을 이어가고 있다. 빠른 응용 프로그램을 개발하는 반복적인 프로세스의 이 시점에서 아직 추가 미세 조정의 여지가 있습니다.

우리가 사용하게 되는 도구와 관련된 다른 요소에 따라 프로토타이핑 프로세스에서 지금까지 수행한 작업을 사용할 수조차 없었습니다.

컷오버

이것은 사용자 교육, 수용 가능성 테스트 및 새 시스템 구현을 포함하는 마지막 단계입니다.

신속한 애플리케이션 개발과 비교 기민한

"RAD"라는 이름은 Agile 개발 방법론보다 10년 전에 만들어졌으며 반복적인 방법론으로 인해 RAD는 때때로 Agile의 "부모"라고 불립니다. 반면에 이것은 상황이 아닙니다. Agile 은 규범적 개발 기술인 RAD와 달리 단순한 소프트웨어 개발 이상의 것을 포괄하는 철학적 관점입니다.

RAD(Rapid Application Development)가 Scrum, Kanban 등과 같은 다른 애자일 소프트웨어 개발 접근 방식과 동일한 제품군의 구성원이라고 가정하는 것이 안전합니다.

신속한 애플리케이션 개발의 장점과 단점

초점은 예측 가능성에서 벗어나 RAD로 인한 적응성으로 이동하며, 이는 좋은 의미와 나쁜 의미를 모두 가지고 있습니다.

장점 :

비용 및 위험 감소

사용자는 프로젝트가 전달된 후에만 방법의 결과를 보고 의견을 제공할 수 있습니다. 이 시점에서 수행해야 하는 불가피한 조정은 시간과 비용이 많이 듭니다. 신속한 애플리케이션 개발 프로세스를 사용하면 솔루션이 구현된 후 절반을 다시 작성해야 할 가능성이 크게 줄어듭니다.

우수한 품질

최종 프로그램은 사용자가 프로토타이핑 프로세스에 적극적으로 참여한다면 사용자의 활동에 더 잘 적용될 것입니다. 또한 결과에 관계없이 기대에 부응할 것입니다.

단점:

불쌍한 디자인

특정 비즈니스 요구 사항을 추구하고 프로토타입 단계에서 지름길을 택할 때 너무 멀리 가는 자신을 발견할 수 있습니다. 따라서 설계 및 전체 솔루션이 좋지 않습니다.

효과적으로 확장할 수 없음

RAD 패러다임은 팀과 최종 사용자가 긴밀하게 협력하여 협력해야 한다고 가정합니다. 프로토타입 프로세스는 팀이 너무 크거나 이해 관계자가 너무 많으면 항상 느린 속도로 이동합니다. 또한 프로젝트 범위의 빈번한 변경을 모든 당사자에게 설명하는 것이 어려워집니다. 따라서 RAD는 중소 규모의 그룹에 가장 적합하다고 생각됩니다.

백엔드에서 고객의 약속

신속한 애플리케이션 개발 기술은 프로젝트 수명 동안 상당한 양의 사용자 입력을 예상합니다. 보고서에 따르면 이는 조직에서 가장 바쁜 개인이기도 한 업계에서 가장 자격을 갖춘 전문가에게 특히 해당됩니다.

통제력을 발휘할 수 없음

프로젝트의 프로토타입 단계가 완료되기 전에는 명백한 이유로 프로젝트의 범위, 예산 또는 일정을 정확하게 예측할 수 없습니다. 그러나 요구 사항 계획 프로세스의 결과에 따라 여전히 몇 가지 일반적인 기대치를 설정할 수 있습니다.

신속한 애플리케이션 개발(RAD)을 위한 도구

RAD 접근 방식의 적용은 주로 신속한 프로토타이핑과 긴밀한 협력에 의존합니다. 따라서 이러한 노력을 지원하는 적절한 도구를 선택하는 것이 가장 중요합니다. 우리의 행운을 위해 선택할 수 있는 광대한 선택이 있습니다.

디자인 및 프로토타이핑

Figma 및 InVision과 같은 신속한 애플리케이션 개발 기술을 통해 시각 디자이너와 UX 전문가는 빠르게 함께 빌드하고 클릭 가능한 프로토타입을 최종 사용자와 공유할 수 있습니다. 이것은 개발자가 사용자 입력을 수집할 수 있도록 완전한 디자인을 가지고 있습니다. 프로토타입의 반복 중 하나에 승인이 주어지는 즉시 프론트엔드 개발자가 재사용할 수 있는 형식으로 프로젝트를 내보낼 수 있습니다. 따라서 건설 단계로의 전환을 표시합니다. 웹 사이트 생성이 이러한 도구의 가장 일반적인 사용이지만 더 복잡한 최종 사용자 앱 또는 포털의 사용자 경험을 프로토타이핑하는 것은 또 다른 용도입니다.

비즈니스 분석가는 Balsamiq와 같은 다른 애플리케이션을 훨씬 더 자주 사용합니다. 그들은 와이어프레임을 사용하여 사용자 경험의 프로토타입을 만드는 데 집중하고 있습니다. 그런 다음 나중에 최종 디자인을 구현합니다. 이는 복잡한 사용자 상호 작용을 포함하는 보다 광범위한 시스템을 예비 모델링하기 위한 탁월한 옵션입니다.

개발

애플리케이션을 구축하는 개발 단계는 가장 많은 시간을 소비하고 가장 비용이 많이 들며 가장 큰 불확실성을 안고 있습니다. 따라서 신속한 애플리케이션 개발을 위한 현재 플랫폼은 테스트된 아키텍처를 통합합니다. 이들은 표준 기능을 구현하는 준비된 구성 요소와 신속한 개발을 더 쉽게 만드는 도구입니다. 이들 모두를 사용하여 더 빠르게 결과를 제공할 수 있습니다. 프로젝트의 프로토타입 단계에 있는지 아니면 건설 단계에 있는지 여부.

Gartner 및 Forrester와 같은 컨설팅 회사는 이러한 각 플랫폼을 차별화하기 위해 새로운 명명법을 지속적으로 개발하고 있습니다. 종종 다음을 포함합니다: 로우 코드/코드 없는 애플리케이션 플랫폼(LCAP), 서비스로서의 고 생산성 애플리케이션 플랫폼(HPAPaaS) 및 다중 경험 개발 플랫폼. 다음은 모두 사용할 수 있는 다양한 유형의 애플리케이션 플랫폼(MXDP)의 예입니다. 그러나 결국 독자층에 따라 각각이 분류될 수 있다.

로우 코드/노코드 플랫폼

이러한 플랫폼의 기본 개념은 코딩 전문 지식이 없는 비즈니스 사용자(파워 사용자 또는 시민 개발자라고도 함)가 기능적 응용 프로그램을 신속하게 제공할 수 있도록 하는 것입니다. 물론 이러한 단순성에는 유연성이 부족하고 다양한 제한이 따릅니다. 최근 기사에서 저는 이러한 한계와 위험에 대해 논의했습니다. 결과적으로 이러한 플랫폼의 목표 시장은 프로토타입 또는 기본 솔루션으로 구성됩니다.개발자 중심 플랫폼

이러한 플랫폼은 소프트웨어 개발의 신속성과 흥분을 활용합니다. 주로 더 높은 수준의 API 및 코드 생산 제공을 통해. 따라서 프로그래머는 더 이상 상용구 코드를 반복적으로 작성하고 표준 기능을 구현할 필요가 없습니다.

이전에 Borland Delphi였던 Embarcadero RAD Studio는 업계의 개척자 중 하나입니다. 시각적 사용자 인터페이스 디자인으로 잘 알려져 있습니다. 볼랜드 델파이의 성입니다. 웹이 출현하기 이전에 사용되었으며 데스크톱 컴퓨터 및 모바일 장치의 앱에 여전히 사용할 수 있습니다.

웹은 다른 신속한 애플리케이션 개발 프레임워크의 주요 대상입니다. 현대에서 최종 소비자와 소통하는 가장 보편적인 방법이기 때문입니다. 예를 들어, 여기 Jmix에서 우리는 시각적 데이터 모델 및 인터페이스 디자인의 간편함과 신속함을 오늘날의 오픈 소스 기술의 효율성과 결합하기 위해 노력하고 있습니다. 이 전략은 프로토타입을 만드는 속도를 높입니다. 그러나 프로토타입을 안정적이고 확장 가능한 구조를 가진 완전한 기업 응용 프로그램으로 개발할 수 있는 기능도 제공합니다.

결론

애자일 사고방식을 고수하는 개발 접근 방식 중 하나는 RAD(빠른 애플리케이션 개발)입니다. 최종 사용자의 적극적인 참여와 해당 사용자의 입력을 사용하여 신속하고 반복적인 프로토타입을 개발하는 것은 RAD 방법론의 두 가지 핵심 교리입니다. 최종 사용자의 만족을 보장한 후 생산에 적합한 소프트웨어 공급에 주의를 기울입니다.

신속한 프로토타이핑을 위해서는 적절한 도구를 선택하는 것이 중요합니다. 결과적으로 주어진 프로젝트 내에서 RAD 방법론을 효과적으로 사용합니다. 좋은 소식은 사용할 도구와 플랫폼이 다양하다는 것입니다. 이들은 다양한 종류의 응용 프로그램, 프로젝트 단계 및 팀의 기술 세트에 적합합니다.

RAD는 오래된 아이디어지만 이제 부흥을 겪고 있습니다. 이는 현재의 디지털 혁신 추세와 시장 출시 시간 단축을 향한 추진력의 직접적인 결과입니다. 적절한 종류의 프로젝트와 적절한 종류의 팀에 사용될 때 RAD 접근 방식은 더 적은 위험과 더 짧은 시간에 더 많은 고객 만족을 달성할 수 있습니다.