Reti's Log

SDLC 모델

소프트웨어 개발을 위한 프로세스에는 많은 유형이 있지만, 

기본적인 활동은 공통적으로

소프트웨어 명세화 → 소프트웨어 설계와 구현 → 소프트웨어 검증 → 소프트웨어 진화 → 소프트웨어 폐기 의 단계를 가지게 된다.

이 때, 특정 관점에서 소프트웨어 프로세스를 단순화하여 표현한 모델을

소프트웨어 개발 프로세스 모델(SDLC 모형)이라고 하며, 이를 프로세스 패러다임이라고도 하는데,

특정 소프트웨어 공학의 프로세스를 만들기 위해, 

계획부터 폐기까지의 전 과정을 표현한 하나의

프레임워크라고 생각할 수 있다.

이 SDLC 모형은 전통적인 모형인 "폭포수 모델(Waterfall model)" 을 시작으로,

사용자의 의견을 중요시하는 "프로토타이핑 모델(Prototyping model)",

단계적 개발 방법인 "점증적 개발 모델(Incremental model)",

위험관리를 중요시하는 "나선형 모델(Spiral model)", 

테스트와 검증을 강조하는 "V 모델(V model)", 

출시일을 정확히 맞추기 위한 "일정 중심 설계 모델(Design-to-schedule)" 등

다양한 방법으로 발전해 왔다.

폭포수 모델(Waterfall model)

폭포수 모델

소프트웨어 개발생명주기(SDLC; Software Development Life Cycle)에 기반하고 있는 소프트웨어 개발 기법으로, 워터폴 모델·폭포수 모형·선형순차 모형·단계적 생명주기라고도 한다. 한 번 떨어지면 거슬러 올라갈 수 없는 폭포수와 같이 소프트웨어 개발도 각 단계를 확실히 매듭짓고 다음 단계로 넘어간다는 의미에서 붙여진 명칭이다. 전통적인 시스템 생명주기 모델로 소프트웨어를 개발할 때 가장 널리 사용된다. 

개발 과정이 명확하게 단계화되어 있다. ①타당성을 분석하고, ②사용자의 기능·성능·신뢰도 등에 대한 요구를 분석하며, ③소프트웨어를 설계하고, ④프로그래밍을 한 뒤, ⑤통합 테스트를 거쳐, ⑥소프트웨어를 운용하고 유지·보수시키는 등의 단계를 거친다. 각 단계가 명확하여 관리가 쉬우나 요구 분석에 상당한 시간이 소요되며, 일단 분석이 끝나면 수정이 어렵다는 단점을 지닌다. 또 개발 단계마다 피드백이 발생하므로 순차적인 흐름을 따라가기 어려우며, 규모가 크고 복잡한 시스템에는 적합하지 않다. 이러한 단점을 보완하기 위하여 모델을 변형하거나 단계 통합 또는 새로운 단계 추가 등이 시도되고 있다. 

[폭포수 모델]

폭포에서 물이 아래로만 내려오듯이 각 단계를 순차적으로 표현한 모델로, 원칙적으로는 병행되어 진행되거나, 거슬러 반복 진행되어서는 안되나, 실제 프로젝트에 적용하다보면, 불가피하게도 피드백을 통해 거슬러 반복되는 경우가 많이 있다.

이 폭포수 모델은 응용분야가 단순하거나, 잘 알고 있는 경우에 적합하며, 생명주기 전반에 걸쳐 변경이나 진화가 예상되지 않는, 비교적 위험이 적은 프로젝트에 적합한 모델이다.

- 장점 : 복잡성이 낮고 진행과정을 세분화하여 관리가 용이함. 

         사례가 풍부하고, 전체 과정에 대한 이해가 용이함.
- 단점 : 소프트웨어의 거대화 및 요구사항의 구체화가 어려움. 

        후반부에 전체 설계를 뒤엎을지도 모르는 리스크가 표면화                       되는 경우가 많음. 

         시스템이 개발완료되는 시점에야 완성이 가능. 

        각 진행단계에서 문제 발생시 그 이전단계로 피드백이 되는                     경우가 발생.

