소프트웨어 공학 - 나선형 모델, 단계적 개발 모델, 통합 프로세스 모델(UP모델)

오늘 알아볼 모델들은 나선형, 단계적 개발, 통합 프로세스 모델들이다.

 

먼저 나선형 모델이다.

 

나선형 모델

개요

나선형 모델이란 이름에서 볼 수 있듯이 개발 과정이 뱅글뱅글 돌아 점점 완성도가 높은 제품이 만들어지는 모델이다.

이 나선형 모델은 전 포스팅에서 말했듯이 진화적 프로토타입 모델의 대표적인 예이다.

나선형 모델의 개발 방식은 프로토타입 모델에서 최종 프로토타입을 버리지 않고 계속 개발하여 최종 완성시킨다.

 

이 모델이 프로토타입 모델과 다른 점은 위험 분석 단계가 추가되었다는 것이다.

 

 

나선형 모델의 특성

나선형 모델은 초기 요구 분석 후 프로토타입 개발 이전에 위험 분석 단계를 거친다. 이렇게 만들어진 프로토타입을 사용자가 평가한 후 개발자가 추가 또는 수정 요구를 받아들여 위험 분석을 거쳐 2차 위험요소 발견 및 목록 작성 만든다.

이렇게 3차, 4차,.... n차를 거치는 동안 사용자의 요구가 충분히 반영된다.

 

여기서 위험분석 단계에서의 위험요소는 소프트웨어 개발 과정이 순조롭게 진행되는데 방해되는 것을 뜻한다.

예를 들면 빈번하게 변경되는 요구사항, 프로젝트 관리의 부재, 팀원들의 경험 부족 등이 있다.

 

이러한 위험 요소들을 확인하고 해결하려면 프로젝트 초기부터 실행이 가능하고 테스트가 가능한 시스템을 개발해 계속 확인해야 한다.

이 부분이 폭포수 모델과 프로토타입 모델과의 차이점이다.

 

즉, 나선형 모델에는 위험 요소를 최소화하기 위한 방법으로 개발 단계에 위험을 분석할 수 있는 과정이 존재하는 것이다.

 

정리하자면 나선형 모델은 폭포수 모델과 프로토타입 모델의 장점을 중심으로 위험 분석 단계를 추가하여 위험에 대한 문제 식별 및 해결 방법을 강조한 반복적 개발 모델이다.

 

 

개발 절차

1. 계획 및 요구 분석 단계

• 사용자의 개발 의도(요구 분석) 파악
• 프로젝트에 대한 명확한 목표 수립
• 제약 조건의 대안을 고려한 계획 수립
• 기능 요구 사항과 성능 같은 비기능 요구 사항을 정의 및 분석

2. 위험 분석 단계

• 위험 요소 발견 및 목록 작성
• 위험에 대한 예방 대책 논의
• 위험요소를 평가

소프트웨어 개발 시 위험 요소

위험 요소	위험 내용
개발자의 이직	프로젝트 수행 중 개발자의 이직
요구 사항 변경	요구 사항 확적 이후에 계속되는 변경 요구
발주사의 재정적 어려움	프로젝트 수행 중 발주사의 경제적 어려움
예상을 빗나간 투입 인력	처음에 예측한 인력보다 더 많은 인력을 필요로 하는 경우
개발 기간의 부족	처음에 예측한 개발 기간을 초과한 경우
개발비의 초과	처음에 예측한 개발비로 완료할 수 없는 경우

일반적으로 나타날 수 있는 위험요소는 위의 표와 같다.

 

3. 개발 단계

개발 프로세스의 설계와 구현

그냥 진짜 개발 단계이다.

 

4. 사용자 평가 단계

진화적 프로토타입 모델에서 매우 핵심적이고 중요한 부분이다.

개발이 반복적으로 이루어지는 이유도 이 평가 단계가 존재하기 때문이다.

 

프로토타입을 사용자가 확인하고 추가 및 수정될 요구사항이 있으면 다음 프로토타입을 개발 시 반영한다.

