소프트웨어 개발방법론

개발방법론이란? 

 

개발을 할 때에 좀 더 효율적이고 체계적으로 개발하기 위해 정리된 방법이라고 생각하시면 될 거 같습니다.

 

 

소프트웨어 개발 방법론은 소프트웨어를 생산하는 데에 필요한 프로그래밍 개발 과정들을 정리하고 표준화하여 프로그래머들이 프로그래밍 개발과정에서 각개인이 개발과정에서의 일관성을 유지하고 프로그래머들 간의 효과적인 협업이 이루어질 수 있도록 돕기 위한 방법론이다.

                                                                                                                                                       

출처 : 위키백과

 

 

검색을 하다보니 방법론에 심취하지 말고 개발이나 하자라는 의견들이 보이더라고요.

 

실질적인 개발이 우선적으로 중요한게 맞지만 초기에는 이런 체계도 중요하다고 생각합니다.

 

이제 개발방법론의 종류를 살펴보겠습니다.

 

*폭포수와 애자일 방법은 비교하여 많이 다루니 잘 봐주세요!

 

폭포수 모델 - 애자일 방법론 - V모델 - 나선형 모델 - 원형 패러다임

 

 

폭포수 모델 (Waterfall model)

고객이나 프로젝트 진행에서 원하는 것이 확실하여 후에 변경하지 않을 때 사용하면 좋은 방법론입니다.

 

폭포수 방법론은 프로젝트 시작 전에 계획을 확실히 수립하지만 애자일 방법론은 그렇지 않습니다.

 

애자일 방법론은 계획이 그때그때 수정될 수 있습니다.

 

진행사항을 쉽고 확실하게 파악할 수 있고, 프로젝트 관리 용이하다는 장점이 있습니다.

 

중간에 발생하는 사용자 요구사항에 대처하기 힘들다는 단점이 있습니다.

 

 

애자일 방법론(Agile)

출처 https://www.mk.co.kr/news/economy/view/2018/11/718895/

 

개발방법론을 검색하면 절대적으로 많이 나오는 애자일 방법론입니다.

 

빠르고 잦은 피드백을 통해서 짧은 주기로 제품을 개발하여 제품에 대한 피드백을 많이 받아

 

제품의 질을 향상시키는 개발 방법이며,

 

계획이나 문서가 아닌 실질적인 코딩을 중요시하고

 

짧은 개발 주기를 반복하여 위험 요소를 최소화시킨다는 중요한 특징을 가지고 있습니다.

 

 

세부적으로 본다면 개발 대상을 다수의 작은 기능으로 분할하여

 

하나의 기능을 하나의 반복 주기 내에 개발하는 방법하고 

 

이 반복 주기를 계속해나가며 하나씩 기능을 추가해 개발하는 것입니다.

 

 

중간중간 필요한 요소를 바꿔 변화에 대처할 수 있고 중간 중간 테스트를 하며 버그에 대처할 수 있다는 장점

 

정확한 계획이 없다면 비효율적이다는 단점이 있습니다.

 

 

가장 고객의 요구에 잘 대응할 수 있는 방법론입니다.

 

 

 

V 모델

출처 https://www.oss.kr

 

폭포수 모델에 테스트 단계 추가된 폭포수 모델의 확장된 형태로 볼 수 있습니다.

 

폭포수 모델은 문서, 산출물 중심으로 진행

 

단계가 명확하고 모든 단계마다 검증작업이 있어 오류를 줄일 수 있다는 장점이 있습니다.

 

테스트를 마지막 단계에 하기 때문에 기본적인 치명적인 문제가 처음에 간과될 수 있는 단점이 있습니다.

 

나선형 모델 (Spiral model)

 

출처 위키

 

소프트웨어의 리스크(위험)를 명백히 측정하는데에 좋은 모델입니다.

 

위험 분석이라는 요소가 추가되어 높은 위험도가 예상되는 경우에 사용합니다.

 

그림과 같이 나선형으로 돌면서 점진적으로 개발합니다.

 

비용이 많이 들고 복잡한 시스템을 개발하는데 유용하다는 장점이 있지만

 

프로젝트 관리가 복잡할 수 있다는 단점이 있습니다.

 

 

원형 패러다임 (Prototyping)

 

출처 https://m.blog.naver.com/PostView.nhn?blogId=whatclouds&logNo=220226873106&proxyReferer=https%3A%2F%2Fwww.google.com%2F

 

고객의 요구사항이 무엇인지 구체적으로 모르는 상황에서 간단한 시제품(Prototype)을 만들어 

 

피드백을 통해 고객의 요구사항을 만족해나가는 방법론입니다.

 

시제품을 확인함으로써 고객의 요구사항을 구체적으로 확인할 수 있는 장점이 있습니다.

 

하지만 시제품을 통해 오해를 불러올 수 있는 단점이 있습니다.