맨위로가기

소프트웨어 개발 프로세스

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

소프트웨어 개발 프로세스는 소프트웨어 시스템을 개발하기 위한 방법론과 절차를 의미한다. 1960년대 시스템 개발 생명 주기(SDLC)의 등장으로 시작되어, 폭포수 모델, 애자일 개발, 나선형 모델, RAD 등 다양한 방법론이 개발되었다. 개발 방법론은 프로젝트의 특성과 조직의 상황에 따라 선택되며, 요구 사항 분석, 명세 기술, 소프트웨어 아키텍처 설계, 구현, 테스트, 문서화, 배포 및 유지보수 등 여러 단계를 거친다. 프로세스 메타 모델로는 ISO/IEC 12207, CMMI, ISO 9000 등이 있으며, 소프트웨어 개발 계획서, 요구 사양서 등의 산출물을 생성한다.

더 읽어볼만한 페이지

  • 방법론 - 궤변
    궤변은 발언자가 유리한 결론을 내기 위해 의도적으로 잘못된 논리를 전개하는 것으로, 소피스트로부터 발전하여 정치, 설득 등에 이용되었으며, 다양한 논리적 오류를 포함하고 비판적 사고 능력 향상에 기여한다.
  • 방법론 - 진리와 방법
    한스-게오르크 가다머의 대표작인 진리와 방법은 철학적 해석학의 개념을 설명하고, 진리와 방법의 대립을 통해 과학적 방법론의 한계를 지적하며, 인간 의식의 역사적, 문화적 뿌리와 텍스트 해석의 지평 융합을 강조하는 책이다.
  • 소프트웨어 개발 프로세스 - 버전 관리
    버전 관리는 파일 변경 이력을 체계적으로 관리하는 시스템이며, 다양한 구조와 소스 관리 모델을 통해 협업을 지원하고, 비즈니스 등 다양한 분야에서 활용된다.
  • 소프트웨어 개발 프로세스 - 소프트웨어 개발 수명 주기
    소프트웨어 개발 수명 주기(SDLC)는 시스템 설계자와 개발자가 따르는 일련의 단계로, 예비 분석부터 폐기까지 여러 단계를 거치며, 폭포수 모델, 시스템 분석 및 설계(SAD), 객체 지향 분석 및 설계(OOAD) 등 다양한 방법론을 포함한다.
  • 소프트웨어 공학 - 통합 개발 환경
    통합 개발 환경(IDE)은 코드 편집, 빌드, 디버깅 등 소프트웨어 개발에 필요한 여러 기능을 통합적으로 제공하는 응용 프로그램이다.
  • 소프트웨어 공학 - 소프트웨어 개발
    소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
소프트웨어 개발 프로세스
소프트웨어 개발
정의소프트웨어 개발은 컴퓨터 프로그램 개발을 위한 프로세스이다.
주요 활동소프트웨어
소프트웨어 개발
요구 분석
소프트웨어 아키텍처
소프트웨어 설계
소프트웨어 엔지니어링
프로그래밍
소프트웨어 테스트
디버깅
소프트웨어 배포
소프트웨어 유지보수
패러다임 및 모델
소프트웨어 개발 방법론 및 프레임워크
개발 지원
실천법
프로그래밍 도구
표준 및 기관
용어집

2. 역사

소프트웨어 개발 방법론 프레임워크는 1960년대에 이르러 등장하기 시작했다. 엘리엇(Elliott, 2004)에 따르면, 시스템 개발 생명 주기(SDLC)는 정보 시스템 구축을 위한 가장 오래된 공식화된 방법론 프레임워크로 여겨진다. SDLC의 핵심 아이디어는 정보 시스템 개발 과정을 매우 신중하고 구조화된 방식으로 진행하는 것이었다. 즉, 아이디어 구상부터 최종 시스템 구현까지 각 단계를 엄격하고 순차적으로 수행하는 것을 목표로 했다.[1] 1960년대 당시 이러한 방법론의 주된 목표는 대규모 기업 환경에서 필요한 기능 중심의 비즈니스 시스템을 개발하는 것이었으며, 주로 대규모 데이터 처리와 계산 작업에 초점이 맞춰졌다.[1]

이후 소프트웨어 개발 방법론은 지속적으로 발전해왔다. 조직의 필요에 따라 구체적인 단계를 제시하는 방법론부터, 특정 프로젝트나 그룹의 요구에 맞게 조정할 수 있는 유연한 프레임워크까지 다양하게 개발되었다. 때로는 특정 조직이 공식 문서를 통해 자체적인 프로세스를 배포하기도 한다. 시대별로 다양한 개발 방법론들이 등장했으며, 이는 하위 섹션에서 자세히 다룬다.

한편, 오픈 소스 개발 커뮤니티에서도 독자적인 개발 프로세스와 모범 사례들이 확립되었다. 이러한 방식을 기업 내부에서 채택하여 활용하는 것을 이너 소스라고 부른다. 또한, 미국에서는 군수 계약을 따내기 위한 조건으로 프로세스 모델 기반의 평가가 요구되면서, 이러한 평가 시스템이 소프트웨어 개발 방법론의 발전을 촉진하는 요인이 되기도 했다.

2. 1. 1970년대

1970년대에는 다음과 같은 주요 소프트웨어 개발 방법론이 등장했다.

  • 구조적 프로그래밍 (1969년 이후)
  • Cap Gemini SDM (원래 PANDATA에서 유래했으며, 첫 영어 번역은 1974년에 출판됨). SDM은 시스템 개발 방법론(System Development Methodology)의 약자이다.

2. 2. 1980년대

1980년대에는 다음과 같은 주요 소프트웨어 개발 방법론들이 등장했다.

  • 구조적 시스템 분석 및 설계 방법 (SSADM): 1980년부터 사용되었다.
  • 정보 요구 사항 분석/소프트 시스템 방법론: 정보 요구 사항 분석 및 소프트 시스템 방법론도 이 시기에 등장했다.

2. 3. 1990년대

1990년대에는 소프트웨어 개발 분야에서 중요한 변화가 있었다. 특히 객체 지향 프로그래밍 (OOP)이 이 시기에 주류 프로그래밍 방식으로 자리 잡았다. OOP 자체는 1960년대 초에 개발되었지만, 1990년대 중반에 이르러 널리 사용되기 시작했다.

이 시기에는 다음과 같은 새로운 개발 방법론들이 등장했다.

  • Rapid application development (RAD): 1991년 이후 등장.
  • Dynamic systems development method (DSDM): 1994년 이후 등장.
  • 스크럼: 1995년 이후 등장.
  • 팀 소프트웨어 프로세스: 1998년 이후 등장.
  • Rational Unified Process (RUP): 1998년 이후 등장했으며, IBM에서 관리한다.
  • 익스트림 프로그래밍: 1999년 이후 등장.