이렇게 사용자가 만족할 때까지 n번 반복하여 더 의상의 추가 및 수정 요구가 없으면 최종 제품을 만든다.

 

 

장점

• 갑작스럽게 돌출되는 위험으로 인해 프로젝트가 중단되는 상황이 발생할 확률이 적음
• 사용자의 요구가 충분히 반영되어 만들어지기 때문에 사용자의 불만이 별로 없음

단점

• 반복적으로 요구 분석, 위험 분석, 개발, 사용자 평가가 반복적으로 계속 진행되기 때문에 프로젝트 기간이 길어질 수 있음
• 반복 횟수가 많아질수록 프로젝트 관리가 어려움
• 위험 관리 전문가를 필요로 한다는 부담감이 있음

 

 

단계적 개발 모델

개요

이 모델에서는 개발자가 먼저 릴리스 1을 개발하여 사용자에게 제공하면 사용자가 개발된 릴리스 1을 사용한다.

그리고 사용자가 릴리스 1을 사용하는 동안 개발자가 다음 버전인 릴리스 2를 개발한다.

이렇게 개발과 사용을 병행하는 과정을 반복하여 완료한다.

이러한 단계적 개발 모델은 릴리스를 구성하는 방법에 따라 점증적 개발 방법과 반복적 개발 방법으로 나눌 수 있다.

 

점증적 개발 방법

점차적으로 개발 범위가 증가시키며 개발하는 방법이다.

비유를 들면 양식 코스 요리와 비슷하다.

일반적으로 양식 코스 요리를 먹을 때는 야채샐러드나 수프 같은 전채 요리를 먹은 후 스테이크 같은 메인 요리를 먹는다. 그다음 후식을 먹는다.

 

이와 같이 점증적 방법도 하나가 끝나면 그다음, 또 하나가 끝나면 그다음과 같이 하나씩 늘려간다.

또한 전체 시스템을 독립성이 높은 서브시스템으로 분할하고 중요하다고 생각되는 부분부터 차례로 개발한 후 그 일부를 사용하면서 개발 범위를 늘려간다.

 

점증적 개발 방법의 장점

• 한꺼번에 많은 비용이 들어가지 않는다.
• 새로운 시스템 전체를 한꺼번에 주었을 때 조직이 받는 충격을 완하 할 수 있다.
• 조직에 자연스러운 변화를 줄 수 있다.
• 이미 사용하고 있는 서브시스템이 있어 사용자에게 원하는 결과를 가져다줄 수 있다.

점증적 개발 방법의 단점

• 처음 설계부터 이후 개발할 서브시스템 들과의 연관성을 고려해야 한다.
• 위를 지키지 않을 시 기존에 개발된 서브시스템들과 통합이 어렵다.

 

 

반복적 개발 방법

계속 반복적으로 개발을 하여 품질을 증가시키는 방법이다.

말로 하면 잘 모를 텐데, 예를 들어주겠다.

 

예로는 도서 집필로 들 수 있다.

1장부터 10장까지 큰 줄거리를 중심으로 개괄적인 1차 원고를 작성한다. 그러고 다시 전체적으로 내용을 보강한다.

이런 과정을 몇 번 반복하여 만족할 만한 수준으로 원고가 완성되면 책으로 출간하는 것이다.

 

소프트웨어 개발에서도 마찬가지다. 초기에 시스템 전체를 일차적으로 개발한다. 그다음 각 서브 시스템의 기능과 성능을 변경 및 보강하여 완성도를 높인다. 이렇게 반복적으로 품질을 증가시킨다.

이러한 방식은 초기의 요구 사항이 불분명한 경우에 적합하다.

 

참고로 실제 개발에서는 점증적 개발 방법과 반복적 개발 방법을 함께 사용하는 경우가 많다.

 

 

통합 프로세스 모델 (UP모델)

개요

요즘의 소프트웨어는 규모도 매우 크고 복잡하다. 그리고 사용자의 요구도 빈번하게 변해 시스템이 이 변화에 유연하게 대처할 수 있어야 한다.