프로토 타입

원래의 형태 또는 전형적인 예, 기초 또는 표준이라는 뜻으로 HCI 분야에서는 시제품이 나오기 전 제품의 원형(archetype)을 의미한다. 프로토타이핑(prototyping)은 개발 초기에 시스템의 모형을 간단히 만들어 사용자에게 보여 주고, 사용자가 기기나 시스템을 직접 사용해 보게 한 뒤, 기능의 추가, 변경 및 삭제 등을 요구하면 이를 즉각 반영해 정보 시스템 설계를 다시 하고 프로토타입을 재구축하는 과정을 사용자가 만족할 때까지 반복해 나가면서 시스템을 개선시켜 나가는 방식이다. 이처럼 프로토타이핑은 그 원형 개발 접근법의 하나로 널리 쓰이고 있다. 이는 개발자와 사용자의 의사소통 채널이고 중요한 점은 개발자와 사용자 간 상호이해와 지식 교환을 위한 작업이라는 것이다.

프로토타입은 시스템의 미완성 버전 또는 중요한 기능들이 포함되어 있는 시스템의 초기 모델이다. 이 프로토타입은 사용자의 모든 요구사항이 정확하게 반영될 때까지 계속해서 개선·보완된다. 실제로 많은 애플리케이션들이 지속적인 프로토타입의 확장과 보강을 통해 최종 설계가 완성된다. 프로토타이핑은 시스템의 초기 모델을 세우고 다듬고, 다시 세우고 다듬고 하는 반복 과정을 통해서 이루어진다. 그러나 프로토타이핑은 무계획적인 반복 과정을 지양하고 계획된 반복 과정을 통해서 한 과정이 끝날 때마다 사용자의 요구를 정확하게 반영한 버전이 나오게 된다. 프로토타이핑의 가장 큰 장점은 최종 사용자가 초기 모델을 사용하면서 평가할 수 있도록 도와준다는 데 있다. 사용자는 프로토타입을 실행시키면서 장·단점과 필요 없는 부분 또는 반드시 첨가해야 할 부분들을 파악할 수 있다.
프로토타이핑은 그 목적에 따라 여러 가지 형태가 있는데, 크게 '실험적(experimental) 프로토타입'과 '진화적(evolutionary) 프로토타입' 두 가지로 나눌 수 있다. 실험적 프로토타입은 실제 개발될 제품군을 직접 개발해 요구사항을 검증하는 모델이다. 진화적 모형은 요구 분석 도구 활용 및 개발된 프로토타입을 지속적으로 발전시켜 최종 제품을 개발하는 모델이다. 이 프로토타입은 단계마다 사용자의 요구를 분석하며 프로토타이핑을 반복하기 때문에 기존의 전통적인 생명주기를 무시하게 된다. 결국 진정한 프로토타입은 바로 진화적 프로토타입이 되어야 할 것이다.

 1단계
기본적인 사용자 요구사항을 분석한다. 시스템 설계자는 기본 요구사항이 도출되기까지 사용자와 함께 작업한다.

 2단계
시스템 설계자가 위의 단계에서 도출된 요구사항을 만족시키는 프로토타입을 프로그래밍 언어 또는 알고리즘 도구를 이용해 개발한다. 이때 프로토타입은 앞으로 개발될 시스템의 가장 핵심적인 기능 위주로 개발된다.

 3단계
사용자가 개발된 프로토타입을 실제 사용함으로써 요구사항이 이행되고 있는지를 확인하며 프로토타입의 보완을 위한 여러 가지 제안을 하게 된다.
 4단계
프로토타입의 수정과 보완이 이루어진다. 시스템 설계자는 사용자가 요구한 모든 제안사항과 이에 따르는 보완작업을 하게 된다. 프로토타입이 수정된 후에는 3단계로 돌아간다. 사용자가 만족할 때까지 3단계와 4단계는 계속 반복된다.

 5단계