1994년 DSDM 이후 등장한 방법론들 중 RUP를 제외한 대부분은 이후 애자일 방법론으로 분류된다.[2] 하지만 많은 조직, 특히 정부 기관에서는 여전히 폭포수 모델과 같은 전통적인 방식을 사용하기도 한다.[2] 소프트웨어 개발 프로세스와 소프트웨어 품질은 밀접하게 연관되어 있으며, 실제 적용 과정에서 예상치 못한 결과가 나타나기도 한다.[2]

2. 4. 2000년대


  • Agile Unified Process (AUP): 2005년부터 Scott Ambler가 관리하였다.
  • Disciplined agile delivery (DAD): AUP를 대체하며 등장하였다.

2. 5. 2010년대

2010년대에 들어서면서 다음과 같은 소프트웨어 개발 관련 접근 방식들이 등장하였다.

  • Scaled Agile Framework (SAFe)
  • Large-Scale Scrum (LeSS)
  • DevOps

3. 개발 방법론 종류

소프트웨어 개발의 프로세스를 체계적으로 관리하기 위한 모델을 개발 공정 모델 또는 개발 방법론이라고 부른다. 다양한 소프트웨어 생명 주기에서 공통적으로 나타나는 여러 종류의 모델이 존재하며, 각각의 모델은 고유한 특징을 가지고 있다. 따라서 실제 개발 프로젝트에서는 해당 프로젝트의 특성과 요구사항에 가장 적합한 소프트웨어 개발 방법론을 신중하게 선택하는 것이 매우 중요하다.

대표적인 개발 방법론으로는 전통적인 방식인 폭포수 모델을 비롯하여, 변화에 유연하게 대응하는 애자일 소프트웨어 개발, 위험 관리를 강조하는 나선형 모델, 시스템을 작은 단위로 나누어 개발하는 점증적 개발, 빠른 개발 속도를 중시하는 신속 응용 개발(RAD) 등이 있다. 이 외에도 Shape Up, V 모델, 통합 프로세스(UP) 등 다양한 방법론들이 존재하며, 프로젝트의 목표, 규모, 복잡성, 요구사항의 변경 가능성 등을 고려하여 최적의 방법론을 선택하거나 여러 방법론의 장점을 조합하여 사용하기도 한다.

미국에서는 군수 관련 계약을 따내기 위한 조건으로 특정 프로세스 모델 준수 여부와 그에 따른 평가를 요구하는 경우가 있었는데, 이러한 제도적 환경이 소프트웨어 개발 방법론의 체계화와 발전에 영향을 미치기도 했다.

3. 1. 폭포수 모델 (Waterfall Model)

폭포수 모델로 표현된 소프트웨어 개발 프로세스의 활동. 이 프로세스를 나타내는 다른 여러 모델이 있다.


폭포수 모델은 소프트웨어 개발 프로세스의 하나로, 개발 과정을 순차적인 단계들로 나누어 마치 폭포수처럼 각 단계가 완료되어야 다음 단계로 진행하는 방식이다.[14] 이는 소프트웨어 공학에 적용된 전통적인 공학적 접근 방식이다.

일반적으로 다음과 같은 단계를 순서대로 거친다.

  • 요구 사항 분석을 통해 소프트웨어 요구 사항 명세서 생성
  • 소프트웨어 설계
  • 구현
  • 테스팅
  • 여러 하위 시스템이 있는 경우 통합
  • 배포 (또는 설치)
  • 유지 보수


이 방법론에 대한 최초의 공식적인 설명은 1970년 윈스턴 W. 로이스[6]가 발표한 논문으로 알려져 있지만, 로이스는 해당 논문에서 '폭포수'라는 용어를 사용하지 않았으며 오히려 이 모델을 결함이 있는 모델의 예시로 제시했다.[7]

폭포수 모델의 기본 원칙은 다음과 같다.[14]

  • 프로젝트를 순차적인 단계로 나누며, 단계 간 약간의 중복이나 재작업은 허용될 수 있다.
  • 초기 단계에서 계획, 일정, 예산 및 전체 시스템 설계를 확정하는 데 중점을 둔다.
  • 각 단계가 끝날 때마다 문서화, 공식 검토, 사용자 및 관리자의 승인을 통해 프로젝트 전반에 걸쳐 엄격한 통제를 유지한다. 문서화는 각 단계의 중요한 결과물이다.


이 모델은 각 단계가 명확하게 구분되어 프로젝트 관리가 용이하다는 장점이 있다. 특히 각 단계별 산출물이 명확하여 진행 상황을 파악하기 쉽다.

그러나 한 단계가 완전히 끝나야 다음 단계로 넘어가는 경직성 때문에 변화에 매우 취약하다는 단점이 있다. 개발 과정 중 요구사항 변경이나 문제 발생 시 이전 단계로 돌아가 수정하기 어렵고, 이로 인해 비용과 시간이 크게 증가할 수 있다. 엄격한 폭포수 방식은 이전 단계의 재검토나 수정을 권장하지 않는 것으로 알려져 있다. 이러한 유연성 부족은 사전 대규모 설계 접근 방식과 맞물려, 특히 대규모 공공 프로젝트나 정부 주도 사업에서 예산 초과, 개발 지연, 최종 결과물이 사용자의 실제 요구를 만족시키지 못하는 문제의 원인으로 지적받기도 한다. 이러한 문제 때문에 계약상 요구되는 특별한 경우를 제외하고는, 실제 개발 현장에서는 애자일 방법론 등 변화에 더 유연하게 대처할 수 있는 다른 방법론들이 선호되는 추세이다. 폭포수 모델 비판 참조. 한국에서도 과거 대규모 시스템 통합(SI) 프로젝트에 폭포수 모델이 주로 적용되었으나, 최근에는 공공 소프트웨어 사업 등에서 경직된 폭포수 모델의 한계를 지적하며 보다 유연하고 혁신적인 개발 방식 도입을 요구하는 목소리가 커지고 있다.

폭포수 모델은 요구사항이 명확하고 변경 가능성이 적은 프로젝트, 또는 군수 관련 계약처럼 각 공정 단계별로 명확한 구분과 승인이 필요한 대규모 시스템 개발에 여전히 사용될 수 있다. 대규모 시스템 개발 시에는 전체 시스템을 여러 하위 시스템으로 나누어 각 서브 시스템 개발에 시차를 두고 폭포수 모델을 적용하기도 한다. 이를 통해 선행 서브 시스템 개발에서 얻은 교훈을 후속 시스템에 반영하거나, 개발 단계별 인력 및 자원 투입을 효율적으로 관리할 수 있다. 또한, 각 개발 단계 내부적으로는 스파이럴 모델이나 반복적 개발 방식을 혼합하여 사용하는 경우도 있다.

