검수요청.png검수요청.png

"폭포수 모델"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
(→‎같이 보기)
(→‎설계)
 
(사용자 3명의 중간 판 19개는 보이지 않습니다)
1번째 줄: 1번째 줄:
−
'''폭포수 모델이란 소프트웨어 개발시 단계적으로 개발하는 방법론을 말한다. 분석→설계→개발(디자인→퍼블리싱→프로그래밍)→테스트→적용→안정화의 단계를 따른다. 폭포수가 거슬러 올라갈 수 없듯이, 소프트웨어 개발도 반드시 앞 단계가 먼저 완료되어야 다음 단계의 개발을 진행할 수 있다는 뜻이다. [[소프트웨어 개발 방법론]](SDM)의 일종이다. 반대말은 [[애자일]] 개발 방법론이다.
+
'''폭포수 모델'''(Waterfall Model)이란 소프트웨어 개발 시 단계적으로 개발하는 방법론을 말한다. 분석→설계→개발(디자인→퍼블리싱→프로그래밍)→테스트→적용→안정화의 단계를 따른다. 폭포수가 거슬러 올라갈 수 없듯이, 소프트웨어 개발도 반드시 앞 단계가 먼저 완료되어야 다음 단계의 개발을 진행할 수 있다는 뜻이다. [[소프트웨어 개발 방법론]](SDM)의 일종이다. 반대말은 [[애자일]] 개발 방법론이다.
 +
 
 +
[[파일:폭포수모델.PNG | 썸네일 | 폭포수모델 구성도]]
 +
 
 +
==개요==
 +
폭포수 모델은 분석, 설계, 개발/구현, 시험, 운영 및 유지보수 등 전 과정을 순차적으로 접근하는 개발모델이다. 순차적으로 접근하며 단계별 검증을 진행한다. 그리고 각 단계를 종료할 때 검증 후에 다음 단계로 진행한다. 관리가 용이하며 문제점이 후반부에 발견될 수 있는 리스크를 가지고 있다.<ref name="자료1"> 도리의 디지털라이프, 〈[http://blog.skby.net/%ED%8F%AD%ED%8F%AC%EC%88%98-%EB%AA%A8%EB%8D%B8-waterfall-model/ 폭포수 모델 (Waterfall Model)]〉, 《개인블로그》, 2018-11-20</ref>
 +
원래의 폭포수 모델은 폭포에서 내려오는 물이 아래로만 떨어지듯이 각 단계가 순차적으로 진행되며, 병행되어 진행되거나 거슬러 반복 진행되는 경우가 없다. 하지만 실제 사용되고 있는 폭포수 모델은 각 단계의 결과가 확인된 후에 다음 단계로 넘어간다. 이는 사용자 의견이 다르거나 중간 결과를 점검한 결과 전 단계의 작업에 결함이 있다면 다시 수정하도록 전 단계로 돌아가는 피드백이 있기 때문이다.<ref name="자료4"> 푸른제비, 〈[https://gisulsa.tistory.com/229 폭포수 모델 Waterfall Model]〉, 《개인 블로그》, 2008-05-09</ref>
 +
 
 +
==특징==
 +
폭포수 모델은 SW 개발을 단계적, 순차적, 체계적으로 접근한다. 그리고 각 단계를 철저하게 완료한 뒤 다음 단계를 진행하는 순차적인 특징을 가지고 있다. 개발 방법과 관리 방법론을 연계하여 효과적인 생산성 확보 여부를 판단하며, 각 단계 종료 시 검증 후 다음 단계로 진행하는 단계별 검증을 한다.
 +
이러한 폭포수 모델은 프로젝트 진행과정에 대해서 관리가 용이하지만 목표 시스템이 후반에 가서야 구체화 되므로 중요한 문제점이 프로젝트 후반부에 발견될 수 있다.<ref name="자료1"> 도리의 디지털라이프, 〈[http://blog.skby.net/%ED%8F%AD%ED%8F%AC%EC%88%98-%EB%AA%A8%EB%8D%B8-waterfall-model/ 폭포수 모델 (Waterfall Model)]〉, 《개인블로그》, 2018-11-20</ref>
 +
 
 +
==구성==
 +
SDLC(Software Development Life Cycle)에서 많이 반복되는 구성 단계로 '계획수립->요구분석->설계->개발/구현->테스트->유지보수' 단계를 순차적으로 진행하며 각 단계 종료 시 검증 후에 다음 단계를 진행한다. 전 단계에서 결함 발견 시 피드백을 받고, 각 단계별 산출물을 명확하게 정의한다. 기술적 위험성이 낮거나 유사프로젝트 경험이 많은 경우에 사용한다.<ref name="자료2"> 바보상자, 〈[https://m.blog.naver.com/PostView.nhn?blogId=seilius&logNo=130185585600&proxyReferer=https%3A%2F%2Fwww.google.com%2F 소프트웨어 공학 - 폭포수 모델(Waterfall Model)]〉, 《개인블로그》, 2014-02-14</ref>
 +
 
 +
===계획===
 +
타당성 검토라고도 한다. 고객과 사용자가 원하는 바를 파악하여 타당성을 조사하고 SW 기능과 제약조건을 정의하는 명세서를 작성한다. 고객의 요구조건, 시스템 환경 등을 고려하여 프로젝트 진행 여부를 판단하고, 진행 결정이 나면 프로젝트 전반적인 계획에 들어간다.<ref name="자료2"> 바보상자, 〈[https://m.blog.naver.com/PostView.nhn?blogId=seilius&logNo=130185585600&proxyReferer=https%3A%2F%2Fwww.google.com%2F 소프트웨어 공학 - 폭포수 모델(Waterfall Model)]〉, 《개인블로그》, 2014-02-14</ref>
 +
문제점을 파악하고 해결 방안을 제시하여 투입 대비 이익을 평가한다. 조직의 전략적 목표를 충족하는지, 비용 대비 수익 효과가 큰지, 정해진 시간 안에 현재의 기술 수준으로 개발이 가능한지, 운영이나 사용하는 능력이나 다른 시스템과의 연동 가능성이 있는지를 판단해야 한다.
 +
짧은 기간 내에 분석과 미래 예측을 해야 하기 때문에 시간적 제약과 정신적 압박감이 존재하는 단계로 문제 정의, 해결 방안, 기대 효과, 타당성, 비용, 인도 날짜 등을 포함한다.<ref name="자료5"> 버터필드, 〈[https://atoz-develop.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%AA%A8%EB%8D%B8-%ED%8F%AD%ED%8F%AC%EC%88%98-%EB%AA%A8%EB%8D%B8Waterfall-Model 소프트웨어 개발 프로세스 모델 - 폭포수 모델(Waterfall Model)]〉, 《개인 블로그》, 2020-04-18</ref>
 +
 
 +
===분석===
 +
대상이 되는 문제 영역과 사용자가 원하는 요구를 이해하는 단계이다. 사용자의 요구사항을 듣고 정확히 기능적, 비기능적 요구 사항을 도출한다.<ref name="자료2"> 바보상자, 〈[https://m.blog.naver.com/PostView.nhn?blogId=seilius&logNo=130185585600&proxyReferer=https%3A%2F%2Fwww.google.com%2F 소프트웨어 공학 - 폭포수 모델(Waterfall Model)]〉, 《개인블로그》, 2014-02-14</ref>
 +
프로젝트에서 무엇을 개발할 것인지 결정하는 단계로 문제의 해결을 위해 시스템이 갖추어야 하는 조건과 능력을 요구사항 명세서, 계약서에 명시한다. 요구사항 명세서의 경우 발주자-개발자 간 의사소통의 수단으로 사용되며 정확성, 일관성, 완전성에 맞추어 작성해야 한다.
 +
명세서의 구성으로는 시스템의 목적과 범위와 기능적, 비기능적 요구사항과 기타 제약 조건 등을 포함한다. 이 때 문제점을 구체적으로 기술하고 대안 법을 제시해야 한다.<ref name="자료5"> 버터필드, 〈[https://atoz-develop.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%AA%A8%EB%8D%B8-%ED%8F%AD%ED%8F%AC%EC%88%98-%EB%AA%A8%EB%8D%B8Waterfall-Model 소프트웨어 개발 프로세스 모델 - 폭포수 모델(Waterfall Model)]〉, 《개인 블로그》, 2020-04-18</ref>
 +
 
 +
===설계===
 +
분석 모델을 가지고 이를 세분화함으로써 구현될 수 있는 형태로 전환한다. 요구사항 명세가 전달되면 요구사항 명세에 준수하는 설계에 들어간다.<ref name="자료2"> 바보상자, 〈[https://m.blog.naver.com/PostView.nhn?blogId=seilius&logNo=130185585600&proxyReferer=https%3A%2F%2Fwww.google.com%2F 소프트웨어 공학 - 폭포수 모델(Waterfall Model)]〉, 《개인블로그》, 2014-02-14</ref>
 +
요구사항을 기반으로 명확하고 조직화된 구조로 설계해야 한다. 설계의 단계는 아키텍처 설계 -> 인터페이스 설계 -> 프로그램 설계 순이며 구조적 설계 방법과 객체지향 설계 방법이 있다.<ref name="자료5"> 버터필드, 〈[https://atoz-develop.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%AA%A8%EB%8D%B8-%ED%8F%AD%ED%8F%AC%EC%88%98-%EB%AA%A8%EB%8D%B8Waterfall-Model 소프트웨어 개발 프로세스 모델 - 폭포수 모델(Waterfall Model)]〉, 《개인 블로그》, 2020-04-18</ref>
 +
 
 +
===개발===
 +
설계 단계에서 만들어진 설계서를 바탕으로 프로그램을 작성, 코딩, 디버깅, 단위/통합테스트를 수행한다. 단위테스트는 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차로 모든 함수와 메소드에 대한 테스트 케이스를 작성하는 것이다.<ref name="자료2"> 바보상자, 〈[https://m.blog.naver.com/PostView.nhn?blogId=seilius&logNo=130185585600&proxyReferer=https%3A%2F%2Fwww.google.com%2F 소프트웨어 공학 - 폭포수 모델(Waterfall Model)]〉, 《개인블로그》, 2014-02-14</ref>
 +
설계 결과를 프로그램으로 작성하는 단계로 구현된 모듈이 명세서를 만족하는지 테스트해서 확인해야 한다. 작성 시 코딩 표준과 테스트 절차를 준수하며 작성해야 하며 코드의 정적 분석을 진행한다.<ref name="자료5"> 버터필드, 〈[https://atoz-develop.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%AA%A8%EB%8D%B8-%ED%8F%AD%ED%8F%AC%EC%88%98-%EB%AA%A8%EB%8D%B8Waterfall-Model 소프트웨어 개발 프로세스 모델 - 폭포수 모델(Waterfall Model)]〉, 《개인 블로그》, 2020-04-18</ref>
 +
 
 +
===시험===
 +
발생 가능한 실행 프로그램 오류를 발견, 수정하는 단계이다. 테스트는 모듈들을 통합시키며 진행하는 통합 테스트, 전체 시스템 동작에 대해 검증을 하는 시스템 테스트, 사용자가 현장에서 검증해보는 인수테스트가 있다.<ref name="자료2"> 바보상자, 〈[https://m.blog.naver.com/PostView.nhn?blogId=seilius&logNo=130185585600&proxyReferer=https%3A%2F%2Fwww.google.com%2F 소프트웨어 공학 - 폭포수 모델(Waterfall Model)]〉, 《개인블로그》, 2014-02-14</ref>
 +
모듈과 서브시스템을 전체 시스템으로 통합시킨다. 통합 시스템의 경우 모듈들을 통합하여 점층적으로 시스템 구축을 하고, 시스템 테스트는 최종적으로 통합된 전체 시스템이 요구사항을 만족하는지 확인한다.
 +
베타 테스트는 고객의 실제 사용 환경에서 수행한다. 제품 출시 전 릴리즈 된 베타 버전으로 가망 사용자로부터 미리 제품을 평가하는 방법이다. 이 외에 알파 테스트는 소프트웨어 개발 현장에서 수행하는 테스트로 일반 소프트웨어는 테스트 팀이 알파 테스트를 수행하고 베타 버전으로 보낸다. 주문형 소프트웨어의 경우 제품 인수 동의가 이루어질 때까지 테스트를 수행한다.<ref name="자료5"> 버터필드, 〈[https://atoz-develop.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%AA%A8%EB%8D%B8-%ED%8F%AD%ED%8F%AC%EC%88%98-%EB%AA%A8%EB%8D%B8Waterfall-Model 소프트웨어 개발 프로세스 모델 - 폭포수 모델(Waterfall Model)]〉, 《개인 블로그》, 2020-04-18</ref>
 +
 
 +
===운영/유지보수===
 +
시스템의 사용 중 발생하는 여러 변경사항에 대해 적응하고, 변화에 대비하는 과정이다. 소프트웨어를 사용하면서 나타나는 오류들을 수정하며, 환경변화나 고객 요구에 따른 추가 기능 개발을 진행하는 과정으로 유지보수 계약 종료 후 재계약을 하지 않았을 때와 소프트웨어가 폐기됐을 때 유지보수가 종료된다.<ref name="자료2"> 바보상자, 〈[https://m.blog.naver.com/PostView.nhn?blogId=seilius&logNo=130185585600&proxyReferer=https%3A%2F%2Fwww.google.com%2F 소프트웨어 공학 - 폭포수 모델(Waterfall Model)]〉, 《개인블로그》, 2014-02-14</ref>
 +
실제 사용을 위해서 고객에게 소프트웨어를 배포해 운영한다. 운영 중에 소프트웨어의 수정 및 보완 활동을 유지보수라고 하는데 이 유지보수의 종류는 수정, 적응, 완전, 예방 유지보수가 있다.
 +
수정 유지보수는 오류를 수정, 적응 유지보수는 환경 변화에 대응하며, 완전 유지보수는 기능을 개선하고 성능을 향상시킨다. 그리고 예방 유지보수는 미래 유지 보수성을 향상시키기 위한 활동이다.<ref name="자료5"> 버터필드, 〈[https://atoz-develop.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%AA%A8%EB%8D%B8-%ED%8F%AD%ED%8F%AC%EC%88%98-%EB%AA%A8%EB%8D%B8Waterfall-Model 소프트웨어 개발 프로세스 모델 - 폭포수 모델(Waterfall Model)]〉, 《개인 블로그》, 2020-04-18</ref>
 +
 
 +
== 장단점 ==
 +
 
 +
=== 장점 ===
 +
* 고전적인 방법론으로써 적용 사례가 풍부하다.
 +
* 전체 과정의 이해가 쉽다.
 +
* 현재 단계에 대한 이해가 빠르고 쉽다.
 +
* 문서, 산출물의 관리와 적용이 쉽다.
 +
 
 +
=== 단점 ===
 +
* 병행 작업이 안된다.
 +
* 피드백에 대한 반복 단계가 어렵다.
 +
* 테스트 단계에 발견된 중요 결함에 대한 대응이 어렵다.
 +
* 고객 요구사항에 대한 상세한 반영이 어렵다.
 +
 
 +
==활용==
 +
응용분야를 잘 알고 있거나, 단순한 프로젝트를 개발할 때 용이하다. 비전문가가 사용할 시스템을 개발하는 데 적합하고, 단계 종료 후에 나와야 하는 산출물에 대한 명확한 정의가 필요한 사이트 제작에 사용하기 좋고 초기에 정의한 요구사항 변경이 적은 프로그램에 적용해 사용하기 좋다.
 +
<ref name="자료3"> 자비스가 필요해, 〈[https://needjarvis.tistory.com/65 SDLC의 고전적 모델, 폭포수모델(Waterfall Model)]〉, 《개인 블로그》, 2016-09-08</ref>
 +
===고려사항===
 +
폭포수 모델을 적용할 때 고려해야 하는 사항들이 있다. 우선, 관리가 상대적으로 쉬우나 요구사항의 변경에 대한 대응력이 떨어진다. 단계별로 개발을 진행하기 때문에 요구사항 단계가 끝이 나고 다음 단계에서 요구사항을 변경했을 때 수정이 어렵기 때문이다.
 +
그리고 기술 위험이 낮고 유사한 프로젝트 경험이 있는 경우와 요구사항이 비교적 명확하게 정의되어 있을 때 적용하는 것이 좋다.<ref name="자료6"> 보통 인간 보통인간, 〈[https://azurecourse.tistory.com/277 폭포수(Waterfall) 모델]〉, 《개인 블로그》, 2014-01-22</ref>
 +
 
 +
{{각주}}
 +
 
 +
== 참고자료 ==
 +
* 개요, 장단점 구성 단계, 〈[http://blog.naver.com/PostView.nhn?blogId=seilius&logNo=130185585600&parentCategoryNo=&categoryNo=54 소프트웨어 공학 - 폭포수 모델(Waterfall Model)]〉 , 《개인 블로그》 , 2014-02-14
 +
* 도리의 디지털라이프, 〈[http://blog.skby.net/%ED%8F%AD%ED%8F%AC%EC%88%98-%EB%AA%A8%EB%8D%B8-waterfall-model/ 폭포수 모델 (Waterfall Model)]〉, 《개인블로그》, 2018-11-20
 +
* 바보상자, 〈[https://m.blog.naver.com/PostView.nhn?blogId=seilius&logNo=130185585600&proxyReferer=https%3A%2F%2Fwww.google.com%2F 소프트웨어 공학 - 폭포수 모델(Waterfall Model)]〉, 《개인블로그》, 2014-02-14
 +
* 자비스가 필요해, 〈[https://needjarvis.tistory.com/65 SDLC의 고전적 모델, 폭포수모델(Waterfall Model)]〉, 《개인 블로그》, 2016-09-08
 +
* 푸른제비, 〈[https://gisulsa.tistory.com/229 폭포수 모델 Waterfall Model]〉, 《개인 블로그》, 2008-05-09
 +
* 버터필드, 〈[https://atoz-develop.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%AA%A8%EB%8D%B8-%ED%8F%AD%ED%8F%AC%EC%88%98-%EB%AA%A8%EB%8D%B8Waterfall-Model 소프트웨어 개발 프로세스 모델 - 폭포수 모델(Waterfall Model)]〉, 《개인 블로그》, 2020-04-18
 +
* 보통 인간 보통인간, 〈[https://azurecourse.tistory.com/277 폭포수(Waterfall) 모델]〉, 《개인 블로그》, 2014-01-22
  
 
== 같이 보기 ==
 
== 같이 보기 ==
 +
* [[폭포]]
 +
* [[폭포수]]
 
* [[소프트웨어 개발 방법론]]
 
* [[소프트웨어 개발 방법론]]
 
* [[애자일]]
 
* [[애자일]]
 +
 +
{{프로그래밍|검토 필요}}

2023년 5월 16일 (화) 16:33 기준 최신판

폭포수 모델(Waterfall Model)이란 소프트웨어 개발 시 단계적으로 개발하는 방법론을 말한다. 분석→설계→개발(디자인→퍼블리싱→프로그래밍)→테스트→적용→안정화의 단계를 따른다. 폭포수가 거슬러 올라갈 수 없듯이, 소프트웨어 개발도 반드시 앞 단계가 먼저 완료되어야 다음 단계의 개발을 진행할 수 있다는 뜻이다. 소프트웨어 개발 방법론(SDM)의 일종이다. 반대말은 애자일 개발 방법론이다.

폭포수모델 구성도

개요[편집]

폭포수 모델은 분석, 설계, 개발/구현, 시험, 운영 및 유지보수 등 전 과정을 순차적으로 접근하는 개발모델이다. 순차적으로 접근하며 단계별 검증을 진행한다. 그리고 각 단계를 종료할 때 검증 후에 다음 단계로 진행한다. 관리가 용이하며 문제점이 후반부에 발견될 수 있는 리스크를 가지고 있다.[1] 원래의 폭포수 모델은 폭포에서 내려오는 물이 아래로만 떨어지듯이 각 단계가 순차적으로 진행되며, 병행되어 진행되거나 거슬러 반복 진행되는 경우가 없다. 하지만 실제 사용되고 있는 폭포수 모델은 각 단계의 결과가 확인된 후에 다음 단계로 넘어간다. 이는 사용자 의견이 다르거나 중간 결과를 점검한 결과 전 단계의 작업에 결함이 있다면 다시 수정하도록 전 단계로 돌아가는 피드백이 있기 때문이다.[2]

특징[편집]

폭포수 모델은 SW 개발을 단계적, 순차적, 체계적으로 접근한다. 그리고 각 단계를 철저하게 완료한 뒤 다음 단계를 진행하는 순차적인 특징을 가지고 있다. 개발 방법과 관리 방법론을 연계하여 효과적인 생산성 확보 여부를 판단하며, 각 단계 종료 시 검증 후 다음 단계로 진행하는 단계별 검증을 한다. 이러한 폭포수 모델은 프로젝트 진행과정에 대해서 관리가 용이하지만 목표 시스템이 후반에 가서야 구체화 되므로 중요한 문제점이 프로젝트 후반부에 발견될 수 있다.[1]

구성[편집]

SDLC(Software Development Life Cycle)에서 많이 반복되는 구성 단계로 '계획수립->요구분석->설계->개발/구현->테스트->유지보수' 단계를 순차적으로 진행하며 각 단계 종료 시 검증 후에 다음 단계를 진행한다. 전 단계에서 결함 발견 시 피드백을 받고, 각 단계별 산출물을 명확하게 정의한다. 기술적 위험성이 낮거나 유사프로젝트 경험이 많은 경우에 사용한다.[3]

계획[편집]

타당성 검토라고도 한다. 고객과 사용자가 원하는 바를 파악하여 타당성을 조사하고 SW 기능과 제약조건을 정의하는 명세서를 작성한다. 고객의 요구조건, 시스템 환경 등을 고려하여 프로젝트 진행 여부를 판단하고, 진행 결정이 나면 프로젝트 전반적인 계획에 들어간다.[3] 문제점을 파악하고 해결 방안을 제시하여 투입 대비 이익을 평가한다. 조직의 전략적 목표를 충족하는지, 비용 대비 수익 효과가 큰지, 정해진 시간 안에 현재의 기술 수준으로 개발이 가능한지, 운영이나 사용하는 능력이나 다른 시스템과의 연동 가능성이 있는지를 판단해야 한다. 짧은 기간 내에 분석과 미래 예측을 해야 하기 때문에 시간적 제약과 정신적 압박감이 존재하는 단계로 문제 정의, 해결 방안, 기대 효과, 타당성, 비용, 인도 날짜 등을 포함한다.[4]

분석[편집]

대상이 되는 문제 영역과 사용자가 원하는 요구를 이해하는 단계이다. 사용자의 요구사항을 듣고 정확히 기능적, 비기능적 요구 사항을 도출한다.[3] 프로젝트에서 무엇을 개발할 것인지 결정하는 단계로 문제의 해결을 위해 시스템이 갖추어야 하는 조건과 능력을 요구사항 명세서, 계약서에 명시한다. 요구사항 명세서의 경우 발주자-개발자 간 의사소통의 수단으로 사용되며 정확성, 일관성, 완전성에 맞추어 작성해야 한다. 명세서의 구성으로는 시스템의 목적과 범위와 기능적, 비기능적 요구사항과 기타 제약 조건 등을 포함한다. 이 때 문제점을 구체적으로 기술하고 대안 법을 제시해야 한다.[4]

설계[편집]

분석 모델을 가지고 이를 세분화함으로써 구현될 수 있는 형태로 전환한다. 요구사항 명세가 전달되면 요구사항 명세에 준수하는 설계에 들어간다.[3] 요구사항을 기반으로 명확하고 조직화된 구조로 설계해야 한다. 설계의 단계는 아키텍처 설계 -> 인터페이스 설계 -> 프로그램 설계 순이며 구조적 설계 방법과 객체지향 설계 방법이 있다.[4]

개발[편집]

설계 단계에서 만들어진 설계서를 바탕으로 프로그램을 작성, 코딩, 디버깅, 단위/통합테스트를 수행한다. 단위테스트는 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차로 모든 함수와 메소드에 대한 테스트 케이스를 작성하는 것이다.[3] 설계 결과를 프로그램으로 작성하는 단계로 구현된 모듈이 명세서를 만족하는지 테스트해서 확인해야 한다. 작성 시 코딩 표준과 테스트 절차를 준수하며 작성해야 하며 코드의 정적 분석을 진행한다.[4]

시험[편집]

발생 가능한 실행 프로그램 오류를 발견, 수정하는 단계이다. 테스트는 모듈들을 통합시키며 진행하는 통합 테스트, 전체 시스템 동작에 대해 검증을 하는 시스템 테스트, 사용자가 현장에서 검증해보는 인수테스트가 있다.[3] 모듈과 서브시스템을 전체 시스템으로 통합시킨다. 통합 시스템의 경우 모듈들을 통합하여 점층적으로 시스템 구축을 하고, 시스템 테스트는 최종적으로 통합된 전체 시스템이 요구사항을 만족하는지 확인한다. 베타 테스트는 고객의 실제 사용 환경에서 수행한다. 제품 출시 전 릴리즈 된 베타 버전으로 가망 사용자로부터 미리 제품을 평가하는 방법이다. 이 외에 알파 테스트는 소프트웨어 개발 현장에서 수행하는 테스트로 일반 소프트웨어는 테스트 팀이 알파 테스트를 수행하고 베타 버전으로 보낸다. 주문형 소프트웨어의 경우 제품 인수 동의가 이루어질 때까지 테스트를 수행한다.[4]

운영/유지보수[편집]

시스템의 사용 중 발생하는 여러 변경사항에 대해 적응하고, 변화에 대비하는 과정이다. 소프트웨어를 사용하면서 나타나는 오류들을 수정하며, 환경변화나 고객 요구에 따른 추가 기능 개발을 진행하는 과정으로 유지보수 계약 종료 후 재계약을 하지 않았을 때와 소프트웨어가 폐기됐을 때 유지보수가 종료된다.[3] 실제 사용을 위해서 고객에게 소프트웨어를 배포해 운영한다. 운영 중에 소프트웨어의 수정 및 보완 활동을 유지보수라고 하는데 이 유지보수의 종류는 수정, 적응, 완전, 예방 유지보수가 있다. 수정 유지보수는 오류를 수정, 적응 유지보수는 환경 변화에 대응하며, 완전 유지보수는 기능을 개선하고 성능을 향상시킨다. 그리고 예방 유지보수는 미래 유지 보수성을 향상시키기 위한 활동이다.[4]

장단점[편집]

장점[편집]

  • 고전적인 방법론으로써 적용 사례가 풍부하다.
  • 전체 과정의 이해가 쉽다.
  • 현재 단계에 대한 이해가 빠르고 쉽다.
  • 문서, 산출물의 관리와 적용이 쉽다.

단점[편집]

  • 병행 작업이 안된다.
  • 피드백에 대한 반복 단계가 어렵다.
  • 테스트 단계에 발견된 중요 결함에 대한 대응이 어렵다.
  • 고객 요구사항에 대한 상세한 반영이 어렵다.

활용[편집]

응용분야를 잘 알고 있거나, 단순한 프로젝트를 개발할 때 용이하다. 비전문가가 사용할 시스템을 개발하는 데 적합하고, 단계 종료 후에 나와야 하는 산출물에 대한 명확한 정의가 필요한 사이트 제작에 사용하기 좋고 초기에 정의한 요구사항 변경이 적은 프로그램에 적용해 사용하기 좋다. [5]

고려사항[편집]

폭포수 모델을 적용할 때 고려해야 하는 사항들이 있다. 우선, 관리가 상대적으로 쉬우나 요구사항의 변경에 대한 대응력이 떨어진다. 단계별로 개발을 진행하기 때문에 요구사항 단계가 끝이 나고 다음 단계에서 요구사항을 변경했을 때 수정이 어렵기 때문이다. 그리고 기술 위험이 낮고 유사한 프로젝트 경험이 있는 경우와 요구사항이 비교적 명확하게 정의되어 있을 때 적용하는 것이 좋다.[6]

각주[편집]

  1. ↑ 1.0 1.1 도리의 디지털라이프, 〈폭포수 모델 (Waterfall Model)〉, 《개인블로그》, 2018-11-20
  2. ↑ 푸른제비, 〈폭포수 모델 Waterfall Model〉, 《개인 블로그》, 2008-05-09
  3. ↑ 3.0 3.1 3.2 3.3 3.4 3.5 3.6 바보상자, 〈소프트웨어 공학 - 폭포수 모델(Waterfall Model)〉, 《개인블로그》, 2014-02-14
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 버터필드, 〈소프트웨어 개발 프로세스 모델 - 폭포수 모델(Waterfall Model)〉, 《개인 블로그》, 2020-04-18
  5. ↑ 자비스가 필요해, 〈SDLC의 고전적 모델, 폭포수모델(Waterfall Model)〉, 《개인 블로그》, 2016-09-08
  6. ↑ 보통 인간 보통인간, 〈폭포수(Waterfall) 모델〉, 《개인 블로그》, 2014-01-22

참고자료[편집]

같이 보기[편집]


  검수요청.png검수요청.png 이 폭포수 모델 문서는 프로그래밍에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.  

개발 : 프로그래밍 □■⊕, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인
프로그래밍 언어 ASP • C 언어 • C++ • C# • CSS • D 언어 • HTML • HTML5 • JSP • PHP • R • XHTML • XML • XSLT • 고(Go) • 고급언어 • 기계어 • 델파이 • 러스트 • 루비 • 루아 • 리액트 • 리퀴디티 • 무브 • 미켈슨 • 베이직 • 브이비스크립트 • 비주얼 C++ • 비주얼베이직(VB) • 비주얼베이직닷넷(VB.NET) • 솔리디티 • 스몰토크 • 스위프트 언어 • 스칼라 • 스크립트 언어 • 알골 • 어셈블리 • 언리얼스크립트 • 얼랭 • 에이잭스(Ajax) • 엠에프씨(MFC) • 오브젝티브-C • 오브젝트 파스칼 • 오카멜 • 웹어셈블리(WASM) • 이와즘(eWASM) • 자바 • 자바스크립트 • 저급언어 • 제이슨(JSON) • 제이쿼리(jQuery) • 카멜 • 코볼 • 코틀린 • 콜드퓨전 • 타입스크립트 • 파스칼 • 파워스크립트 • 파이썬 • 펄(Perl) • 포트란 • 프로씨(Pro-C) • 피엘에스큐엘(PL/SQL) • 피엘원(PL/I) • 하스켈
개발방법론 CBD 개발방법론 • EA • 구조적 개발방법론 • 객체지향 개발방법론 • 라이브러리 • 람다 아키텍처 • 모듈 • 모듈화 • 벤치마킹 • 소프트웨어 개발방법론 • 스크럼 • 스프린트 • 아키텍처 • 아키텍트 • 애자일 • 웹개발방법론 • 정보공학 개발방법론 • 컴포넌트 • 테일러링 • 템플릿 • 폭포수 모델 • 프로젝트 • 프로토타입 • 피드백
코딩 EUC-KR • UTF-8 • 값 • 글루웨어 • 노팔로우 링크 • 두팔로우 링크 • 디버깅 • 디코딩 • 마크업 • 버그 • 부트스트랩 • 세이브포인트 • 소스코드 • 시큐어코딩 • 아스키 • 액티브엑스 • 오픈소스 • 유니코드 • 인코딩 • 재컴파일 • 주석 • 컴파일 • 컴퓨터 프로그램 • 코드 • 코딩 • 태그 • 테스트 • 테이블 • 텍스트 • 파싱 • 퍼블리싱 • 퓨니코드 • 하드코딩 • 하이퍼링크 • 하이퍼텍스트
프로그래밍 C 명령어 • 객체 • 객체지향 • 객체지향 프로그래밍 • 거짓 • 관계연산자 • 기본형 변수 • 널 • 논리 • 논리연산 • 논리연산자 • 다중상속 • 다형성 • 대입 • 대입문 • 대입연산자 • 더블 • 도스 명령어 • 디폴트 • 레지스터변수 • 루프 • 리눅스 명령어 • 리턴 • 메모리 주소 • 메소드 • 멤버 • 명령문 • 명령어 • 무한루프 • 문자 • 문자열 • 바이트 • 반복문 • 배열 • 변수 • 분기 • 분기문 • 불린 • 브레이크 • 비교연산자 • 비트연산자 • 산술연산자 • 상속 • 상수 • 생성자 • 선언 • 선언문 • 설정자 • 속성 • 스위치 • 스태틱 • 시프트연산자 • 실행 • 실행문 • 어노테이션 • 에코 • 역참조 • 연산 • 연산문 • 연산자 • 오버로딩 • 오버라이딩 • 외부변수 • 윈도우 명령어 • 유닉스 명령어 • 인스턴스 • 인스트럭션 • 인클루드 • 인터페이스 • 임포트 • 입력 • 입력문 • 입출력 • 입출력문 • 자료형(데이터 타입) • 자바 명령어 • 자바 예약어 • 자바 컬렉션 • 전역변수 • 접근자 • 접근제어자 • 정보은닉 • 정수형 • 정적변수 • 제어 • 제어문 • 제어자 • 조건 • 조건문 • 조건연산자 • 주소 • 증감연산자 • 지역변수 • 참 • 참조 • 참조변수 • 초기화 • 추상메소드 • 추상클래스 • 추상화 • 출력 • 출력문 • 캡슐화 • 케이스 • 클래스 • 파라미터(매개변수) • 파이널 • 패키지 • 퍼블릭 • 포인터 • 프라이빗 • 프로텍티드 • 필드(멤버변수) • 함수 • 환경변수
명령어 abstract • array • boolean • break • byte • case • char • continue • default • double • do while • echo • elif • else • else if • false • final • float • for • gosub • goto • if • if else • import • include • int • join • long • long long • null • print • printf • println • private • protected • public • return • scanf • short • stdio.h • static • string • switch • temp • then • true • unsigned • void • while
디자인패턴 구조패턴 • 동시성패턴 • 동시실행패턴 • 모델-뷰-컨트롤러 패턴 • 상태패턴 • 생성패턴 • 싱글톤패턴 • 아키텍처패턴 • 전략패턴 • 커맨드패턴 • 행동패턴
프로그래밍 인물 귀도 반 로썸 • 그레이스 머레이 호퍼 • 니클라우스 비르트 • 댄 브릭클린 • 더그 커팅 • 데니스 리치 • 리누스 토르발스 • 리처드 그린블라트 • 마거릿 해밀턴 • 마크 앤드리슨 • 빈트 서프 • 빌 게이츠 • 빌 조이 • 스티브 잡스 • 에이다 러브레이스 • 제임스 고슬링 • 척 벤턴 • 켄 톰슨 • 팀 패터슨
위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반
원본 주소 "http://wiki1.kr/index.php?title=폭포수_모델&oldid=652640"