가장 중요한 단계로 평가는 고객과 개발자가 함께해서 개발될 소프트웨어의 요구사항을 정제하는 데 중요한 정보로 활용한다.

프로토 타입의 장단점 

프로토타입의 가장 큰 장점은 아이디어의 강력한 쌍방향 커뮤니케이션을 통해 아이디어를 스케치하고 다양한 사람의 참여와 영감을 불러일으킬 수 있다는 데 있다. 이러한 과정을 통해 개발 주기에 획기적 단축을 가져오게 되고 사용자의 요구사항을 정확히 파악해 사용자의 만족도를 증가시킬 수 있다. 많은 경우 제품이나 시스템 오류는 부정확한 사용자 분석에서 기인하는데, 오류를 초기에 발견할 수 있고 변경이 용이하다는 강점이 있다. 효과적인 프로토타이핑은 의사소통 방법과 사용자 참여환경을 활성화해 사용자의 기대를 충족시키는 결과를 가져온다.

그러나 프로토타이핑의 핵심 장점인 효율적 커뮤니케이션이 단점으로 부각될 수도 있다. 시스템의 유지 보수나 기기의 업데이트에 필수적인 시스템의 문서화 과정이 지나치게 축소되거나 생략될 수 있다. 단기적으로 볼 때는 이런 문서들이 별로 도움이 되지 않을 수 있으나 장기적으로 시스템의 수정과 보수가 필요할 때, 시스템에 관련된 문서가 없다면 유지 보수에 부가적인 노력이 필요해 결국 비용이 훨씬 많이 들 수 있다. 즉, 프로토타이핑의 장점인 언제든지 변경이 가능한 유연성이 향후 시스템의 변경이나 업데이트에서는 시간과 비용을 요구하게 되는 것이다.

다른 단점으로는 프로토타이핑을 할 때 그 범위를 정하는 것이 모호하다. 모든 기능이 다 작동되는 시제품을 만든다면 확실한 테스트와 코드 재사용성을 높일 수 있지만 개선안을 미리 뽑는다는 취지에서 벗어나게 된다. 반대로 최소한의 기능만이 작동되는 시제품을 만들고 테스트하기에는 테스트 범위가 협소하고 코드 재사용성이 떨어질 수 있다.

나선형 모델

나선형 모델은 이미 앞선 SDLC 포스트에서  "뺑뺑이 모델" 로 소개한 바 있습니다.

이 뺑뺑이라는 것은 두 가지 의미가 있는데, 바로 반복적인 모델 이라는 것과

프로세스를 그려보면 단계별로 뱅뱅 돌며 진행되는 모양이 나타난다는 점 입니다.

나선형 모델의 정의

시스템 개발시 위험을 최소화 하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델

여기서의 키워드는 "위험 최소화" 와 "점진적" 입니다.

이 모델에서는 위험의 최소화를 위해 점진적으로 진행이 된다는 것 입니다.

이 위험 최소화의 의미는 바로 "위험 분석" 이라는 단계에 있습니다.

나. 나선형 모델의 특징

- 리스크 최소화를 위해 "위험분석" 단계가 존재

- 점진적으로 단계를 반복 수행해 나가는 모델

- 위험 부담이 큰 대형 시스템 구축에 적합

간단히 정리 하자면 "위험 분석 단계"를 포함한 개발 단계를 점진적으로 반복하여 개발을 완성하는 모델 입니다.

나선형 모델의  단계는 

"목표설정->위험분석->구현및 테스트->고객평가 및 다음단계 수립" 으로 구분

1.목표설정(Determine Objective)

목표설정 단계에서는 고객의 요구사항 분석 및 타당성 검토, 프로젝트 수행 여부 결정을 하게 됩니다.

그리고 프로젝트 각 단계에 대한 특정 목표를 수립 합니다.

이 목표 부분은 한 싸이클이 돌고 다음 싸이클이 진행되면 변경되게 됩니다.