폭포수 모델 적용 시 발생하는 문제들은 종종 요구사항 분석 및 관리의 미흡함, 개발 공정에 대한 이해 부족, 그리고 고객과 개발자 간의 충분한 소통 부재에서 비롯되기도 한다. 개발자는 위험을 감수하고 설계를 진행하지만, 최종 설계는 Critical Design Review(최종 설계 심사)와 같은 마일스톤에서 점검받게 된다.

3. 2. 애자일 개발 (Agile Development)

애자일 소프트웨어 개발은 소프트웨어 개발 방법론의 한 종류로, 짧은 주기의 반복적인 개발을 통해 소프트웨어를 만들어 나가는 방식들의 그룹을 의미한다. 이 방식에서는 요구사항과 해결책이 개발팀 스스로 조직되고 다양한 역할을 수행하는 팀원들 간의 긴밀한 협력을 통해 점진적으로 발전해 나간다. '애자일(Agile)'이라는 용어는 2001년 발표된 애자일 선언문을 통해 널리 알려지게 되었다.

애자일 개발은 반복적 개발을 기반으로 하지만, 기존의 전통적인 개발 방식보다 더 가볍고 사람 중심적인 접근을 강조한다. 개발 과정을 여러 번의 짧은 주기로 나누어 반복하며, 각 주기마다 실제 작동하는 소프트웨어의 일부를 만들어내고 이에 대한 피드백을 지속적으로 반영하여 소프트웨어 시스템을 꾸준히 개선하고 발전시키는 것이 핵심이다. 이를 통해 변화하는 요구사항에 유연하게 대응하고 고객의 요구를 빠르게 반영할 수 있다는 장점이 있다.

애자일 개발은 과거의 엄격하고 순차적인 폭포수 모델과 같은 전통적인 개발 방식에 대한 대안으로 등장했다. 폭포수 모델은 요구사항 분석, 설계, 구현, 테스트 등의 단계를 순서대로 진행하며 이전 단계로 돌아가기 어려운 경직된 구조를 가지고 있어, 변화에 대응하기 어렵고 프로젝트가 길어지거나 예산을 초과하는 등의 문제가 발생하기 쉽다는 비판을 받았다.[7][14] 애자일은 이러한 문제점을 극복하고자 계획보다는 실제 작동하는 소프트웨어와 지속적인 피드백을 더 중요하게 생각한다.

하지만 애자일 방식에도 고려할 점이 있다. 반복 주기가 짧고 변화에 열려있기 때문에 장기적인 계획을 세우기 어려울 수 있으며, 고객이나 사용자의 적극적인 참여가 중요하여 때로는 이것이 부담이 될 수도 있다.[19] 또한, 문서화보다는 실제 작동하는 소프트웨어 자체를 중시하는 경향이 있어 체계적인 문서 관리가 부족해질 수 있다는 지적도 있다.

애자일 개발 모델에는 다양한 구체적인 방법론들이 포함된다. 대표적인 예로는 다음과 같은 것들이 있다.

이러한 방법론들은 애자일의 기본 철학을 공유하면서도 각기 다른 방식으로 프로젝트를 관리하고 개발을 진행한다.

3. 2. 1. 스크럼 (Scrum)

스크럼은 애자일 소프트웨어 개발 방법론 중 하나이다. 애자일 소프트웨어 개발은 반복적 개발을 기반으로 하는 프레임워크 그룹을 지칭하며, 자기 조직적이고 다기능 팀 간의 협업을 통해 요구 사항과 솔루션을 발전시키는 특징을 가진다. 애자일 프로세스는 반복을 통해 지속적인 피드백을 얻고 소프트웨어 시스템을 개선하는 것을 목표로 한다.

애자일 모델에는 스크럼 외에도 다음과 같은 개발 프로세스가 포함된다.

  • 동적 시스템 개발 방법론 (DSDM)
  • 칸반
  • 린 소프트웨어 개발

3. 2. 2. 칸반 (Kanban)

애자일 소프트웨어 개발 모델에 포함되는 개발 프로세스 중 하나로 칸반이 있다.

3. 2. 3. 익스트림 프로그래밍 (XP)

익스트림 프로그래밍(XP)은 애자일 소프트웨어 개발 방법론 중 가장 널리 알려진 것 중 하나이다. XP는 기존의 폭포수 모델과 같이 수개월에서 수년에 걸리는 개발 공정을 1일에서 1주일 단위의 매우 짧은 주기로 나누어 진행하는 것이 특징이다.

XP의 개발 과정은 다음과 같은 단계를 따른다.

# 각 개발 주기가 시작될 때, 먼저 자동화된 단위 테스트를 작성하여 해당 공정에서 달성해야 할 목표를 명확히 한다.

# 다음으로, 두 명의 프로그래머가 함께 작업하는 페어 프로그래밍 방식으로 코드를 작성한다.

# 작성된 코드가 미리 정의된 모든 테스트를 성공적으로 통과하면 해당 단계의 공정이 완료된 것으로 간주한다.

설계와 아키텍처 구축 방식도 독특하다. 초기 단계에서 상세한 설계를 하기보다는, 코드를 우선 작성하고 이후 리팩토링 과정을 통해 지속적으로 코드 구조를 개선하며 설계와 아키텍처를 점진적으로 완성해 나간다. 설계 작업은 코딩을 담당하는 개발자가 직접 수행한다. 설계와 코드의 통합은 다른 애자일 방법론과 마찬가지로 꾸준히 이루어진다.

또한, 아직 모든 기능이 완성되지 않았더라도 현재까지 개발된, 작동 가능한 시스템을 사용자[19]에게 배포하여 직접 사용해 보게 하고 피드백을 받는다. 이 피드백과 평가는 다음 개발 주기에서 어떤 부분을 중요하게 다룰지 결정하는 데 활용되며, 해당 부분에 대한 테스트를 작성하면서 다음 개발 주기가 시작된다.

애자일 커뮤니티에서는 리팩토링을 상세한 설계 문서를 미리 작성하는 방식의 대안으로 제시하기도 한다. 리팩토링은 기존 코드에 대해 10%에서 15%의 비용 증가를 유발한다고 알려져 있으나, 이 값에 재평가나 회귀 테스트 비용이 포함되어 있는지는 불분명하다. XP는 코드 수준의 리팩토링을 강조하지만, 소프트웨어의 근본적인 아키텍처 문제를 해결하기 위한 리엔지니어링의 명확한 대안을 제시하지는 않는다는 지적도 있다.

테스트 주도 개발(TDD)은 XP에서 파생된 기법으로, 코드를 작성하기 전에 해당 코드에 대한 단위 테스트를 먼저 작성하는 개발 방식이다. 이를 위해서는 코드를 작성하기 전에 어떤 기능을 구현할지 상세하게 결정해야 한다. 따라서 TDD를 애자일적이지 않은 개발 공정 모델에 도입하는 것은 오히려 애자일 원칙과 상반될 수 있다는 비판도 존재한다.

