티스토리 뷰

 스프트웨어 개발 방법론이란 소프트웨어 개발에 있어 생산성과 품질 향상을 목적으로 개발 전과정에 지속적으로 적용할 수 있는 절차나 기법 등을 말합니다. 소프트웨어 개발에 공학적 기법을 접목해보려는 시도에서 소프트웨어 공학이 시작되었고 그 해결책으로 제시된 것이 개발 방법론이라고 하네요.

 

 대표적인 방법론으로는 2가지가 있는데요, 워터폴은 완전히 기획이 끝난 이후에 개발을 하는 개발 방법론입니다. 애자일은 서비스를 단위로 쪼개어 특정 기간 안에 개발 범위를 세분화하고 점진적으로 고도화하는 개발 방법론을 말합니다.

 

워터폴 개발방법론, 애자일 개발방법론 비교
https://www.easyredmine.com/

 

1. 워터폴(Waterfall) 방법론

 워터폴 방밥론에서 개발 과정은 선형적입니다. 프로젝트 시작부터 최종 결과물 전달까지 특정 순서에 따라 이루어집니다. 개발 과정에서 프로세스 각 단계에서 동일하고 정확한 순서로 실행하여 완료합니다.

 

- 요구사항 수집과 분석 : 프로젝트에서 구현할 기능이나 시스템 스펙 등을 고객 등으로부터 수집합니다.

- 설계 : 제품의 모양과 디자인 등의 요소를 결정합니다.

- 테스팅 : 만들어진 소프트웨어가 요구사항을 충족하는지 확인합니다. 결함이 발견되면 최종 완성 전에 해결합니다.

- 최종 결과물 전달 : 프로젝트를 시작할 때 확정되었던 요구사항이 충족되면 완성품을 고객에게 전달합니다.

- 유지보수 : 클라이언트가 요청하는 사항을 변경하게 되는데 이때 비용과 시간이 추가될 수 있습니다.

 

 

2. 애자일(Agile) 방법론

 애자일 기법은  개발 대상을 다수의 작은 기능으로 분할하고 하나의 기능을 특정 기간 안에 개발하는 방법입니다. 하나의 기능을 구현하는 기간은 프로젝트마다 다르지만 일반적으로 1~4주 정도가 많습니다. 각각의 반복 주기는 소규모 SW 개발 프로젝트와 유사합니다. 

 

 기존의 개발방법과는 달리 프로젝트 관계자 사이에서 직접 얼굴을 맞대고 즉각적인 의사소통을 강조합니다. 일반적으로 애자일 기법에서는 개발팀에 속하는 모든 관계자가 한 곳에서 모여 일을 합니다. 결함을 조기에 식별하기 위해 테스트를 강화한 것이 특징인데 개발 초기부터 테스트를 수행합니다. 또한 자동화된 테스트와 SW 배포 환경을 구축하여 지속적으로 시스템 통합을 수행합니다.

 

Waterfall vs Agile
https://www.linkedin.com/

 

 애자일 개발 방법은 1990년대 중반 중량 워터폴(heavyweight waterfall-oriented) 방법론에 대한 반대 운동인 경량 SW 개발 방법으로부터 시작되었습니다. 2001년 이 분야의 저명한 개발자 17명이 미국 유타 주에서 모여 애자일 소프트웨어 개발 선언을 발표하였습니다. 이 선언에서 도구보다 상호작용을, 문서보다 소프트웨어 자체를, 계약 협상보다 고객과의 협력을, 계획 준수보다 변화에 대한 대응을 강조하는 개발 원칙들이 공표되었습니다. 이후에는 비영리 조직인 애자일 연합(Agile Alliance)이 애자일 SW 개발 방법론을 추진하고 있다고 합니다.

 

- 계획 : 고객과 팀원들이 함께 프로젝트 개념화, 브레인스토밍, 우선순위설정, 필요자원, 예산책정 등을 논의

- 설계 : 사용자 경험(UX) 전문가와 팀원들이 협력해서 제품의 디자인과 기타 요소들을 결정

- 개발 : 이 단계에서 스프린트라고 불리는 여러 반복 작업을 거치며 고객의 요구사항에 맞는 제품을 개발

- 테스팅 : 제품이 고객의 요구사항을 충족하는지 확인. 결함이 발견되면 다시 개발 단게로 보내 수정 후 테스트를 거치며, 고객의 요구사항을 충족할 때까지 반복

- 배포 : 앞선 모든 단계가 완료되면 최종 제품을 고객에게 전달

- 피드백 : 팀원들이 전체 개발 프로세스를 리뷰하며 제품이나 팀의 성과를 개선할 수 있는 방법을 검토

 

3. 워터폴 vs 애자일 비교

 워터폴과 애자일 방법론의 장단점을 표로 정리해 보았습니다.

 

  워터폴(Waterfall) 애자일(Agile)
장점 - 개발 주기가 애자일보다 형식적, 연속적, 긴 프로세스를 가져 팀의 규모에 상관없이 따르기가 용이

- 개발 주기가 정해져 있어서 새로운 프로젝트를 안정적으로 시작

- 프로젝트 요구사항이 확정되어 있어 프로젝트 실행이 수월하며 개발 목표를 자주 변경하지 않아도 된다.

- 프로젝트 전 과정에 필요한 예산과 자원이 초기에 확정되어 예상 결과와 리스크를 통제 쉬움
- 개발 과정이 빠르고 유연

- 짧고 반복적인 스프린트로 구성되어 품질에 초점이 맞춰져 워터폴 방법론보다 빨리 결함 식별 및 수정 가능

- 여러개의 소규모 팀들이 개발 과정에서의 여러 과제를 각각 할당받아 처리

- 필요 시 개발중에 신속하게 제품 변경 가능
단점 - 개발이 순차적으로 진행되므로 앞 단계가 완료되어야 다음 단계로 넘어감. 이로 인해 개발 속도가 느리며 유연성이 떨어짐

- 테스팅 단계에 이르러서야 결함과 이슈가 발견

- 개발 요구사항이 프로젝트 초기에 정해져 범위 변경이 자유롭지 못함
- 스프린트에 대한 경험이 있으면서 빠른 반복 작업에 익숙한 스크럼 마스터가 필요

- 고객이 수많은 변경사항을 검토해야 하는 경우 생길 수 있음

- 팀원이 다양한 시간대의 지역에 흩어져 있거나 조직적이지 못한 경우, 프로젝트 진행에 문제가 발생 가능성

 

댓글
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday