본문 바로가기
카테고리 없음

[소프트웨어 공학] 소프트웨어 생명 주기 - 폭포수 모델

by 세개남 2024. 5. 22.
반응형

폭포수 모델

 

폭포수 모델은 요구분석, 설계, 테스트 등의 작업을 순서대로 쭉 헤나가는 프로세스입니다. 1970년대 많이 소개되어 산업계에서 보편적으로 사용되어 해오던 방식입니다. 원래는 1950년대 항공 방위 소프트웨어 시스템 개발 경험으로 소개되었던 것입니다.

원해 폭포수 모델은 폭포에서 내려오는 물이 아래로 떨어지듯이 각 단계가 순차적으로 진행되는, 즉 병행되어 진행되거나 거슬러 반복 진행되는 경우가 없습니다. 그러나 실제 사용되고 있는 폭포수 모델은 아래 그림처럼 표현한 것처럼 각 단계의 결과가 확인된 후에 다음 단계로 넘어갈 수 있기 때문입니다. 이는 사용자의 의견이 다르거나 중간 결과를 점검한 결과 전 단계의 작업에 결함이 있다면 다시 수정하도록 전 단계로 돌아가는 점이 있습니다.

 

 

폭포수 모델의 큰 특징은 작업 단계가 단순하다는 점입니다. 작업 단계가 복잡하고 반복되는 경우 일정이나 결과에 대한 예측이 어렵지만 단순한 작업 단계라면 쉽게 예측할 수 있습니다. 또한 비전문가라 하더라도 시스템을 개발하는 과정에서 이해하기가 쉽습니다. 소프트웨어 시스템을 구축하는 큰 작업이 명확하게 분리된 단계로 나누어 있습니다. 또한 다음 개발 단계로 들어가기 전에 필요한 중간 산출물이 명확하게 제시 되어있습니다. 대부분의 복잡한 프로세스 모델도 엄밀하게 말하며 폭포수 모델에 반복 단계 및 새로운 단계를 추가하는 것이라 할 수 있습니다.

폭포수 모델을 채택한다면 각 단계가 끝난 후에 나와야 할 결과물을 명확히 정의해야 합니다. 이를 생산하기 위하여 각 단계에 사용된 것을 방법이라 하며 개발집단의 특수성을 고려하여 정합니다. 프로젝트 진행 과정을 예측하고 확인하기 위하여 결과물을 정확히 정의하는 것이 중요합니다. 결과물의 구조가 표준화되어 있다면 품질의 향상에도 크게 도움이 됩니다.

폭포수 모델의 두번째 큰 특징은 작업이 일렬로 나열되어 있어 직능 중심의 프로젝트 조직이 가능하다는 점입니다. 요구분석, 설계, 구현, 테스트 등이 각 작업을 전문으로 하는 팀이 전담하여 마치 파이프라인과 같은 형태로 작업이 가능합니다.

세 번째로 폭포수 모델은 크고 복잡하고 오래 지속되는 프로젝트에 적합합니다. 예를 들면 공장에 제어하는 시스템이나 우편물을 정리하고 분류하는 시스템 개발에 적합합니다. 이런 시스템은 하드웨어가 생성하는 이벤트들에 반응하여야 하며 대량의 입력 데이터를 처리하고 하드웨어 장치들을 제어하여야 합니다. 대체로 이런 시스템의 기능과 성능은 장치 제조사와 고객이 협력하여 정하게 됩니다. 이런 시스템을 개발하는 프로젝트는 대부분 현재 시스템의 기능과 성능, 보안을 개선하는 것입니다. 따라서 개발자들이 애플리케이션에 대한 경험과 지식도 있고 고객이 무엇을 원하는지 잘 알고 있습니다. 또한 요구 사항이 크게 변하지 않습니다. 일단 개발 용역 사업이 결정되면 일수 테스트 단계가 될 때까지 고객은 장치를 만져볼 수 없기 때문입니다. 폭포수 모델은 각 작업 단계 종료시점에 시스템이 신뢰할 만한지 성능 제약을 만족하는지 엄격하게 검사하여 동결시킵니다.

폭포수 모델은 여러 가지 단점이 있습니다. 첫째 설계와 코딩 및 테스트를 지연시킬 우려가 있습니다. 처음 단계들이 지나치게 강조되므로 불필요한 문서들을 작업하는 데 많은 노력을 소모하는 경우가 있습니다. 실제 각 단계에서 시스템을 보는 관점이 다르며 이를 전환하는 데 드는 노력이 적지 않기 때문입니다.

폭포수 모델의 두 번째 단점은 각 단계와 일정이 엄격하여 요구 변경을 수용하기 어렵습니다. 시스템의 요구가 설계 단계로 넘어가기 전에 동결되기 때문입니다. 대부분의 경우 개발하는 동안 비즈니스 환경이 변하고 규칙이나 표준이 바뀔 구 있고 요구 사항을 완벽하게 찾아내기가 어렵습니다. 또한 요구를 동결하려면 하드웨어를 선택하여야 하는데 대규모 프로젝트에서 이를 위하여 여러 해가 걸릴 수도 있습니다. 하드웨어를 미리 선택하였다면 하드웨어 기술 발전 속도가 빠르게 때문에 최종 소프트웨어는 없어져 버릴 하드웨어 기술을 사용할 수도 있습니다

전통적인 폭포수 모델을 따를 경우 다음에 설명할 프로토타입과 재사용의 기회가 줄어드는 단점이 있습니다. , 사용자의 요구에 대하여 정확한 의견을 듣기 어렵고, 시스템을 한 번의 계획과 실행으로 완성시키기 때문에 재사용을 위하여 결과들을 정비하고 개선시키는 기회가 없습니다.

일정에 융통성이 없으며 이전 단계로 회귀, 반복이 계속된다면 요소 자원이 계속 증가할 수 있습니다. 무엇보다 중요한 단점은 최종 단계까지 가 봐야 결과가 나온다는 점입니다. 전체 소프트웨어가 최종 단계에 가서 한꺼번에 출시되기 때문입니다. 만약 프로젝트가 중간에 취소된다면 투자한 비용을 회수할 수 없는 위험을 감수해야 합니다. 원시코드가 완성될 최종 단계까지 오류가 발견되지 않으면 수정 비용이 증폭될 우려도 있습니다.

결론적으로 폭포수 모델은 요구사항을 이미 잘 알고 있는 문제나 연국 중심의 문제를 다루는 소프트웨어 개발에 적합합니다. 또한 생명주기 전반에 걸쳐 변경이나 진화가 예상되지 않는 비교적 위험이 적은 프로젝트에 적합합니다. 여기서 위험이 적은 프로젝트는 프로젝트의 규모가 상당히 작은 프로젝트의 규모이거나 변경 가능성이 없는 프로젝트를 말합니다. 만약 변경을 하게 되면 모두 삭제를 하고 처음부터 다시 해야 하는 불상사가 일어나기 때문입니다. 그리하여 폭포수 모델은 아주 고전적인 모델이라고 할 수 있습니다.

 

참고자료 출처 : 새로쓴 소프트웨어 공학 (저자 : 최은만)

반응형