3. 2. 4. 기타 애자일 방법론

애자일 모델은 다음 소프트웨어 개발 프로세스를 포함한다.

  • 동적 시스템 개발 방법론 (DSDM)
  • 칸반
  • 스크럼
  • 린 소프트웨어 개발

3. 3. 점증적 개발 (Incremental Development)

점증적 개발은 선형적 개발 방식과 반복적 개발 방식을 결합하는 다양한 방법 중 하나이다. 주요 목표는 프로젝트를 더 작은 단위로 나누고 개발 과정에서 변경을 쉽게 하여 프로젝트에 내재된 위험을 줄이는 것이다.[14]

점증적 개발에는 세 가지 주요 변형이 있다:[14]

# 일련의 작은 폭포수 방식을 연속적으로 수행한다. 시스템의 작은 부분에 대해 폭포수의 모든 단계(요구사항 분석, 소프트웨어 설계, 구현, 테스팅 등)를 완료한 후 다음 증분으로 넘어간다.

# 전체 요구사항을 먼저 정의한 후, 시스템의 각 증분을 점진적으로 개발한다. 각 증분 개발은 작은 폭포수 방식으로 진행될 수 있다.

# 초기 소프트웨어 개념 구상, 요구사항 분석, 아키텍처 및 시스템 핵심 설계는 폭포수 방식으로 정의한다. 이후 점증적으로 기능을 구현하며, 최종적으로 작동하는 시스템을 완성하여 배포한다.

3. 4. 나선형 모델 (Spiral Model)

나선형 모델(Boehm, 1988)


1988년, 배리 뵘은 공식적인 소프트웨어 시스템 개발 방법으로 '나선형 모델'을 발표했다.[8] 이는 기존의 폭포수 모델과 신속 프로토타입 개발 방법론의 주요 특징들을 결합하려는 시도였다. 특히 하향식 및 상향식 개념의 장점을 모두 활용하고자 했다. 나선형 모델의 가장 큰 특징은 다른 방법론들에서 상대적으로 간과되었던 위험 분석을 개발 과정의 핵심 요소로 삼았다는 점이다. 이 때문에 의도적인 반복을 통해 위험을 관리하는 방식은 특히 규모가 크고 복잡한 시스템 개발에 적합하다는 평가를 받는다.

나선형 모델의 기본 원칙은 다음과 같다.[14]

  • 위험 중심 접근: 프로젝트를 진행하면서 발생할 수 있는 위험을 미리 식별하고 분석하여 이를 최소화하는 데 초점을 맞춘다. 이를 위해 전체 프로젝트를 관리하기 쉬운 작은 단위로 나누고, 개발 과정에서 발생하는 변경 요구에 유연하게 대응한다. 각 단계마다 위험을 평가하고 프로젝트를 계속 진행할지 여부를 결정할 기회를 가진다.
  • 반복적 개발: 소프트웨어 개발은 나선형 경로를 따라 반복적으로 진행된다. "각 사이클은 제품의 각 부분과 각 수준의 정교화에 대해 동일한 일련의 단계를 거치며, 전반적인 운영 개념 문서에서 각 개별 프로그램의 코딩에 이르기까지 진행된다."[8] 즉, 초기 구상 단계부터 실제 코드 작성까지 동일한 개발 단계를 여러 번 반복하며 점진적으로 완성도를 높여간다.
  • 4단계 반복: 나선을 한 바퀴 도는 각 사이클은 다음 네 가지 주요 활동(사분면)으로 구성된다.[9]

1. 계획 수립: 해당 반복 단계의 목표를 설정하고, 가능한 대안들을 탐색하며, 제약 조건을 확인한다.

2. 위험 분석: 대안들을 평가하고 잠재적 위험 요소를 식별하여 해결 방안을 모색한다.

3. 개발 및 검증: 분석과 설계를 바탕으로 실제 결과물을 개발하고, 그것이 요구사항에 맞는지 검증한다.

4. 다음 단계 계획: 다음 반복 사이클을 위한 계획을 수립한다.

  • 이해관계자 참여: 각 사이클은 프로젝트 이해관계자들과 그들이 생각하는 "성공 조건"을 명확히 파악하는 것에서 시작하며, 사이클이 끝날 때는 진행 상황을 검토하고 다음 단계 진행에 대한 합의(약속)를 얻는 것으로 마무리된다.[10]


이처럼 나선형 모델은 위험 관리를 강화하고 변화에 유연하게 대처할 수 있다는 장점이 있어 대규모 프로젝트에 효과적일 수 있다. 하지만 반복적인 단계와 지속적인 위험 분석 과정 때문에 다른 모델에 비해 개발 과정이 복잡하고 시간이 더 오래 걸릴 수 있다는 단점도 고려해야 한다.

3. 5. 신속 응용 개발 (RAD, Rapid Application Development)

신속 응용 개발(RAD) 모델


신속 응용 개발(RAD, Rapid Application Development)은 소프트웨어 개발 방법론 중 하나로, 초기의 방대한 계획 수립보다는 반복적 개발과 프로토타입의 빠른 제작을 중시한다.[14] RAD 방식에서는 소프트웨어의 '계획'이 실제 개발 과정과 병행하여 진행되는 경향이 있어, 일반적으로 개발 속도가 빠르고 중간에 요구 사항 변경이 용이하다는 특징이 있다.

RAD의 개발 과정은 보통 구조적 기법을 활용하여 초기 데이터 모델과 비즈니스 프로세스 모델을 만드는 것으로 시작한다. 이후 프로토타입을 제작하여 사용자의 요구 사항을 확인하고, 이를 바탕으로 데이터 및 프로세스 모델을 개선해 나간다. 이 과정은 여러 차례 반복될 수 있으며, 최종적으로는 "새로운 시스템 구축에 사용될 비즈니스 요구 사항과 기술 설계 명세서가 결합된" 결과물을 만들어낸다.[5]

이 용어는 1991년 제임스 마틴이 소개한 개발 프로세스를 설명하며 처음 사용되었다. 데이터 중심의 정보 기술 엔지니어링과 같은 구조적 분석 및 설계 기법을 프로토타이핑 기법과 결합하여 소프트웨어 시스템 개발 속도를 높인 것으로 평가받는다.[5]

신속 응용 개발의 기본 원칙은 다음과 같다.[14]

