RAD(Rapid Application Development)

관련도서 : http://www.yes24.com/24/goods/380739

 

 

출처 : http://anyflow.net/397
참고 : http://neokido.tistory.com/576

RAD 도구 : http://en.wikipedia.org/wiki/Rapid_application_development#searchInput

1. 신속 S/W 개발(Rapid S/W development)
- 비즈니스 환경의 빠른 변화, 비즈니스는 새로운 기회와 도전에 신속히 응답해야. Time-to-market
- 이 경우, 신속한 개발과 인도는 종종 S/W 시스템에 관한 가장 중요한 요구사항
- 위와 같은 배경 기반의 비즈니스 영역에서는 주요 기능이 정상적으로 동작하기만 하면 빠른 인도의 장점이 낮은 품질이란 단점을 상쇄
- 요구사항
  1) 환경의 변화로 인해 안정적이고 일관적인 시스템 요구사항에 도달하기가 매우 어려움
  2) 따라서 waterfall 모델은 비현실적, 오직 반복적(iterative) 명세와 인도에 기반을 둔 개발 방법론만이 S/W를 신속하게 인도하는 유일한 방법

2. RAD 프로세스의 특성
- 명세, 설계, 구현 프로세스가 동시에 이루어짐. 상세 명세는 없으며 설계 문서는 최소화됨
- 시스템은 일련은 점증적 단계(증분; increment)를 통해 개발됨. 최종 사용자는 개발에 참여하여 각 점증 단계를 평가하며, 이후 점증 단계를 위한 제안을 함
- 시스템 UI는 일반적으로 반복적 개발 시스템을 이용하여 개발됨

점증적 개발 프로세스

3. 점증적 개발(Incremental development)의 장점
- 고객 서비스의 신속한 인도(accelerated delivery of customer services) : 각 점증 단계(증분; increment)는 고객의 가장 높은 우선순위의 기능을 인도
- 시스템에 대한 사용자의 참여 : 사용자는 개발에 참여하여 시스템이 좀더 그들의 요구에 다가서고, 사용자는 시스템에 대해 더 나은 만족을 얻을 수 있음

4. 점증적 개발의 문제점
- 관리 문제(Management problem) : 문서가 없으므로 상황 파악이 어려움
- 계약 문제(Contractual problem) : 명세가 없으므로 명세 이외의 타 형식의 문서를 사용해야
- 검증 문제(Validation problem) : 명세가 없으면, 어떤 기준으로 시스템을 테스트할 것인가
- 유지보수 문제(Maintenance problem) : 계속적인 변경은 S/W 구조에 문제를 일으키고(corrupt), 이로써 S/W는 새로운 요구에 대한 변경과 진화가 어려워짐

5. 프로토타이핑(Prototyping)
- 일부 대규모 시스템에서는 점증적 반복 개발과 인도는 비현실적. 특히 다수의 팀이 각가 다른 위치에서 일할 경우
- 실험적 시스템을 개발하는 프로토타이핑을 통해 요구사항의 타당성(실제 사용할만한지 여부 판단) 체계화(formulate)를 위한 기반을 세울 수 있음. 시스템 명세가 만들어지면(agreed) 프로토타입은 폐기됨(throw away)

6. 점증적 개발과 프로토타이핑
- 점증적 개발의 목적은 최종 사용자에게 실제 동작하는(working) 시스템을 인도함에 있음. 개발은 가장 잘 이해된 요구사항을 바탕으로 시작됨.
- 프로토타이핑의 목적은 시스템 요구사항의 검증 또는 추출임. 프로토타이핑 프로세스는 잘 이해되지 않은 이해사항에서 시작.

 

점증적 개발과 프로토타이핑의 목적

7. 애자일 기법(Agile Methods)
- 기존의 개발 접근법에 대한 불만,즉 계획 수립, 설계, 문서화에 대한 부하(overhead)에 대한 반기로 시작
- 설계와 문서화보다는 S/W 자체(특히 코드)에 초점을 두도록
- 점증적 접근법에 기반
- 빠르게 변화, 진화해가는 요구사항에 대한 신속한 S/W의 배포
- 주로 소/중규모 비즈니스 시스템이나 PC 제품이 알맞음
- XP는 가장 잘 알려진 애자일 기법 중 하나

8. 애자일의 원칙
- 고객 참여(Customer involvement) : 고객은 요구사항 개발 및 운선순위 결정, 시스템의 반복(iteration)을 평가
- 점증적 인도(Incremental delivery) : 고객이 지정한 요구사항이 포함된 점증 단계를 기반으로 s/w가 개발되고 인도됨
- 사람은 프로세스가 아님(People not process) : 기정의된 프로세스를 강요하지 않음. 개발자 및 개발팀 만의 방식, 그들의 기술을 인정
- 변화를 포용(Embrace change) : 요구사항의 변화를 받아들이고 ,변화 수용 가능한 시스템을 설계
- 단순성 유지(Maintain simplicity) : S/W 및 개발 프로세스 모두에서 단순성에 초점을. 수시로 시스템에 남겨진 복잡성을 제거하도록

9. 애자일의 문제점
- 고객은 전적으로, 계속하여 프로세스에 참여하기 어려움
- 개발팀 구성원이 집중적인 참여를 요구하는 애자일의 특성에 맞지 않을 수도
- 다수의 이해관계자(stackholder)가 있을 경우 우선순위 변경이 어려워짐
- 단순성 유지는 추가적 작업을 요구
- 내재화된 점증적 명세화 작업으로 인해, 명사가 포함된 계약서 작성이 난해. 따라서 타 외부 개발 조직과의 co-work이 어려워질 수도

