[소프트웨어공학] 소프트웨어 프로세스3 ( 프로세스 반복 )

 4.2 프로세스 반복

 모든 대형 소프트웨어 프로젝트에서 변경은 필연적이다. 시스템을 구매하는 비즈니스가 외부의 압력에 반응함에 따라 시스템 요구사항은 변경된다. 관리 우선순위도 변경된다. 새로운 기술이 출현함에 따라 설계와 구현도 변경된다. 이것은 소프트웨어 프로세스가 한 번에 끝나는 프로세스가 아니라는 것을 의미하며, 오히려 시스템이 변경 요구에 반응하고 재작업함에 따라 프로세스 활동은 규칙적으로 반복된다.

 

 1. 점증적 인도(incremental delivery) : 소프트웨어 명세화, 설계, 구현이 여러 개의 증분으로 나누어져서 개발된다.

 2. 나선형 개발(spiral development) : 시스템 개발은 나선형의 안에서 밖으로 향해서 최종 개발 시스템에 이른다.

 

 반복적인 프로세스의 기본은 명세서가 소프트웨어와 연계되어 개발된다는 것이다. 그러나 이것은 완전한 시스템 명세서가 시스템 개발 계약의 일부분인 많은 조직의 구매 모델과 상충된다. 점증적 방법에서는 최종 산출물이 지정될 때까지 완전한 시스템 명세서가 존재하지 않는다. 이것은 정부 조직과 같은 대형 고객이 수용하기 어려운 새로운 형태의 계약을 요구한다. 

 

 

 

 4.2.1 점증적 인도

 폭포수 개발 모델은 설계를 시작하기 전에 고객이 요구사항을 확정하고 구현하기 전에 설계자가 설계 전략을 확정하는 과정을 거친다. 요구사항에 대한 변경은 명세화, 설계, 구현의 재작업을 필요로 한다. 그러나 설계와 구현의 분리는 변경을 수용할 수 있는 양질의 문서 시스템을 필요로 한다. 반대로 진화적 방법은 요구 분석과 설계상의 결정을 지연시키며, 구조적이지 못하고 이해와 유지보수가 어려운 소프트웨어를 유도한다.

 