원칙설명
주요 목표비교적 낮은 투자 비용으로 고품질 시스템을 신속하게 개발하고 제공한다.
위험 관리프로젝트를 작은 단위로 나누고 개발 중 변경이 용이하도록 하여 내재된 위험을 줄인다.
핵심 요소반복적인 프로토타이핑, 적극적인 사용자 참여, CASE 도구와 같은 전산화된 개발 도구 활용을 통해 고품질 시스템을 빠르게 생산한다. (예: GUI 빌더, DBMS, 4세대 프로그래밍 언어, 코드 생성기, 객체 지향 기법 등)
강조점기술적인 완성도보다는 실제 비즈니스 요구 사항을 충족시키는 데 더 중점을 둔다.
프로젝트 제어개발 우선순위를 정하고, 마감일(타임박스)을 설정한다. 일정이 지연될 경우 마감일을 연장하기보다 요구 사항을 줄여 타임박스를 맞추는 데 집중한다.
사용자 참여공동 응용 설계(JAD) 등을 통해 사용자가 시스템 설계 과정에 적극적으로 참여하며, 이는 필수적인 요소이다.
산출물폐기용 프로토타입이 아닌 실제 운영 가능한 소프트웨어를 반복적으로 생산한다.
문서화향후 개발 및 유지보수를 용이하게 하기 위해 필요한 문서를 생성한다.
호환성표준적인 시스템 분석 및 설계 방법론을 RAD 프레임워크에 맞게 적용할 수 있다.


3. 6. Shape Up

Shape Up은 2018년 베이스캠프(Basecamp)가 도입한 소프트웨어 개발 접근 방식이다. 이는 베이스캠프가 명확한 종료 시점 없이 프로젝트가 지연되는 문제를 해결하기 위해 내부적으로 개발한 원칙과 기술들의 모음이다. 주로 원격 팀을 대상으로 한다. Shape Up은 워터폴, 애자일, 또는 스크럼 방식과 달리, 추정, 속도 추적, 백로그, 스프린트 등을 사용하지 않는다. 대신 식욕(appetite), 베팅(betting), 사이클(cycle)이라는 개념을 사용한다. 2022년을 기준으로, 베이스캠프 외에도 UserVoice와 Block 등이 Shape Up 방식을 채택한 주요 조직으로 알려져 있다.

3. 7. 기타 방법론


  • 행위 주도 개발 및 비즈니스 프로세스 관리.[13]
  • 카오스 모델: 주요 규칙은 항상 가장 중요한 문제를 먼저 해결하는 것이다.
  • 점증적 자금 조달 방법론: 반복적인 접근 방식이다.
  • 경량 방법론: 규칙과 실천 사항이 몇 가지 없는 방법론에 대한 일반적인 용어이다.
  • 구조적 시스템 분석 및 설계 방법: 폭포수 모델의 특정 버전이다.
  • 슬로우 프로그래밍: 더 큰 슬로우 무브먼트의 일부로, 시간적 압박 없이 신중하고 점진적인 작업을 강조한다. 슬로우 프로그래밍은 버그와 지나치게 빠른 릴리스 일정을 피하는 것을 목표로 한다.
  • V 모델: 폭포수 모델의 확장이다.
  • 통합 프로세스(UP): 통합 모델링 언어(UML)를 기반으로 하는 반복적인 소프트웨어 개발 방법론 프레임워크이다. UP는 소프트웨어 개발을 네 단계(시작, 정교화, 구성, 지침)로 구성하며, 각 단계는 하나 이상의 실행 가능한 소프트웨어 반복으로 이루어진다.

4. 개발 프로세스

소프트웨어 개발 프로세스는 여러 종류의 하위 프로세스로 구성된다. 이러한 개발 하위 프로세스의 모델에는 다양한 종류가 있으며, 대표적인 표준 규격으로는 ISO 12207, 능력 성숙도 모델 통합(CMMI) 등이 있다. 주요 하위 프로세스는 다음과 같다.

;요구 사항 분석

: 소프트웨어를 만들기 위한 첫 단계로, 고객의 요구 사항을 파악하고 수집하여 일관성 있는 요구 사항 명세서로 정리하는 과정이다. 고객의 요구는 불완전하거나 모호할 수 있으므로, 경험 많은 기술자가 이를 명확히 하는 역할을 한다. (자세한 내용은 아래 하위 섹션 참조)

;명세 기술

: 개발할 소프트웨어를 정확하고 엄격하게 기술하는 과정이다. 특히 안전성이 중요한 시스템에서 중요하며, 외부 인터페이스 명세는 필수적이다.

;소프트웨어 아키텍처

: 시스템의 추상적인 구조를 설계하는 과정이다. 시스템이 요구 사항에 맞는지 검증하고, 향후 확장을 고려하며, 다른 소프트웨어나 하드웨어, 운영 체제와의 인터페이스를 규정한다.

;구현

: 설계를 바탕으로 실제 코드를 작성하는 단계이다. 개발 과정에서 가장 명확해 보이는 부분이지만, 반드시 가장 많은 시간이 소요되는 공정은 아니다. (자세한 내용은 아래 하위 섹션 참조)

;평가

: 개발된 코드를 검증하고 오류를 찾는 과정이다. 특히 여러 개발자가 작성한 코드를 통합하여 테스트하는 것이 중요하다. (자세한 내용은 아래 하위 섹션 참조)

;소프트웨어 문서화

: 소프트웨어의 내부 설계를 기록하는 과정으로, 향후 유지보수 및 개선에 필수적이지만 종종 간과되기도 한다. 외부 인터페이스에 대한 문서화는 특히 중요하다. (자세한 내용은 아래 하위 섹션 참조)

;트레이닝 및 지원

: 최종 사용자에 대한 교육과 지원은 소프트웨어 성공에 중요한 요소이다. 사용자들은 새로운 환경에 저항감을 느낄 수 있으므로, 배포 단계에서 교육을 제공하고 사용 중 발생하는 문제나 질문에 대응하는 것이 중요하다. 이러한 피드백은 다음 개발의 중요한 입력이 된다.

;유지보수

: 소프트웨어 배포 후 발생하는 오류를 수정하고 기능을 개선하는 과정이다. 초기 개발보다 더 많은 시간과 노력이 필요할 수 있으며, 단순히 버그 수정뿐만 아니라 새로운 기능을 추가하는 작업이 대부분을 차지한다. (자세한 내용은 아래 하위 섹션 참조)

이러한 개발 과정을 관리하는 프로세스를 관리 프로세스라고 하며, 개발 프로세스 자체에도 관리 요소가 포함된다.

소프트웨어를 완성해나가는 전체 과정을 다루는 모델을 개발 공정 모델이라고 한다. 폭포수 모델, 반복적 개발, 애자일 소프트웨어 개발 등 다양한 모델이 존재하며, 각 모델은 고유한 특징을 가지고 있다. 실제 개발에서는 프로젝트의 특성에 맞는 모델을 포함한 소프트웨어 개발 방법론을 선택하는 것이 중요하다. (각 모델에 대한 자세한 내용은 관련 하위 섹션들에서 다룬다.)

4. 1. 요구사항 분석

