소프트웨어 개발 계획을 다 짰으면 개발에 들어갈 차례입니다.
개발 계획 단계에서 설계한 UML 다이어그램을 기반으로, 개발자들은 하나씩 역할을 나누어 구현합니다.
폭포수 모델
소프트웨어 공학에서는 아래 그림과 같은 개발 방법론을 폭포수(Waterfall) 모델이라고 부릅니다. 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 이름이 붙여졌습니다.
폭포수 모델은 개발 계획 단계에서 본 것과 같이 요구사항 분석과 설계를 하고 설계도대로 실제 소프트웨어를 개발합니다. 마지막으로 테스트를 통해 소프트웨어를 검증하여 개발을 완료한 다음 운영/유지보수 단계로 넘어갑니다.
특징
폭포수 모델의 특징은 먼저 위의 작업이 완전히 끝나야 아래의 작업이 수행된다는 것입니다. 또한 아래의 작업을 수행 중일때는 위의 작업으로 돌아갈 수 없습니다.
장점
1. 소프트웨어 개발 초기에 등장한 전통적인 개발론으로 적용 사례가 많습니다.
2. 일반적으로 사람이 문제 해결을 위해 행하는 단계를 소프트웨어에 적용하였기 때문에 이해가 쉽습니다.
3. 작업이 시간의 순서에 따라 진행되므로 스케줄 관리에 용이하고 작업의 결과물들을 단계별로 관리하기 편합니다.
단점
1. 현 단계의 상태를 완전히 파악할 수 있는 사람이 적습니다.
2. 약간의 변화에 큰 영향을 받습니다.
폭포수 모델은 작은 요구사항만 추가되어도 설계, 개발, 검증단계까지 모든 단계가 영향을 받고 각 단계의 결과물들이 모두 수정이 되어야 합니다. 대부분의 고객은 요구사항 분석 단계가 끝난 다음에도 추가 요구사항을 전달하기 때문에, 폭포수 모델로 개발할 경우 소프트웨어 개발에 지장을 많이 줍니다.
3. 유지 보수의 어려움
약간의 변화에 큰 영향을 받기 때문에 개발이 완료된 다음 유지 보수를 위해 업데이트를 하거나 추가 기능을 구현하게 되면 모든 단계를 다시 다 거쳐야 합니다.
폭포수 모델은 하나의 변동사항만 있어도 다시 모든 단계의 작업을 수행하여야 한다는 큰 단점이 있습니다. 무작정 나쁘기만 한 개발 방법론은 아니고, 요구사항이 변동될 가능성이 낮고 명확하게 정의되어 있는 경우 폭포수 모델이 적합하다고 볼 수 있습니다.
스크럼 모델
소프트웨어 공학에서 폭포수 모델과 자주 비교되는 모델로 애자일 방법론이 있습니다. 애자일 방법론은 소프트웨어 개발 방법론의 하나로, 처음부터 끝까지 계획을 수립하고 개발하는 폭포수 방법론과는 달리 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법입니다.
애자일 개발 방법론 중에서 가장 대표적인 것이 스크럼(Scrum)모델입니다.
스크럼 모델은 스프린트 라는 개발 주기를 정해두고 이 스프린트를 반복해가며 개발을 진행합니다. 스프린트는 스크럼 모델에서 개발을 진행하는 최소 주기로 보통은 30일을 기준으로 하고 있습니다. 한 번의 스프린트에 한 개의 목표를 달성해야 하며 이 기간동안 스프린트의 요구사항인 스프린트 백로그를 다 구현해야 합니다. 백로그는 소프트웨어 개발을 위해 필요한 요구사항 목록으로, 목표 소프트웨어에 포함될 요구사항들을 모두 백로그에 기록합니다.
하나의 스프린트에는 반드시 실행 가능한 제품의 형태의 결과물이 나와야 하며, 개발자들은 하나의 스프린트가 끝나면 스프린트 리뷰를 통해 추가할 기능들을 백로그에 기록하고 다음 스프린트에 기존의 백로그의 개선점을 더해 소프트웨어를 완성해 나갑니다.
폭포수 모델과의 가장 큰 차이점은, 조직의 구성입니다. 폭포수 모델은 관리자급 직원에 의해 요구사항 분석과 설게가 이루어지므로 수직적인 구조를 가집니다. 반대로, 스크럼 모델은 팀 단위로 조직되며 팀원 간의 수평적인 구조를 요구합니다. 팀장의 강압이나 명령보다는 팀의 자율성을 통해 아이디어를 마음껏 제안하고 거기에서 개선점을 찾는 창의력을 발산할 수 있어야 합니다.
즉, 폭포수 모델은 부분부분 완전하게 완성해 나간다면, 애자일 모델은 완성도는 부족하지만 전체를, 그리고 이를 자주 반복적으로 수정하고 통합하여 배포를 한다고 보면 되겠습니다.