애자일은 RAD의 변형입니까?


16

Wikipedia에 따르면 Agile은 "RAD"의 한 유형이라고 생각합니다. 내가 아는 바에 따르면, 애자일은 RAD 자체가 90 년대에 성공하지 못했기 때문에 개발되었습니다. 아니면 내가 틀렸어?

(비고 : 애자일 소프트웨어 개발에 관한 Wikipedia 기사 는 그 사이에 개선되었다. RAD 를 수퍼 셋이 아닌 Agile의 전신으로 표시합니다.)

책 급진적 프로젝트 관리 (Thomsett)에서 참조

".. RAD, Agile, Object oriented와 같은 새로운 개발 유행."

CISA 인증 정보 시스템 감사관 :

.. 두 개의 대체 소프트웨어 개발에 대해 알고 있습니다. 방법 : 민첩하고 빠른 응용 프로그램 개발

소프트웨어 민첩한 관리 :

민첩한 방법은 대부분 RAD의 간단한 접근 방식에서 파생됩니다.

소프트웨어 추정 모범 사례 :

sw의 주요 방법. dev. 다음과 같이 요약 될 수있다
1. 폭포 ..
제 RAD
제 민첩

이 질문의 핵심은 :
Agile 유형의 RAD 또는 독립형 개발 방식입니까?


1
RAD = 빠른 응용 프로그램 개발. 애자일은 확실히 그 범주에 속합니다.
Oded

2
@Oded : 많은 소스가 어떻게 그렇게 말하지 않는가? 주로 빠른 배달을 목표로했기 때문에 "민첩한"이라는 단어로 표현되는 적응성에 민첩한 이유 ..
John V

1
물론 민첩성은 적응성에 관한 것이지만 동시에 우선 순위가 높은 항목을 빠르게 전달하는 것에 관한 것입니다 .
Oded

1
"위키 백과는 말한다"-에 기사 , 사인이 "표창장은 필요로했다" "민첩한 방법이 많이 신속한 응용 프로그램 개발과 공통점이"그 문 근처 -이 문을 의미 위키 피 디아의 기준에없는
모기

1
"독립 개발 방식"이란 무엇입니까?
Thomas Owens

답변:


15

용어로서의 RAD는 애자일을 약 10 년 앞서서 사용하지만 실제로 애자일의 "부모"는 아닙니다. 둘 다 전통적인 소프트웨어 개발 관리 기술을 통해 인식 된 단점에 대한 반응으로 만들어졌습니다. 그러나 RAD는 연속적인 프로토 타입을 사용하여 요구 사항을 도출하고 응용 프로그램을 구체화하여 소프트웨어를 작성하는 규범적인 방법입니다. 원래 도입 된 형태의 민첩성은 전통적인 접근 방식과 민첩한 전문가가 중점을 둔 가치의 차이를 설명하는 철학적 입장입니다.

따라서 민첩한 소프트웨어 개발은 ​​일종의 RAD가 아닙니다. 그것들은 다른 추상화 수준에서 문제를 해결합니다.


그것이 내가 정확히 생각하는 것입니다. Wiki가 업데이트되어야한다고 생각합니다.
John V

2
글쎄 편집 가능하므로 그렇게 할 수 있습니다 ;-)

11

hiearchies에서 개발 방법론을 분류하는 것이 옳지 않다고 생각합니다. 따라서 다른 어떤 방법도 "위"또는 "위"가 아닙니다. 일반적인 방법론에 대해 생각하는 것이 훨씬 더 논리적입니다. 종종 실제 방법론의 적용에는 많은 유사한 방법론의 조합이 포함되며 작업 개발 모델을 만드는 것은 관리자에게 달려 있습니다.

RAD (내가 경험하지 않은) 대 Agile의 경우 반복적 인 개발 만 공통점 인 것 같습니다. RAD는 구체적인 목표와 결과를 가진 엄격한 단계를 선호하는 것 같습니다. 애자일은 모든 일이 일어나는 단일 개발 단계에 관한 것입니다. 또한 Agile은 사전에 프로토 타입을 작성하지 않고 기능을 제거 할 수있는 소프트웨어를 직접 개발합니다. (이는 종종 프로토 타입이 다시 올바르게 작동하는 대신 작동중인 소프트웨어에 즉시 통합되기 때문에 민첩한 결과와 동일 할 수 있습니다)


1
이것이 애자일이 제품 언어와 다른 언어로 프로토 타입을 만들 것을 제안한 이유입니다. 프로토 타입은 일반적으로 올바르게 수행되지 않습니다. 예를 들어 제품의 프로토 타입과 C ++의 matlab
BЈовић

-1

애자일 방법론은 이해 관계자에게 빠른 반복 데모를 통해 반복 모델로 응용 프로그램을 작성하도록 설계 되었기 때문에 더욱 엄격합니다. 개발자는 설계 패러다임 (특히 모듈 식)을 유지하지 않아도되지만 지속적인 반복 제공과 비즈니스 요구 사항의 빠른 변화에 대한 빠른 대응에 집중하면서 직접 강조하지는 않습니다. 실제로는 격리 된 제품을 개발하는 데 중점을두고 제품 프레임에서 작동하지만 솔루션의 구성 요소를 명확하게 재사용 할 필요가 없으며 회사 수준의 제품군을위한 공통 플랫폼을 구축 할 필요가 없습니다. 어느 기술 관리자도 동일한 작업을 N 번 반복하는 것을지지하지 않습니다. 다행스럽게도 RAD는 도메인, 모듈 및 이들의 통합과 기술적 인 관점에서 개발을 분리합니다. 회사의 기술 관리 관점에서 합리적인 개발 모델의 기술 조직에 더 적합합니다. 이로 인해 모델이보다 유연하고 재사용 가능하며 다른 제품에 적합합니다. 마지막으로 회사는 프리랜서 커뮤니티가 아니며 한 제품의 수명보다 수명이 연장됩니다. 그러나 회사가 마이그레이션 및 수정없이 단일 제품을 생산하는 경우 RAD의 역할이 그렇게 표현 적이 지 않습니다. 그러나 일반적으로 Agile의 비즈니스 강점은 RAD의 기술 조직 강점과 훌륭하게 결합됩니다. 마지막으로 회사는 프리랜서 커뮤니티가 아니며 한 제품의 수명보다 수명이 연장됩니다. 그러나 회사가 마이그레이션 및 수정없이 단일 제품을 생산하는 경우 RAD의 역할이 그렇게 표현 적이 지 않습니다. 그러나 일반적으로 Agile의 비즈니스 강점은 RAD의 기술 조직 강점과 훌륭하게 결합됩니다. 마지막으로 회사는 프리랜서 커뮤니티가 아니며 한 제품의 수명보다 수명이 연장됩니다. 그러나 회사가 마이그레이션 및 수정없이 단일 제품을 생산하는 경우 RAD의 역할이 그렇게 표현 적이 지 않습니다. 그러나 일반적으로 Agile의 비즈니스 강점은 RAD의 기술 조직 강점과 훌륭하게 결합됩니다.


4
이 게시물은 읽기 어렵습니다 (텍스트의 벽). 더 나은 형태로 편집 하시겠습니까 ?
gnat
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.