요구사항 분석은 소프트웨어 개발 프로세스의 초기 단계 중 하나로, 고객이나 사용자가 소프트웨어로부터 무엇을 원하는지를 파악하고 분석하여 구체적인 소프트웨어 명세를 작성하는 과정이다. 이 단계에서 도출된 요구사항은 이후 설계, 구현, 테스트 단계의 기준이 되므로 매우 중요하다.

전통적인 폭포수 모델에서는 개발 초기 단계에서 요구 사항을 명확히 정의하고 문서화하는 것을 강조한다. 이 모델에서는 각 개발 단계가 순차적으로 진행되므로, 요구사항 분석 단계에서 오류가 발생하거나 요구사항이 변경될 경우 후반 단계에 큰 영향을 미치게 된다. 따라서 초기 요구 분석과 요구 사항 관리의 정확성이 프로젝트 성공에 결정적인 역할을 한다. 요구 분석 과정에서의 기술적 미숙함이나 고객과의 소통 부족은 종종 프로젝트 실패의 원인이 되기도 한다.

반면, 반복적 개발이나 애자일 소프트웨어 개발과 같은 현대적인 개발 방법론에서는 초기 단계에서 모든 요구사항을 완벽하게 정의하기보다는, 핵심 요구사항을 바탕으로 개발을 시작하고 지속적인 피드백을 통해 요구사항을 점진적으로 구체화하고 변경에 유연하게 대응한다. 이는 소프트웨어에 대한 고객의 요구가 불명확하거나 개발 과정 중 변경될 가능성이 높은 경우에 유용하다. 하지만 이러한 접근 방식은 고객의 적극적인 참여와 개발팀과의 긴밀한 의사소통을 전제로 하며, 그렇지 않으면 오히려 개발 방향이 모호해지거나 비용이 증가할 수 있다는 비판도 있다.[19]

한국의 공공 소프트웨어 사업에서는 제안요청서(RFP)를 기반으로 요구사항 분석이 진행되는 경우가 많다. 그러나 발주처의 잦은 요구사항 변경이나 초기에 제시된 요구사항의 모호성으로 인해 개발 과정에서 혼란이 발생하고, 이는 결과적으로 소프트웨어 품질 저하나 납기 지연 등의 문제로 이어지기도 한다. 이러한 고질적인 문제를 해결하기 위해 더불어민주당을 비롯한 정치권과 업계에서는 소프트웨어 개발 대가 산정 기준의 현실화, 표준계약서 도입 등을 통해 공정한 계약 문화를 정착시키고 불합리한 요구사항 변경을 방지하려는 노력을 지속하고 있다.

결론적으로 어떤 개발 방법론을 선택하든, 고객의 요구사항을 정확하게 이해하고 이를 효과적으로 관리하는 것은 성공적인 소프트웨어 개발을 위한 핵심적인 활동이다. 이를 위해서는 개발 초기 단계부터 고객과 개발자 간의 명확하고 지속적인 의사소통이 필수적이다.

4. 2. 구현

구현 단계에서는 설계를 바탕으로 실제 코드를 작성하게 되는데, 다양한 개발 방법론이 이 과정에 적용될 수 있다.

반복적 개발은 소프트웨어를 점진적으로 만들어나가면서 문제점이나 잘못된 가정을 초기에 발견하여 큰 문제로 번지는 것을 막는 기법이다. 특히 상용 소프트웨어 개발에서 선호되는데, 이는 고객이 소프트웨어에 무엇을 원하는지 명확히 정의하지 못하는 상황에서도 개발을 진행할 수 있게 해주기 때문이다. 반복적 개발은 비용 및 품질 면에서 장기적으로 유리한 전략을 취하며, 사전에 모든 것을 완벽하게 계획할 필요가 없다는 장점이 있다.[19] 하지만 고객이 개발 과정에 깊이 관여해야 하고, 때로는 개발자 수준의 기술과 경험이 요구된다는 비판도 있다. 고객의 참여가 부족하면 비용이 증가할 수 있다는 지적이다. 그러나 반복적 개발 지지자들은 피드백을 얻기 위해 전체 시스템을 완성할 필요는 없으며, 기존 방식의 요구 분석과 평가 단계를 개발 전 과정에 분산시킨 것으로 보아야 한다고 반박한다.

애자일 소프트웨어 개발은 반복적 개발에서 파생된 방법론으로, 더 가볍고 인간 중심적인 접근을 강조한다. 애자일은 엄격한 계획보다는 피드백을 더 중요하게 여기며, 주로 테스트(평가)와 개발 중인 소프트웨어의 잦은 릴리스를 통해 피드백을 얻는다. 애자일은 기존 방법론보다 적은 노력으로 더 많은 기능을 개발하고 높은 품질의 소프트웨어를 만들 수 있어 효율적이라고 평가받는다. 하지만 장기적인 계획 수립이 어렵다는 단점도 있다. 필요한 기능은 개발되지만, 정확히 언제 완료될지 예측하기 어렵기 때문이다. 또한, 요구 사양이 고정되지 않고 계속 변할 수 있다는 점은 기존의 개발 방식과는 다른 특징이며, 만약 새로운 요구 사항이 큰 아키텍처 변경을 필요로 하고 고객이 추가 비용을 지불하지 않으면 프로젝트가 중단될 수도 있다.

익스트림 프로그래밍 (XP)은 잘 알려진 애자일 기법 중 하나이다. XP는 개발 과정을 매우 짧은 단계(보통 1일에서 1주일)로 나눈다. 각 단계는 자동화된 테스트 작성으로 시작하여 목표를 설정하고, 두 명의 프로그래머가 함께 코딩(페어 프로그래밍)을 진행한다. 모든 테스트를 통과하면 해당 단계가 완료된다. 설계와 아키텍처는 코딩 이후 리팩토링을 통해 점진적으로 만들어지며, 설계 작업은 코드를 작성하는 개발자가 직접 수행한다. 불완전하지만 작동하는 시스템을 사용자에게 배포하고 평가받은 후[19], 다음으로 중요하다고 판단되는 기능에 대한 테스트를 작성하며 다음 개발 주기를 시작한다.

리팩토링은 애자일 커뮤니티에서 제안한 기법으로, 코드를 작성한 후에 내부 구조를 개선하는 작업을 의미한다. 이는 사전에 상세한 설계를 하고 문서를 만드는 방식의 대안으로 여겨지기도 한다. 하지만 리팩토링은 기존 코드 수정에 따른 비용 증가(약 10~15%로 추정되나, 재평가나 회귀 테스트 포함 여부는 불분명)를 유발할 수 있으며, 근본적인 아키텍처 문제를 해결하기 위한 리엔지니어링의 대안은 되지 못한다는 지적도 있다.

테스트 주도 개발 (TDD) 역시 애자일에서 파생된 기법이다. TDD는 실제 코드를 작성하기 전에 해당 코드의 기능을 검증하는 단위 테스트 코드를 먼저 작성하는 방식이다. 이를 위해서는 어떤 코드를 작성할지 미리 상세하게 결정해야 한다. 애자일 개발은 보통 간단한 설계에서 시작하여 점진적으로 발전시키므로, TDD를 엄격하게 적용하는 것이 항상 애자일 철학에 부합하는지는 논의의 여지가 있다.

