Rapid application development

Rapid application development

From Wikipedia, the free encyclopedia

Jump to: navigation, search

 

이 문서는 소프트웨어 개발에서 사용되는 Rapid Application Development에 대한 글이다. 소프트웨어의 빠른 개발을 위한 툴에 대한 내용을 보고자 한다면 List of rapid application development tools을 확인해보자.

Rapid Application Development (RAD)은 소프트웨어 개발 방법론의 타입중에 하나이며, 이것은 빠른 프로토타이핑을 이용하여 최소한의 계획을 가지고 작업하는 것이다. RAD에서 "planning"이라는것은 소프트웨어 그 자체에 함께 녹아들어 있음을 나타낸다. 일반적으로 소프트웨어에서 비싼 사전계획의 결핍을 허용한다는 것은 매우 빠르게 소프트웨어를 개발할수 있고, 요구사항 변화를 쉽게 해주기도 한다.

 

개요

Vijayrajah에 의하면 RAD는 소프트웨어 개발 방법론이며, 이것은 반복적인 개발 방법론과 소프트웨어 프로토타이핑과 같은 기술을 포함하고 있다. Whitten에 의하면 다양한 기술들의 구조화된 조합이며, 특히 데이터 위주의 정보공학적 방법론과 가속 소프트웨어 개발 기술인 프로토타입 기술이 함께 적용하는것을 말한다.

RAD에서 구조화된 기술과 프로토타이핑은 사용자 요구사항을 정의할때 그리고 최종 시스템을 설계할때 주로 이용된다. 개발 프로세스는 기본적인 데이터모델링과 비즈니스 프로세스 모델링을 구조적인 기술을 이용하여 시작되고, 다음 단계로 프로토타이핑 기술을 이용하여 요구사항을 정의하게 된다. 결국은 데이터와 프로세스 모델을 정련하는 것이다. 이러한 단계들은 반복적인 수행과정을 통해서 이루어 지며 향후 개발 결과로 "새로운 시스템이 구현되기 위해 사용되어진 비즈니스 요구사항과 설계 기술의 결합체"가 된다.
RAD접근은 빠른 개발을 가능하게 하고, 효과적인 애플리케이션 유지를 위해 기능이나 성능면과 타협점이 필요하게 된다.

배경

RAD는 소프트웨어 개발 프로세스라고 James Martin에 의해서 소개되었던 용어이다. 마틴은 반복적인 개발과 프로토타입을 개발 방법론에 포함했는데, 최근에는 웹 개발 프레임워크와 다른 소프트웨어 프레임워크 타입에 이용되는 것처럼 광범위하게 이용되고 있다.

---

RAD는 1970년에서 1980년에 구조적 분석과 설계 방법론과 워터폴 모델등에서 non-agile 프로세스 개발 방법론이었다. 이러한 방법론의 문제중에 하나는 애플리케이션을 개발하는데 오랜 시간이 거리는것과 시스템이 완료되기 전에 변화가 발생할때에는 그 부작용이 매우 크다는 것이며, 이러한 관계로 만족스럽지 못한 결과와 실용성이 없는 시스템을 만드는데 있었다. 다른 문제로는 요구사항 분석 단계에서 모든 주요 요구사항을 도출해냈다는 가정하에서 개발이 이루어 진다는 것이며, 많은 사실들이 이러한 증명을 해주고 있다. 그것이 바로 개발을 모든 단계에서 경험이 매우 높은 프로페셔녈에 의해서 개발이 좌우된다는 것이다.

---

1980년대 이러한 RAD의 개념이 정형화 되어 Rapid Application Development 이 1991년 Brian Gallagher, Alex Balchin, Barry Boehm and Scott Shultz, James Martin 의 저서로 나오게 되었다.

RAD의 효과

과거 세션 기반의 클라이언트/서버 개발 환경에서 웹 2.0과 같이 세션없이 상호작용하는 개발 방법으로 전환되면서 SDLC의 단계들이 매우 빠른 속도로 반복 수행이 필요하게 되었다. 이러한 결과로 오픈소스 프레임워크의 사용성이 증가되었고, 이것들이 상업용 개발소스의 핵심 부분으로 차지하게 되었다. 이러한 요구에 따라 RAD 방법론은 은탄환으로써 다시 개발자들에게 흥미의 대상이 되었다.

비록 대부분의 RAD 방법론이 소프트웨어 재사용을 촉진과, 작은 팀 구조, 그리고 분산 시스템 개발을 촉진하였지만 대부분 RAD 경험자들은 이것이 단순히 "rapid" 방법론만은 아니라는것을 인지하고 있다. 이것은 다른 개발 방법론들의 향상을 도와줄 수 있도록 해준다는 것이다.
  

RAD의 묘미는 제품 개발을 더욱 빠르게 하고, 향상된 코드 퀄리티를 위한 좋은 프레임워크를 제공하는 잠재력을 가지는데 있다. 그러나 성공적인 구현에는 프로젝트 타입, 스케줄, 소프트웨어 릴리즈 사이클, 그리고 기업의 문화에 달려 있다. 이것은 또한 아직 주요 프로덕트에는 RAD를 광범위하게 사용하지 않고 전통적인 워터폴 모델이나 거기에 약간의 스파이럴링(스파이럴 모델)을 추가한 형태를 사용하는 MS나 IBM등과 같은 대형 벤더들에게 흥미로운 대상이 되고 있다. 다음 테이블은 RAD에서 주로 사용되는 몇가지 방법론들의 장점과 단점을 간략하게 기술한 것이다.

Agile software development
Pros	소프트웨어 프로젝트의 모형 개발 혹은 작은 증분의 프로덕트 릴리징에서 주로 이용되며, 짧은 결과 주기를 이용하여 작은 사이즈의 기능을 출시한다.
Cons	짧은 반복은 충분한 기능을 추가하지 못할 수 있다. 이것은 최종 반복주기에서 딜레이를 가져올 수 있는 문제점이 있다. Agile 에서는 실시간 커뮤니케이션을 강조한다. (preferably face-to-face) , 이 개발방법은 복합 팀이 분산된 시스템을 개발할때 발상해는 문제들에 유용하게 적용할 수 있다. agile 방법은 매우 작은 문서를 작성하고, 향후 프로젝트 문서를 제출하는 문제점도 있다.
Extreme Programming (XP)
Pros	새로운 요구사항에 대해서 짧은 스파이럴을 통해서 변화에 대한 비용을 최소하 한다. 대부분의 설계 활동은 기존에 대한 증분으로 이루어 지고 매우 빠르게 수행된다.
Cons	짝으로 프로그래밍을 수행하는것을 요구한다(이것은 특정 개발자들에게는 어려운 일이 될수 있다. ), 또한 상세한 디자인이 없고, 이것은 오랜기간동안 다시 디자인해야하는 결과를 가져올 수 있다. 비즈니스업무에 능통한 사람이 풀타임으로 프로젝트에 참여해야한다. 이것은 프로젝트가 하나의 실수나 실패에 집착하게 할 수 있고, 팀의 주요 스트레스로 작용할 수 있다.
Joint Application Development (JAD)
Pros	JAD라고 불리는 세션을 통해서 상호 워크샵의 과정을 통해서 애플리케이션 설계와 개발에 포함된 팀원에 의해서 고객의 소리를 들을 수 있음
Cons	고객이 팀원이 을 좌지우지 할수 있거나, 요구사항을 광범위하게 glod-plating(도금)하거나, 실현가능성이 없는 비젼을 제시할 수 있다.
Lean software development (LD)
Pros	필요한 최소한의 솔루션을 만들고, 작은 기능을 조기에 양도할 수 있다. 이것은 (오늘의 80%가 내일의 100%보다 좋다는 패러다임을 기초로 하고 있다.)
Cons	산출물의 경쟁력이 떨어질수 있다. 왜냐하면 부족한 핵심 기능과 전체적으로 빈약한 퀄리티를 보여주기 때문이다.
Rapid Application Development (RAD)
Pros	강력한 상호 협동체계와 요구사항을 동적으로 수집 가능하게 해준다. 비즈니스 오너는 활동적으로 프로토타이핑에 참여하고, 테스트 케이스를 작성하며, 단위 테스트를 수행하게 된다.
Cons	강력한 상호 협력하는 팀에 의해서 좌우된다. 또한 개발자의 훈련도에 성공이 좌우되며, 그들의 스킬과 밀접하게 연결되어 있따. 의사 결정은 팀의 기능에 달려 있으며, PM과 엔지니어 인증에 중앙관리 되기보다는 문화적인 요인으로 흘러가기 쉽다.
Scrum
Pros	작업 우선순위에 따라서 처리하는 것으로 기존의 무거운 프로세스에 의해서 녹초가 되던 팀의 생산성 향샹을 가져온다. 이것은 backlog라는 도구를 이용하며, 각 백로그의 내용은 짧은 반복 혹은 스프린트에 의해서 수행된다. 이로 인해서 진척도와 커뮤니케이션을 매일 측정할 수있다.
Cons	이것은 전적으로 마스터(스크럼 마스터)에 의해서 좌우되며, 마스터는 잠재적인 제약사항을 제거하고, 스프린트의 목표로 나아갈수 있도록 독려해야한다. 또한 자기 조직적인 팀과 과거 프로세스 중심의 중앙집중적인 관리의 배제, 그리고 내부의 노력이 매우 필요하다.

Table1: Pros and Cons of various RAD flavors

평론

Since rapid application development is an iterative and incremental process, it can lead to a succession of prototypes that never culminate in a satisfactory production application. Such failures may be avoided if the application development tools are robust, flexible, and put to proper use. This is addressed in methods such as the 2080 Development method or other post-agile variants.
RAD는 반복과 점진적인 프로세스가 나온 이후로 이것은 프로토타입에서 연속적으로 제품화 되도록 리드한다. 하지만 애플리케이션 프로덕트의 만족을 도달할 수 없었다. 그러한 실패를 피하기 위해서는 개발 툴을 견고하고, 유연하며, 적절하게 사용하는 것이 필요하다는 것이다. 이러한 내용은 2080 Development method 혹은 다른 이후 agile에 대해서 확인해 볼 수있다.

RAD를 위한 실천적인 사항

When organizations adopt rapid development methodologies, care must be taken to avoid role and responsibility confusion and communication breakdown within the development team, and between the team and the client. In addition, especially in cases where the client is absent or not able to participate with authority in the development process, the system analyst should be endowed with this authority on behalf of the client to ensure appropriate prioritisation of non-functional requirements. Furthermore, no increment of the system should be developed without a thorough and formally documented design phase ^[6].