폭포수 모델은 각 단계별로 깔끔하게 정리되어 있지만 사용자의 요구 사항이 많으면 민첩하게 대처할 수 없다. 또 실제로는 단계를 거슬러 올라가야 하는 상황이 많아 힘들 수 있다. 

 

이런 폭포수 모델의 문제점을 해결하기 위해 등장한 것이 아래의 그림처럼 작업을 계속해서 반복 수행하는 반복적 개발 방법론이다.

R (Requirement) : 요구 사항 정의

A (Analysis) : 분석

D (Design) : 설계

C (Coding) : 구현

T (Test) : 테스트

M (Maintenance) : 유지보수

 

통합 프로세스(UP) 모델은 OMG(Object Management Group)가 공개한 UML(Unfied Modeling Language)과 함께 제안되어 통합된 프로세스이다. 이후 Ration사에 의해 RUP(Rational Unified Process)라는 이름으로 제품화, 현제 Rational사가 IBM에 통합됐다.

이건 그리면 더러워져서 못 알아 볼까봐 그냥 가져왔다.

 

절차

 

통합 프로세스(UP) 모델은 4단계의 개발 과정인 도입, 구체화, 구축, 전이로 나뉜다.

이건 도저히 그릴 수 가 없었다.

또한 각 단계는 여러 개의 반복 구간으로 나뉘며 각 반복 구간을 하나씩 개발한다.(개발 - 통합 - 테스트 - 실행)

그다음 실행 가능한 산출물을 도출해 위험요소 제거 여부 판단에 활용한다.

 

1. 도입 단계 (inception phase)

도입 단계는 구현 테스트 배치작업은 거의 없고, 비즈니스 모델링과 요구사항 정의 관련 작업이 가장 많이 이루어진다.

소프트웨어 개발 목표를 수립하며, 사업의 타당성, 비용 산정, 프로젝트 계획 등을 한다.

 

2. 구체화 단계 (elaboraion phase)

구체화 단계에서는 비즈니스 모델링과 요구 사항 정의 작업은 점차 줄고, 분석 및 설계 작업이 가장 왕성하게 이루어진다. 또한 설계 결과에 따른 코딩 작업도 이루어지고 단위 테스트도 조금씩 이루어진다.

아키텍처 수립, 요구 사항의 기능 요소에 대한 문서화 등을 한다.

참고로 이 단계가 끝나면 유스 케이스 모델은 대략 80% 정도 완료된다.

 

3. 구축 단계 (construction phase)

구축 단계에서는 구현 작업이 가장 많이 이루어진다. 당연히 가장 활동이 왕성한 것은 구현 작업이다.

또한 구현 결과에 따른 테스트 작업도 점점 늘어난다.

일부 완성된 것을 배치하는 양도 늘어난다.

단위 테스트 및 통합 테스트와 사용자 설명서를 작성 등을 한다.

 

4. 전이 단계 (transiton phase)

전이 단계에서는 완성된 제품을 사용자에게 넘겨주는 과정이다.

대부분의 작업이 거의 끝나가므로 배치 작업이 주를 이룬다.

사용자에게 배포 가능한 단위로 묶는 작업, 인수 테스트 등을 한다.

 

5. 공통 작업

통합 프로세스 모델(UP)에서는 모든 단계에서 공통적으로 이루어지는 작업이 있다.

• 분석, 설계, 구현, 테스트 작업을 공통으로 수행한다. 각 단계별로 수행하는 정도에는 차이가 있다.
• 각 작업을 반복 수행한다. 이는 통합 프로세스(UP) 모델의 가장 큰 특징이다. 구체화와 전이 단계는 2회씩, 구축 단계는 3회 반복한다.
• 형상 및 변화 관리, 프로젝트 관리, 환경 점검 등은 지속적으로 수행한다.

 

 

이렇게 나선형 모델과 단계적 개발 모델, 통합 프로세스 모델에 대해 알아보았다.

다음에는 에자일 개발 방법론에 대해 알아보고 오겠다.