이러한 현대적인 개발 기법들은 웹 기반 기술의 발전과 밀접한 관련이 있다. 특히 미들웨어와 같이 강력한 기술 기반 위에서 개발이 이루어질 경우, 많은 기능이 이미 구현되어 있어 개발 과정이 실제로는 유지보수와 유사해질 수도 있다.

4. 3. 소프트웨어 테스트

소프트웨어 테스트는 개발된 소프트웨어의 품질을 확인하고 오류를 찾아내는 중요한 과정이다. 특히 현대적인 소프트웨어 개발 방법론에서는 테스트의 역할이 더욱 강조된다.

애자일 소프트웨어 개발에서는 계획을 세우는 것보다 실제 작동하는 소프트웨어를 통해 얻는 피드백을 중요하게 생각한다. 이러한 피드백은 주로 테스트(평가)와 개발 중인 소프트웨어를 사용자나 고객에게 미리 공개(릴리스)함으로써 얻어진다.

익스트림 프로그래밍(XP)은 애자일 방법론 중 하나로, 개발 단계를 매우 짧게 나누어 진행한다. 각 단계가 시작될 때, 목표 기능을 검증하기 위한 자동화된 테스트 코드를 먼저 작성한다. 그 후 실제 코드를 작성하고, 미리 만들어 둔 모든 테스트를 통과해야만 해당 단계가 완료된 것으로 간주한다. 이는 테스트가 코드 작성의 일부이자 품질 보증의 핵심 수단임을 보여준다.

테스트 주도 개발(TDD) 역시 애자일 기법에서 파생된 개발 방식이다. TDD의 가장 큰 특징은 실제 기능을 구현하는 코드를 작성하기 전에, 해당 기능이 정상적으로 동작하는지 검증하는 단위 테스트 코드를 먼저 작성한다는 점이다. 즉, 어떤 코드를 만들지 구체적으로 결정하고, 그 코드가 통과해야 할 테스트를 먼저 정의한 뒤에 실제 코딩을 진행한다. 이는 개발 초기부터 코드의 명세와 품질을 명확히 하도록 유도한다. 다만, 애자일 개발의 특징인 간단한 설계에서 시작하는 방식과 달리, TDD를 적용하려면 초기에 테스트를 작성할 수 있을 정도로 상세한 설계가 필요하다는 점에서 애자일 철학과 완전히 일치하지 않을 수도 있다는 시각도 존재한다.

4. 4. 소프트웨어 문서화

전통적인 소프트웨어 개발 방식에서는 상세한 계획 수립과 이를 기반으로 한 문서화가 중요하게 여겨졌으나, 반복적 개발이나 애자일 소프트웨어 개발과 같은 현대적인 방법론에서는 다른 접근 방식을 취한다. 이들 방법론은 엄격한 사전 문서화보다는 실제 작동하는 소프트웨어를 통해 얻는 피드백과 지속적인 개선을 더 강조하는 경향이 있다.[19]

특히 애자일 소프트웨어 개발의 한 형태인 익스트림 프로그래밍 (XP)에서는 설계와 아키텍처가 코딩 과정 중에 리팩토링을 통해 점진적으로 만들어지고 완성된다. 애자일 커뮤니티는 이러한 리팩토링을, 개발 초기에 신중하게 설계를 수행하고 이를 문서화하는 전통적인 방식의 대안으로 제시하기도 한다. 즉, 상세한 설계 문서 대신 코드를 통해 설계를 구체화하고 개선해 나가는 방식이다.

하지만 이러한 접근 방식은 장기적인 계획 수립의 어려움이나, 아키텍처상의 문제가 발생했을 때 이를 수정하기 위한 리엔지니어링 비용이 클 수 있다는 비판도 존재한다. 또한, 테스트 주도 개발 (TDD)처럼 코드를 작성하기 전에 해당 코드에 대한 단위 테스트를 먼저 작성해야 하는데, 이는 테스트를 작성할 수 있을 정도로 상세한 수준의 사전 결정(일종의 명세)을 요구한다. 따라서 애자일 방법론에서도 문서화나 사전 설계의 중요성이 완전히 배제되는 것은 아니며, 그 형태와 시점이 달라졌다고 볼 수 있다.

4. 5. 배포 및 유지보수

소프트웨어 개발의 마지막 단계는 완성된 소프트웨어를 사용자에게 전달하는 배포와, 배포 이후 소프트웨어를 지속적으로 관리하는 유지보수이다.

배포는 개발된 소프트웨어를 실제 사용 환경에 설치하고 사용자들이 이용할 수 있도록 하는 과정이다. 폭포수 모델과 같은 전통적인 개발 방식에서는 요구사항 분석, 설계, 구현, 테스트 등 모든 개발 단계가 순서대로 완료된 후 마지막 단계로서 배포가 이루어진다. 배포 후에는 유지보수 단계로 넘어가 소프트웨어를 관리하게 된다.

반면, 반복적 개발이나 애자일 소프트웨어 개발 방식에서는 개발 과정 중에 여러 번에 걸쳐 소프트웨어의 기능 일부 또는 전체를 릴리스(배포)하는 경우가 많다. 예를 들어, 익스트림 프로그래밍(XP)에서는 아직 모든 기능이 완성되지 않았더라도 작동하는 버전을 사용자에게 먼저 배포하여 피드백을 받고, 이를 다음 개발 과정에 반영한다.[19] 이러한 반복적인 배포 방식은 사용자의 요구 변화에 보다 유연하게 대응하고, 개발 초기에 문제점을 발견하여 수정할 기회를 제공한다는 장점이 있다.

유지보수는 배포된 소프트웨어에서 발생하는 오류를 수정하거나, 새로운 기능을 추가하고 성능을 향상시키는 등 소프트웨어의 가치를 지속적으로 유지하고 발전시키는 활동을 포함한다. 또한, 운영체제 업데이트나 새로운 하드웨어 환경 등 외부 환경 변화에 맞춰 소프트웨어를 수정하는 작업도 유지보수의 중요한 부분이다. 특히 애자일 소프트웨어 개발처럼 지속적인 개선과 사용자 피드백 반영을 중요하게 여기는 방식에서는, 개발 과정 자체가 끊임없는 유지보수 활동과 유사한 성격을 띠기도 한다.

5. 프로세스 메타 모델