점증적 인도

 

 점증적 인도는 이러한 모델의 장점을 결합한 중간적인 방법이다. 점증적 개발 프로세스에서 고객은 개괄적으로 시스템에서 제공할 서비스를 식별한다. 그들은 어떤 서비스가 가장 중요하고 중요하지 않은지를 인식한다. 여러 개의 인도될 증분(increment)을 정의하고 각 증분은 시슽메 기능의 부분 집합을 제공한다. 각 증분에 대한 서비스의 할당은 우선순위가 가장 높은 서비스를 먼저 인도하는 서비스의 우선 순위에 좌우된다.

 시스템 증분이 식별되면, 첫 번째 증분에서 인도된 서비스에 대한 요구사항이 상세하게 정의되고, 증분이 개발된다. 개발하는 동안에 나중의 증분을 위한 추가적인 요구 분석이 일어난다. 그러나 현재의 증분에 대한 요구사항은 받아들여지지 않는다.

 일단 증분이 완성되고 인도되면, 고객에게 서비스를 시작한다.이것은 시스템 기능의 일부분이 인도되었다는 것을 의미한다. 그들은 추가적인 증분에 대한 요구사항을 명확하게 하는 것을 돕기 위해 시스템을 실험할 수 있다. 새로운 증분이 완성됨에 따라, 기존의 증분과 통합되고 시스템 기능은 각각의 인도된 증분과 함께 확장시킨다. 공통의 서비스는 프로세스의 초기에 구현되거나 증분에 의해서 요구되는 기능에 따라 점진적으로 구현될 수 있다.

 점증적 개발 프로세스는 다음과 같은 장점이 있다.

 

 1. 고객은 전체 시스템이 인도될 떄까지 기다릴 필요가 없다. 첫 번째 증분은 고객의 가장 중요한 요구사항을 만족시키기 때문에 소프트웨어를 즉시 사용할 수 있다.

 2. 고객은 초기의 증분을 프로토타입으로 사용하고 추후 시스템 증분에 대한 요구사항의 정보를 얻을 수 있는 경험을 획득할 수 있다.

 3. 전체 프로젝트 실패에 대한 위험이 적다. 문제가 어떤 증분에서 생길 수도 있지만, 고객에게 성공적으로 인도될 확률이 높다.

 4. 우선순위가 가장 높은 서비스가 먼저 인도되고 추후의 증분이 그것과 통합되기 때문에, 가장 중요한 시스템 서비스가 가장 많이 시험된다. 이것은 고객이 시스템의 가장 중요한 부분에서 소프트웨어 실패를 만날 확률이 낮아진다는 것을 의미한다.

 

 그러나 점증적 인도에도 문제가 있다. 증분은 비교적 작아야 하며(20,000 라인 이하의 코드), 각 증분은 시스템 기능을 제공해야 한다. 고객의 요구를 적절한 크기의 증분으로 나누는 것이 어렵다. 더군다나, 대부분의 시스템은 시스템의 여러 부분에서 사용될 기본적인 기능을 요구한다. 증분이 구현될 때까지 요구사항이 상세하게 정의되지 못하기 때문에 모든 증분에서 필요한 공통의 기능을 찾아내는 것이 어렵다.

 이러한 점증적 방법의 변형을 익스트림 프로그래밍 (extreme programming) 이라고 한다. 이것은 매우 작은 증분을 개발하고 인도하는 것으로서, 이 프로세스에 고객이 참여하고, 계속적으로 개선과 프로그램이 이루어진다.

 

 4.2.2 나선형 개발

 소프트웨어 프로세스의 나선형 모델은 뵘에 의해 제안되었다. 소프트웨어 프로세스를 한 활동에서 다른 활동으로의 회귀를 포함한 일련의 활동으로 보기보다는, 소프트웨어 프로세스를 나선형으로 나타낸다. 나선에 있는 내부 반복은 시스템 타당성과 관련이 있으며, 그 다음 반복은 요구사항 정의, 그 다음은 시스템 설계와 관계가 있다.

 나선에 있는 각 반복을 네 부분으로 나타내면 다음과 같다.

 

 1. 목표 설정 : 프로젝트의 단계에 대한 목표가 설정된다. 프로세스와 제품에서의 제약 조건이 식별되고, 상세 관리 계획이 수립된다. 프로젝트 위험(risk)이 식별되고, 위험의 종류에 따라 대안 전략이 수립된다.

 2. 위험 평가 및 감소 : 식별된 각 위험의 종류에 따라, 상세 분석이 수행된다. 위험을 줄이기 위한 단계가 취해진다. 예를 들어 만약 요구사항이 부적절하다는 위험이 있으면, 프로토타입 시스템을 개발할 수도 있다.

 3. 개발과 검증 : 위험 평가 후에 그 시스템에 대한 개발 모델이 선택된다. 에를 들어 만약 사용자 인터페이스에 위험이 많으면, 적절한 개발 모델은 진화적 프로토타핑일 것이다. 만약 안전성 위험이 주요 고려사항이라면, 정형 변환 기법에 기반한 개발이 가장 적당할 것이다. 주요 위험이 서브시스템 통합이면 폭포수 모델이 적당할 것이다.

 4. 계획 수립 : 프로젝트가 검토되고, 나선에 대한 추가 반복을 수행할지에 대한 결정이 이루어져야 한다. 만약 계속하기로 했다면, 프로젝트에 대한 다음 단계 계획이 수립되어야 한다.

 

 

 

 나선형 모델과 다른 프로세스 모델의 주요 차이점은 나선형 모델에서의 위험에 대한 분명한 인식이다. 비공식적으로, 위험은 단지 무엇인가 잘못되어 간다는 것을 의미한다. 예를 들어 만약 새로운 프로그래밍 언어를 사용할 의도라면, 위험은 이용가능한 컴파일러가 믿을 수 없고, 생성된 목적 코드가 효율적이지 못하다는 것이다. 일정과 비용 증가와 같은 프로젝트 문제에서 생긴 위험 결과 때문에 위험 최소화가 가장 중요한 프로젝트 관리 활동이다. 

 나선의 사이클은 성능 및 기능과 같은 목표를 다듬는 일로써 시작된다. 그것 각각에 부과된 제약과 목표를 성취하기 위한 도 다른 방법들이 고려된다. 각 목표에 대한 대안이 평가되고 프로젝트 위험 원인을 찾아낸다. 그 다음 단계는 좀 더 상세한 분석, 프로토타이핑, 시뮬레이션과 같은 정보 수집 활동에 의해서 이러한 위험을 해결하는 것이다. 일단 위험이 평가되면, 개발이 진행되고, 그 프로세스의 다음 단계에 대한 계획 수립 활동이 이어진다.