일을 처리하는 과정이나 순서를 프로세스라고 합니다. 즉, 프로세스는 주어진 일을 해결하기 위한 목적으로 순서가 정해져 수행되는 일련의 절차라고 할 수 있습니다.
소프트웨어 개발 프로세스
소프트웨어를 개발하는 과정에서 수행하는 가장 작은 단위를 작업(task)라고 합니다. 그리고 소프트웨어 개발에서 이런 작업들이 모여 프로세스를 이룹니다. 이때 프로세스는 단순히 작업 순서뿐만이 아니라 일정, 예산, 자원과 같은 조건들을 포함하는 일련의 활동들을 말합니다.
좁은 의미의 소프트웨어 개발 프로세스는 소프트웨어를 개발할 때 필요한 절차나 과정으로 요구사항을 소프트웨어로 구현하기 위한 활동입니다. 넒은 의미로는 절차나 과정을 포함해 작업을 수행하는데 필요한 방법과 도구를 비롯한 개발과 관련한 작업자들까지 포함이 됩니다. 즉, 소프트웨어 개발을 하는데 필요한 통합적 수단을 의미합니다.
소프트웨어 개발 프로세스는 수많은 경험에 의해 축적된 지식들이 모여 탄생한 것으로 시행착오를 줄이고 빠르게 적응해서 일을 할 수 있도록 하는 가이드라고 할 수 있습니다.
소프트웨어 개발 프로세스 모델
소프트웨어 개발 프로세스 모델은 소프트웨어를 어떻게 개발할 것인가에 대한 전체적인 흐름을 체계화한 개념입니다. 소프트웨어 개발의 전체 과정을 하나의 프로세스로 정의하기에 주어진 자원으로 개발하고 관리하는 방법에 대해서 구체적으로 정의하고 있습니다. 이러한 정의들을 통해 고품질의 소프트웨어를 개발하는 것을 목적으로 두고 있습니다.
또한 프로젝트 진행에 대한 전체적인 골격을 세워줍니다. 이는 일정 계획, 개발 비용 산정, 개발 참여자 간의 의사소통 기준, 개발 진행 상황의 파악, 단계별 산출물의 검토와 같은 역할을 합니다.
모델 소개
주먹구구식 모델
주먹구구식 모델(build and fix)은 공식적인 가이드라인이나 프로세스 없이하는 개발 방식입니다. 이 방식은 즉흥적 개발, 코딩과 수정 모델이라고 부르기도 합니다.
주먹구구식 모델은 코딩(구현)을 먼저 한 후에 요구분석이나 설계, 유지보수에 대해 생각하는 방식입니다.
이 방식은 관리나 유지보수가 굉장히 어렵고, 일을 나눠서 할 수 없으며 프로젝트 진척사항도 알기 어렵다는 문제점이 있습니다. 따라서 개발자 한 명이 단기간에 작업을 마칠 수 있는 간단한 개발(대학 수업용 프로젝트)에서나 사용되는 방식입니다.
선형 순차적 모델
선형 순차적 모델(linear sequential)은 폭포수 모델(waterfall)로 더 잘 알려진 모델입니다. 초기에 개발된 전통적인 모델로 표준 프로세스를 정하고 소프트웨어를 순차적으로 개발하는 모델입니다. 고전적 생명주기라고도 합니다.
이하에서는 가장 잘 알려진 모델인 폭포수 모델이라고 부르겠습니다.
폭포수 모델은 계획, 요구분석, 설계, 구현, 테스트, 유지보수의 단계들이 하향식으로 진행되며, 병행이나 거슬러 올라가지 않습니다. 따라서 각 단계의 종료마다 확실하게 작업을 종료하고 그 결과를 확인한 뒤 다음 단계로 내려갑니다.
폭포수 모델의 장점은 다음과 같습니다.
- 관리가 용이하다.
- 체계적으로 문서화할 수 있다.
- 요구사항의 변화가 적은 프로젝트에서 효과적이다.
다만 문서화는 문서화 과정에 시간이 과도하게 들거나, 요구사항 변화에 유연하지 못하다는 문제점을 수반하고 있습니다.
단점은 다음과 같습니다.
- 각 단계는 이전 단계가 완료되어야 수행된다.
- 각 단계의 결과물이 완벽한 수준이 되어야 다음 단계에서 오류없이 작업을 수행할 수 있다.
- 사용자가 중간에 가시적인 결과를 볼 수 없다.
최근의 소프트웨어 개발은 요구사항이 끊임없이 변화하고 있습니다. 따라서 폭포수 모델의 채택률은 그다지 높지 않게 되었습니다.
V 모델
V 모델은 폭포수 모델의 변형 모델로, 테스트 단계를 확장한 모델입니다. 폭포수 모델이 산출물(문서화) 중점이었다면 V 모델은 각 개발 단계에 대한 검증에 초점을 두어 오류를 줄이는데 중점을 두고 있습니다.
진화적 프로세스 모델
폭포수 모델의 단점이었던 거슬러 올라가는 것이 불가능함에서 오는 요구사항 변화 대처에 약하다라는 문제점에 대응하기 위해 진화적 프로세스 모델(evolutionary process)가 등장했습니다. 이 방식의 대표적인 방법은 프로토타입 모델입니다.
프로토타입(prototype): 대량 생산에 앞서 미리 제작한 시제품.
소프트웨어 개발에서 프로토타입은 완전한 소프트웨어 개발 이전에 사용자의 요구에 맞춰 모형 소프트웨어를 만들고 사용자와 의사소통 도구로 이용하게 됩니다.
프로토타입을 만들고 사용자에게 보여주고, 사용자는 프로토타입을 경험한 뒤 추가적인 요구사항을 줍니다. 그리고 요구사항이 더 이상 나오지 않을 때까지 반복합니다. 이때 프로토타입은 사용자 인터페이스를 중심으로 설계하게 됩니다.
프로토타입 모델의 장점은 다음과 같습니다.
- 프로토타입이 사용자와 개발자간의 의사소통 도구로 사용된다.
- 프로토타입 개발을 반복하기에 사용자의 요구가 충분히 반영된 요구분석명세서가 나온다.
- 초기 프로토타입에서 새로운 요구사항을 발견할 수 있다.
- 사용자의 요구가 충분히 반영되어 유지보수 비용을 줄일 수 있다.
단점은 다음과 같습니다.
- 반복적인 프로토타입 개발로 인해 필요한 인력/비용 산정이 어렵다.
- 프로토타입 개발 과정의 관리/통제가 어렵다.
- 개발 범위가 불명확해 개발 목표나 종료 시점이 불명확해진다.
나선형 모델
나선형 모델은 프로토타입 모델에 위험 분석단계가 추가된 모델입니다.
위험 분석 단계에서 분석하는 위험은 빈번하게 변경되는 요구사항, 개발 팀원의 경험 부족/팀워크/이직,프로젝트 관리의 부재와 같은 개발 과정에서 어려움을 주는 요소들을 의미합니다.
나선형 모델의 장점은 다음과 같습니다.
- 갑작스럽게 발생하는 위험으로 인해 프로젝트가 중단될 확률이 낮아진다.
- 사용자 요구가 충분히 반영된 결과물이 나오기에 사용자의 불만이 적어진다.
단점은 다음과 같습니다.
- 프로젝트 기간이 길어질 수 있다.
- 반복 횟수가 늘어나면 프로젝트 관리가 어려워진다.
- 위험 관리가 중요하기에 위험 관리 전문가가 필요하다.
단계적 개발 모델
단계적 개발 모델(phased development)은 개발과 사용을 병행하며 개발을 완료해나가는 모델입니다.
릴리스 하나를 개발하고, 사용자가 릴리스를 사용할 동안 다음 버전 릴리스를 개발하는 과정을 반복합니다.
단계적 개발 모델은 릴리스 구성 방식에 따라 점증적 개발과 반복적 개발로 나뉩니다.
점증적 개발
점증적 개발은 중요하다고 생각되는 부분부터 개발한 뒤, 그 일부를 사용하면서 개발 범위를 늘려나가는 방식입니다.
예를 들어 홈페이지를 개발한다고 가정하면, 메인 페이지를 만들어서 사용하게 합니다. 그 후 필요에 따라서 기타 기능들을 개발해서 추가시키는 방식입니다.
이 방식은 한 번에 많은 비용이 들지 않습니다. 또한 완전히 새로운 시스템 전체를 한 번에 줄 때도 조직이 받는 충격을 완화시킬 수 있습니다. 하지만 서브시스템들이 서로 관련이 있기에 처음에 설계할 때부터 다른 서브시스템과의 연관성을 고려하고 설계해야 합니다. 이 과정에서 통합에 어려움을 겪을 수 있습니다.
반복적 개발
반복적 개발은 처음에 시스템 전체를 한 번에 개발합니다. 그 후 각 서브시스템의 기능과 성능을 변경하거나 보강해서 완성도를 높입니다. 이렇게 개발된 릴리스 버전을 내놓으며 개발을 합니다.
실제 개발 환경에서는 점증적 개발과 반복적 개발을 함께 사용하는 경우가 많습니다.
통합 프로세스 모델
갈수록 소프트웨어는 규모도 커지고 복잡해지고 있습니다. 이런 환경에서 요구사항 등의 변화에 유연하게 대처할 수 있도록 개발 과정을 반복해서 사용하는데, 이러한 과정을 반복적 생명주기라고 합니다.
대표적으로 반복적 생명주기를 이용하는 모델이 통합 프로세스 모델(Unified Process)입니다. 통합 프로세스 모델은 UML(Unified Modeling Language)라는 것과 함께 사용됩니다.
통합 프로세스 모델은 크게 도입, 구체화, 구축, 전이의 4단계로 구성됩니다. 이때 각 단계를 여러개의 작은 단위로 나누어 반복하고 정복해 나가며 진행합니다. 각 반복 주기에선 실행 가능한 산출물이 나오고 이를 통해 위험을 관리하게 됩니다.
통합 프로세스 모델의 진행을 나타낸 그림입니다. 그림에서 보이듯이 여러개의 개발 영역이 동시에 수행됨을 알 수 있습니다. 출처
- 도입: 비지니스 모델링이나 요구사항 분석이 주로 이루어지는 단계입니다.
- 구체화: 분석과 설계가 가장 활발하게 이루어집니다.
- 구축: 구현이 가장 활발하게 일어나는 단계입니다. 또한 구현에 따른 테스트도 빈번하게 수행됩니다.
- 전이: 사용자를 위한 제품을 완성시키는 단계입니다. 사용자에게 넘기기위해 배치작업이 가장 많이 일어납니다.
모든 단계에서 형상/변화 관리, 프로젝트 관리, 환경 점검은 지속적으로 수행됩니다
애자일 프로세스 모델
애자일(agile): 날렵한, 민첩한
애자일 프로세스 모델(agile process)은 고객의 요구사항에 대해 민첩하게 대응하고, 그때그때 주어지는 문제를 풀어나가는 모델입니다.
이 모델은 빈번하게 발생되는 요구사항에 대처하기 위해 변화를 수용하기 쉽도록한 방법론을 사용합니다.
애자일에서 사용하는 방법론에는 다음과 같은 것들이 있습니다.
스크럼, 익스트림 프로그래밍, 적응형 소프트웨어 개발, 린 소프트웨어 개발, 크리스탈 패밀리, 기능 주도 개발론, 동적 시스템 개발 방법론, 애자일 UP
애자일 선언문
- 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시한다.
- 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시한다.
- 계약과 협상 중심이 아닌, 고객과의 협력을 중시한다.
- 계획 중심이 아닌, 변화에 민첩한 대응을 중시한다.
즉, 애자일은 고객과의 협업, 단시간에 고객이 작동시킬 수 있는 소프트웨어, 환경과 요구사항 변화에 능동적으로 대처하는 것에 중점을 두고 있습니다.
애자일 프로세스 모델은 반복적인 개발을 통해 자주 출시하는 것을 목표로 하고 있습니다. 실행가능한 프로토타입을 통해 고객에게 확인을 받고, 단기간에 사용가능한 소프트웨어를 만드는 것을 중요하게 생각합니다.
스크럼
스크럼(Scrum)은 럭비에서 온 단어입니다. 간단하게 설명하자면 아래 사진처럼 서로 어깨동무로 팔을 잡은 뒤 하나의 대형으로 집단을 만들어 상대팀을 밀어내는 진형입니다. 즉, 팀이 하나가 되어 단단하게 앞으로 나아가는 대형이죠.
소프트웨어 개발에서 스크럼은 개발 자체보담는 팀의 개선, 프로젝트 관리에 중점을 둔 애자일 방법론입니다. 스크럼은 구체적인 프로세스를 명확하게 제시하지 않습니다.
스크럼은 제품 기능 목록 작성 -> 스프린트 계획 회의 -> 스프린트 수행 -> 스프린트 개발 완료 -> 스프린트 완료의 과정을 반복하며 진행됩니다.
제품 기능 목록은 사용자의 요구사항이 적힌 문서입니다. 하지만 요구사항에 우선순위가 적용되어 있다는 것이 특징입니다.
스프린트(sprint)는 전력 질주라는 의미인데, 일반적으로 단거리 달리기 경주(100m)를 의미합니다. 개발에서 스프린트는 작업량이 많지 않고 개발 기간도 짧은 것을 의미합니다. 즉, 작은 단위의 개발 업무를 단기간에 수행한다는 것을 의미합니다. (보통 1달 이내)
스프린트를 진행하는동안 매일 짧고 간단하게 진척사항을 회의합니다. (일일 스프린트 회의)
스프린트가 종료되면 스프린트 검토 회의와 회고를 하는데, 검토 회의는 실행가능한 산출물을 검토합니다. 주로 비즈니스 가치를 점검합니다. 그리고 검토 회고는 개선할 점이나 팀 규칙 준수 등을 검토합니다. 즉, 회의는 산출물의 품질을 회고는 팀과 팀원에 대한 것을 확인합니다.
스크럼의 장점은 다음과 같습니다.
- 반복 주기마다 생성되는 제품으로 사용자와의 의견을 충분히 나눌 수 있다.
- 일일 회의를 통해 팀원 간의 신속한 협조와 조율이 가능하다.
- 자신의 일정을 직접 발표해, 업무 집중 환경이 조성된다.
- 다른 개발 방법론에 비해 단순하고 실천하기 쉽다.
- 프로젝트의 진행상황을 볼 수 있어서 신속하게 목표와 결과의 추정이 쉽다.
단점은 다음과 같습니다.
- 반복 주기마다 실행/테스트 가능한 산춘물이 만들어져야 한다.
- 일일 스크럼 회의가 꼭 짧게 끝나리란 것을 보장하지 못한다.
- 작업이 얼마나 효율적으로 수행되고 있는지 알기 어렵다.
- 프로젝트 관리에 중점을 두었기 때문에 프로세프 품질을 측정하기 어렵다.