그러므로 첫 싸이클, 두번째 싸이클, 그 이후 싸이클에 따라 각 목표의 단계를 현실적으로 정하는 것이 중요 합니다.

2.위험분석(Risk Analysis)

위험분석은 프로젝트 진행시 고객 요구사항을 기반으로 예측되는 위험 사항에 대해 추출하고,

이에 대한 대처 방안을 수립하는 단계 입니다.

이 단계의 목적은 위험 사항을 조기에 추출하고 해결하여, 위험을 최소화(minimize) 한다는 것 입니다.

3.개발 및 검증(Development&Test)

위험 분석이 완료 되면, 구축하려는 시스템과 개발 환경에 맞는 개발 모델을 선택 합니다.

특별한 상황이 아니라면 일반적으로 사용하는 모델을 선택 하게 됩니다.

예) 폭포수 모델(Waterfull Model), 프로토타이핑 모델(Prototyping Model)

그리고 선택한 모델의 개발 방법론에 따라 개발 절차가 진행 됩니다.

개발 진행 중에는 단위(Unit)테스트가, 그리고 이후에는 통합(Integration)테스트, 시스템(System) 테스트가 이루어 집니다.

* 이 부분에 대해서는 이전 포스트에서 귀따갑게 이야기 했을 것 입니다.

* 최소한 개발중에 단위테스트는 이 단계에서 이루어 져야 합니다.

4.고객평가 및 다음단계수립(Evauation/Plan the next Iteration)

이렇게 개발과 테스트가 끝난 내용을 고객이 평가하여, 추가 반복에 대한 여부를 결정 하게 됩니다. 보통은 이 단계에서 인수테스트가 이루어지고, 만족 결과에 따라 추가 반복의 여부가 결정 됩니다.

나선형 모델의 장단점

나선형 모델의 장점

나선형 모델은 위험 관리로 인해 위험성이 큰 프로젝트를 수행 할 수 있습니다.

그리고, 고객의 요구사항을 보다 더 상세히 적용 할 수 있으며, 

변경되는 요구사항에 대해서도 적용이 가능 합니다.

또한 완성품에 대한 고객 만족도와 품질이 높습니다.

나선형 모델의 단점

하지만 나선형 모델은 프로젝트 기간이 오래 걸린다는 점과,

반복 단계가 길어질수록 프로젝트 관리가 어렵다는 단점이 있습니다.

또한 위험 관리가 중요한 만큼 "위험관리" 전문가가 필요 합니다.

나선형 모델의 활용 방안

나선형 모델의 활용방안이라기 보다는 성공적인 적용을 위한 필수 사항이라고 봐야 겠습니다.

모델 진행시 각 싸이클의 단계별 목표를 명확히 설정해야 합니다.

같은 단계라도 한 싸이클이돌면 진행된 내용과 추가 요구사항민 개선사항이 생기기 마련입니다. 이에 따른 목표를 확실히 설정하며 현행화 시켜줘야 합니다.

단계별 산출물 관리계획을 구축하여 프로젝트가 길어지더라도 프로젝트 관리에 어려움이 발생 해선 안됩니다.

반복 사이클이 진행되고 이에 대한 프로세스가 진행 될수록 산출물 관리에 어려움이 따릅니다. 이때 잘못된 산출물 관리는 프로젝트 진행 및 향후 목표, 그리고 개발 과정에 대한 내용에 혼선을 줄 수 있습니다. 각 싸이클과 단계별로 넘버링된 문서 체계와 각 단계 종료 후 철저한 산출물 검증이 필요 합니다.

상세한 위험 분석 및 시뮬레이션을 통해 해당 위험에 대한 회피 및 대안을 마련해야 합니다.   나선형 모델의 장점이자 가장 큰 특징은 바로"위험관리" 입니다.

그만큼 위험 관리에 많은 노력을 기울여야 하며, 이에 대한 철저한 대비를 갖추어야 합니다.