10. Extreme Programming(XP)
- 가장 잘 알려지고, 가장 많이 사용되는 애자일 기법
- 반복적 개발과 같은 좋은 실무 관행과 고객 참여을 극한(extreme)까지 밀고 나감
  1) 새로운 버전이 하루에도 몇 번씩 빌드될 수 있음
  2) 매 2주마다 각 점증적 단계가 고객에게 인도
  3) 매 빌드마다 모든 테스트가 수행되고 테스트에 성공했을 때만 해당 빌드를 인정

 

XP 릴리즈(release) 사이클

11. Extreme programming Practices
- 점증적 계획(Incremental planning) : 시토리 카드를 이용, 작업으로 분할. 이들 작업은 스케줄링과 비용 산정의 근간. 시간을 고려하여 우선순위 결정
- 소규모 릴리즈(Small releases) : 비즈니스 가치를 제공하는 최소한의 유용한 기능을 먼저 개발. 릴리즈를 자주, 점증적으로 수행
- 단순한 설계(Simple design) : 현재의 요구사항을 충족하는 충분한 설계를
- 테스트 주도 개발(Test driven development): 구현 이전에 자동화된 단위 테스트 프레임워크를 통해 테스트 킷을 먼저 작성
- 리팩토링(Refactoring) : 계속적으로, 최대한 많이 코드를 리팩토링. 단순성, 유지보수성 증가
- 짝 프로그래밍(Pair programming) : 짝으로 팀을 이뤄 함께 개발. 서로가 상대의 작업을 검사(checking)하도록. 비공식적 검토(Informal review)가 자연스럽게 이루어짐
- 집단적 소유(Collective ownership) : 짝이 시스템의 모든 영역을 맡음으로 고립된 비 개발 영역이 없도록. 누구든지 변경 코드 변경 가능
- 계속적 통합(Continuous integration) : 작업이 완료되자마자 전체 시스템에 통합되도록. 이후 모든 단위 테스트를 통과해야
- 유지 가능한 속도(Sustainable pace) : 초과 근무는 낮은 품질, 보통의 생산성 만을 양성할 뿐
- 현장의 고객(On-site customer) : 고객은 개발팀의 일원. 전적으로 개발에 시간을 할당하여 시스템 요구사항을 전달할 책임이 고객에게 존재

12. Rapid application development(RAD)
- 데이터에 집중된 비즈니스 응용(application), 즉 DB로부터의 정보를 표현하는 응용에 주로 사용
- RAD 환경 도구 : DB 프로그래밍 언어, Interface 생성기, 오피스 응용 프로그램과의 연결, 리포트 생성기, 대화식 개발에 알맞는 Visual programming 도구

13. Visual development
- 단위가 작은 재사용 가능 S/W 컴포넌트의 통합에 의존하는 RAD 기법
- Visual Basic같은 스크립트 언어를 사용
- 대규모 컴포넌트가 기정의, 기구현되어 있음
- 특정 응용 요구사항에 맞도록 재구성될(tailored) 수도
- COTS(Commercial Off-the-Shelf; 상용 기성품) 기반 개발이라 부르기도. 기성품을 재구성(configure)하고 연결
- 복합 문서(Compound documents)
  1) 사용자 조작(computation)이 가능한 능동 요소(active element)가 내장된 문서. 복합 문서 자체는 각기 다른 응용을 통합하는 역할
  2) 각각의 능동 요소는 특정 응용과 연결되어 해당 요소 선택시 활성화됨
- 문제점
  1) 팀 기반 개발에 알맞지 않음
  2) 명시적 시스템 아키텍처가 없음
  3) 프로그램 부위간 복잡한 의존성이 유지보수 문제를 일으킬 수도

14. S/W 프로토타이핑(Prototyping)
- 개념을 보여주고(demonstrate), 설계 선택사항(option)을 시험해보기 위한 개발할 시스템의 초기 버전
- 용도는,
  1) 요구공학 프로세스 : 요구사항 추출 및 검증을 위해
  2) 설계 프로세스 : 선택사항 시험 및 UI 설계 개발을 위해
  3) 테스트 프로세스 : back-to-back 테스트 수행을 위해
- 장점
  1) 시스템 사용성 향상
  2) 사용자의 실제 필요에 더욱 근접
  3) 설계 품질 향상
  4) 유지보수성 향상
  5) 개발 노력(effort)의 절감
  6) back-to-back 테스트가 가능해짐

 

back-to-back 테스트(동일 결과면 OK, 다르면 결함 존재)

프로토타이핑 프로세스

15. 폐기용 프로토타입(Throw-away prototypes)
- 프로토타입은 개발 후 폐기되어야 : 제조 시스템(production system)을 위한 적절한 기반이 되지 못하기 때문에
  1) (보안성, 신뢰성 등의) 비기능적 요구사항을 만족시키기 위해 프로토타입을 손질할(tune) 수 없음
  2) 일반적으로 프로토타입에 대한 문서는 없음
  3) 프로토타입의 구조는 보통 많은 변경으로 인해 낙후됨(degraded)
  4) 프로토타입은 조직의 품질 기준(표준)에 미치지 못하는 경우가 다반사