[정보시스템 설계] RAD와 SDLC와의 비교

 

전통적인 SDLC의 단계들과 동일한 단계들이 RAD에도 포함이 되어있습니다. 그러나 RAD에서 이러한 단계들은 서로 결합된 형태로 보다 간결한 개발 기법을 제공합니다.

 

---

RAD의 계획 및 설계 단계들은 단축되어 있는데, 그 이유는 RAD가 비즈니스 분석 및 시스템 성능에 관한 구체적인 이슈들에 대한 관심 대신에 시스템 기능과 사용자 인터페이스에 대한 요구사항에 초점을 맞추기 때문입니다.

 

또한 RAD는 일반적으로 다른 시스템과 독립적으로 개발되는 시스템에 적용도니느데, 따라서 시스템 설계 및 개발 과정 동안 기존의 표준들과 시스템과의 협력 작업에 대한 시간 소모를 제거할 수 있습니다. 일반적으로는 RAD의 특성은 SDLC 프로세스들의 일련의 절차와 구조에 비해, 덜 복잡하고 병행되는 상이한 작업들이 더 많으며, 프로토타이핑을 사용하는 경우가 더 많다는 것입니다. 

 

RAD의 개발주기에서 반복 메커니즘은 설계와 개발 단계에 제한되어 있다는 점에도 유의하여야 합니다. RAD를 따르는 경우, 설계가 시작된 직후 계획 단계로 되돌아오는 것은 가능은 하지만, 이러한 경우는 거의 드뭅니다. 이와 마찬가지로, 인도 단계 (cutover phase: 시스템이 사용자에게 전달되는 단계)로부터 개발 단계로 되돌아 오는 것은 가능하지만, RAD는 이러한 반복 과정을 최소화하도록 설계되어 있습니다. 

 

---

 

※ RAD는 전통적인 시법을 사용하여 개발하는 시스템에 비해 개발 과정 전반에 걸쳐 높은 수준의 사용자 공감대 및 참여를 요구하고 있는데, 이로 인해 RAD는 사용자 집단에게 즉각적으로 수용되어야 하는 시스템 개발에 적합하며, 따라서 인도가 보다 쉽게 이행될 수 있습니다.

 

 

 

긴 글 읽어주셔서 감사합니다.

 

---

 

그러면 더 나아가서 다음 포스트에서는 "참여 설계"에 대해서 자세하게 예와 함께 기록하려고 합니다. 

 

이 포스트는 "Essentials of Systems Analysis and Design" 책의 내용을 참조 및 공부한 것을 바탕으로 제가 이해한 정보를 추가하여 쓰여졌습니다.