일부 "프로세스 모델"은 조직에서 채택한 특정 프로세스를 평가, 비교 및 개선하기 위한 추상적인 설명이다.


  • ISO/IEC 12207은 소프트웨어의 라이프 사이클을 선택, 구현 및 모니터링하는 방법을 설명하는 국제 표준이다.
  • 능력 성숙도 모델 통합 (CMMI)은 모범 사례를 기반으로 하는 주요 모델 중 하나이다. 독립적인 평가는 조직이 정의된 프로세스를 얼마나 잘 따르는지에 따라 등급을 매기며, 이는 해당 프로세스나 생성된 소프트웨어의 품질 자체를 보증하는 것은 아니다. CMMI는 CMM을 대체했다.
  • ISO 9000은 제품을 제조하기 위한 공식적으로 조직된 프로세스와 진행 상황을 관리하고 모니터링하는 방법을 설명하는 표준이다. 이 표준은 원래 제조 부문을 위해 만들어졌지만, 소프트웨어 개발에도 적용되었다. CMMI와 마찬가지로 ISO 9000 인증은 최종 결과의 품질을 보장하지 않으며, 공식화된 비즈니스 프로세스가 준수되었음을 보장할 뿐이다.
  • ISO/IEC 15504 ''정보 기술—프로세스 평가''는 소프트웨어 프로세스 개선 능력 결정(SPICE)으로도 알려져 있으며, "소프트웨어 프로세스 평가를 위한 프레임워크"이다. 이 표준은 프로세스 비교를 위한 명확한 모델 설정을 목표로 한다. SPICE는 CMMI와 매우 유사하게 사용되며, 소프트웨어 개발을 관리, 제어, 안내 및 모니터링하기 위한 프로세스를 모델링한다. 이 모델은 개발 조직이나 프로젝트 팀이 실제로 수행하는 작업을 측정하는 데 사용되며, 이 정보를 분석하여 약점을 식별하고 개선을 추진한다. 또한 강점을 식별하여 조직의 일반적인 관행으로 통합될 수 있도록 한다.
  • ISO/IEC 24744 ''소프트웨어 엔지니어링—개발 방법론을 위한 메타모델''은 소프트웨어 개발 방법론을 위한 파워 타입 기반 메타모델이다.
  • 소프트 시스템 방법론은 관리 프로세스를 개선하기 위한 일반적인 방법이다.
  • 방법 공학은 정보 시스템 프로세스를 개선하기 위한 일반적인 방법이다.

6. 산출 문서


  • 소프트웨어 개발 계획서 (SDP)
  • 소프트웨어 요구 사양서 (SRS)
  • 소프트웨어 인터페이스 명세서 (IDD)
  • 소프트웨어 설계 명세서 (SDD)
  • 소프트웨어 시험 명세서 (STD)
  • 소프트웨어 시험 결과서 (STR)
  • 소프트웨어 버전 명세서 (VDD)
  • 소프트웨어 산출물 사양서 (SPS)

7. 개발 방법론의 실제 적용



소프트웨어 개발에는 다양한 방법론 프레임워크가 존재하며, 각 프로젝트의 기술적, 조직적, 팀 특성 등 여러 요소를 고려하여 가장 적합한 것을 선택하는 것이 중요하다.[14] 과거 전통적인 개발 방식 중 하나로 폭포수 모델이 널리 알려져 있다.

폭포수 모델은 개발 과정을 순차적인 단계로 나누어 진행하는 방식이다. 마치 폭포수가 아래로 떨어지듯 이전 단계가 완료되어야 다음 단계로 넘어가는 특징을 가진다. 일반적인 단계는 다음과 같다.


  • 요구 사항 분석 및 소프트웨어 요구 사항 명세서 작성
  • 소프트웨어 설계
  • 구현
  • 테스팅
  • 통합 (여러 하위 시스템이 있는 경우)
  • 배포 또는 설치
  • 유지 보수


이 모델에 대한 최초의 공식 설명은 1970년 윈스턴 W. 로이스의 논문에서 언급되었지만[6], 정작 로이스 자신은 이 모델을 결함이 있는 예시로 제시했다.[7] 폭포수 모델의 기본 원칙은 프로젝트를 순차적 단계로 나누고, 계획, 일정, 예산 등을 사전에 확정하여 전체 시스템을 한 번에 구현하는 데 중점을 두는 것이다.[14] 각 단계마다 철저한 문서화와 검토, 승인 과정을 거쳐 엄격하게 통제된다.

그러나 폭포수 모델은 한 번 완료된 단계를 다시 수정하기 어려운 경직성 때문에 비판을 받기도 한다. 이러한 유연성 부족은 변화하는 요구사항에 민첩하게 대응하기 어렵게 만들며, 특히 사전 대규모 설계 방식은 예산 초과나 개발 기간 지연, 최종 결과물이 사용자의 요구를 충족하지 못하는 문제로 이어지기도 했다. 이 때문에 과거 일부 대규모 정부 프로젝트 등에서 문제점을 드러내기도 하였다. 현재는 계약상 요구되는 특별한 경우를 제외하고는, 소프트웨어 개발 환경의 변화에 맞춰 등장한 더 유연하고 다재다능한 애자일 방법론 등 다양한 방법론들이 프로젝트 특성에 맞게 활용되고 있다. 폭포수 모델의 비판 참조. 결국, 어떤 단일한 방법론이 모든 상황에 최적인 것은 아니며, 프로젝트의 성격과 목표, 팀의 역량 등을 종합적으로 고려하여 가장 효과적인 개발 방법론을 선택하고 적용하는 것이 중요하다.[14]

참조

[1] 서적 Global Business Information Technology: an integrated systems approach Pearson Education 2004
[2] 학술지 Software Process versus Design Quality: Tug of War?
[3] 서적 Continuous Integration: Improving Software Quality and Reducing Risk Addison-Wesley Professional 2007
[4] 서적 Object Oriented Design: With Applications https://books.google[...] Benjamin Cummings 2014-08-18
[5] 서적 Systems Analysis and Design Methods 2003
[6] 웹사이트 Wasserfallmodell > Entstehungskontext http://cartoon.iguw.[...] 2007-11-28
[7] 웹사이트 Waterfall methodology: there's no such thing! http://www.idinews.c[...]
[8] 학술지 A Spiral Model of Software Development and Enhancement http://doi.acm.org/1[...] Association for Computing Machinery 1986-08
[9] 서적 Tutorial: software engineering project management Computer Society Press of the IEEE 1986
[10] 서적 Software cost estimation with Cocomo II: Volume 1 2000
[11] 웹사이트 Foreword by Jason Fried {{!}} Shape Up https://basecamp.com[...] 2022-09-11
[12] 웹사이트 Is Shape Up just a nice theory? https://www.curiousl[...] 2022-09-12
[13] 학술지 Modeling Test Cases in BPMN for Behavior-Driven Development
[14] 웹사이트 Selecting a development approach http://www.cms.gov/R[...] United States Department of Health and Human Services (HHS) 2008-10-27
[15] 문서
[16] 문서
[17] 문서
[18] 문서
[19] 문서
[20] 문서


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com