이 부분이 명확하게 실천되지 않는다면 그저 "느려터진 프로토타이핑 모델" 이 되어버릴 것 입니다.

RAD 모델

RAD모델의 정의

RAD(Rapid Application Development) Model 은 단어 그대로 매우 빠른 어플리케이션 개발 방법론 입니다.

RAD는 의 빠른 속도의 개발은 바로 강력한 소프트웨어 개발 도구로 부터 나옵니다.

그래서 RAD의 정의를 한줄로 내리자면 아래와 같습니다.

강력한 소프트 개발 도구를 이용하여 짧은 주기로 개발을 진행하는 순차적 소프트웨어 개발 프로세스

여기서 순차적이라는 것을 강조한 이유는, 개발의 속도를 어떤 병행방법에 의해서 내는것이 아님을 강조하기 위함 입니다.

이 모델의 특징은 분석, 설계, 개발 과정을 CASE tool 이나, 4세대 언어를 통해 구현 합니다.

RAD모델의 특징

- CASE(Computer Adied Software Engineering) 도구를 이용한 시스템 개발 

- Prototyping 사용 및 소프트웨어 요구사항 정의, 분석, 설계 과정에 사용자의 적극적인 참여

- 개발기간이 60일~90일 정도로 짧다.

- 기술적으로 위험이 적고 빠른 개발이 요구될때 사용이 적합

RAD 모델의 특징을 키워드로 보자면 "CASE TOOL", "빠른 개발", "사용자의 적극참여" 입니다.

사실 사용자의 적극 참여는 프로토타입 모델의 특징인데, 이 모델은 프로토타입을 사용하므로 사용자의 적극 참여를 요구 합니다.

또한 빠른 개발이 특징인 만큼 꼼꼼하게 테스트나 위험분석을 할 수 없으므로 위험이 적고 빠른 개발이 필요한 프로젝트에 적합 합니다.

*case tool :  소프트웨어 개발을 돕는 툴로써 소프트웨어의 설계, 개발을 돕는다.

*분석설계 : UML 툴, VISIO

*DB설계 : ER-WIN, DB Disigner

*구현 : Visual Studio, Eclipse, Cloud9

목표

전통적 생명주기의 목표는 고품질의 소프트웨어 구현이 목표인 반면,

RAD는 고객의 핵심 요구사항 만족과 개발기간 단축 입니다.

개발 규모

전통적 생명주기 방법론은 대규모의 프로젝트에 적합 하지만, 

RAD는 민첩하고 속도감 잇는 프로젝트, 소규모 프로젝트에 적합 합니다.

당연히 개발 인원이 적은 프로젝트에 이용 됩니다.

분석/설계

전통적 생명 주기는 각 단계가 완벽해야 합니다. 분석/설계 역시도 완벽해야 합니다.

두번 할 일이 아니기 때문이죠.

반면 RAD는 개략적인 분석/설계를 합니다. 사용자와 함께 프로토타입을 개발하고

개선하면서 요구사항 분석과 설계는 계속 변화하기 때문입니다.

그리고 분석/설계에 완벽을 기할 만큼의 시간을 내주지도 않습니다.

기법

전통적 생명 주기는 절차지향적, 하향식, 구조적 기법을 사용 합니다.

반면 RAD는 JRP(Joint Requirement Planning), 

JAD(Joint Application Design), Time-boxing 기법을 사용 합니다.

특징

전통적 생명주기는 하향식에 절차지향적 접근이 특징이라면,

RAD는 사용자의 지속적 참여, 빠른 개발, CASE Tool 사용 입니다.

  RAD 모델의 개념도

RAD 모델 장단점

장점

요구사항의 완전한 이해와 프로젝트 범위의 명확한 설정시 신속한 개발 가능.

COTS 기반 개발을 활용하여 많은 응용 시스템이 매우 낮은 비용으로 구현 가능.

단점

위험성이 높거나 대규모 프로젝트에는 부적합.

구성원의 책임감이 낮을 경우 실패가능성이 있다