소프트웨어 개발 방법론

소프트웨어 개발 방법론

많이 사용되고 있는 4가지 패러다임

• 폭포수 모델
• 원형 패러다임
• 나선형 모델
• 4세대 기법

패러다임의 선정은 프로젝트의 성격, 소요되는 기간, 방법과 도구 등에 의해 이루어진다.

 

폭포수 모델

특징

• 고전적 라이프 사이클 패러다임
• 가장 오래되고 널리 사용되는 패러다임
• 순차적인 접근방법
• 하향식 접근방법

장점

• 프로젝트 진행 과정을 세분화하여 관리 용이

단점

• 대규모일수록 부분 순환이 발생하기 때문에 순차적인 흐름을 따라가는 데 어려움이 있다.
• 요구사항을 초기에 구체적으로 기술하기 어렵다.
• 결과가 후반부에 가서야 얻어짐으로써, 중요한 문제점이 뒤에 발견된다.

 

원형 (Prototyping) 패러다임

적용 환경

• 목표를 정하였으나, 속성을 어떻게 만족시킬지 모르는 경우
• 사용자의 요구사항이 무엇인지, 요구가 어떻게 변경될지 구체적으로 모르는 경우
• 개발자들이 고객의 요구를 불완전하게 이해하고 있는 경우
• 고품질 시스템의 요구사항을 명세화하기 어려울 경우

장점

• 개발 초기에 미리 결과물을 확인할 수 있다는 점에서 사용자의 이해를 도운다.
• 개발의 초기 단계에서 수정 / 보완할 사항을 미리 파악할 수 있다.
• 분석 및 설계 과정에 사용자가 동참하여 즉각적인 피드백을 줄 수 있다.

단점

• 일회적 프로젝트나 대규모 프로젝트의 개발에는 적용하기 쉽지 않다.
• 불완전한 요구사항을 바탕으로 시제품을 만들기 때문에 결과적으로 불완전한 시스템을 산출하여 수정과 보완에 많은 인력과 시간이 투입된다.

완료된 프로토타입을 이용하여 시스템을 구현하였으나 원하는 시스템이 아닐 경우, 재작업 실시

 

나선형 패러다임

• 폭포수 모델과 원형 패러다임의 장점에 새로운 요소인 위험 분석을 추가하여 만든 것(높은 위험도가 예상될 경우)

• 위험을 관리하고 최소화하려는 것이 이 패러다임의 주 목적

• 나선을 돌면서 점진적으로 완벽한 시스템 개발

• 각 나선은 4단계로 나뉘어져 있다.
  • 계획 및 정의 단계
  • 위험 분석 단계
  • 개발 단계
  • 고객 평가 단계

장점

• 비용이 많이 들고, 시간이 오래 걸리는 대형 시스템 구축(대형 사업)에 가장 현실적인 접근방법과 성과를 보면서 위험부담을 줄일 수 있는 방법

단점

• 모델 자체가 복잡하여 프로젝트 관리가 어려움.
• 상업용 제품에는 이 방법보다는 프로토타입이 적합

 

4세대 기법

• 요구사항 명세서로부터 실행 코드를 자동으로 생성할 수 있게 해주는 방법
• 현재 4GT 도구들은 자연 언어를 실행 코드로 바꾸어 줄 만큼 정교하지 못하다.
• 형식 규격 언어로 표현하려는 노력(예 : EER(Enhanced Entity-Relationship) 모델로 만들어진 명세서에서 데이터베이스의 코드가 생성)

 

애자일(Agile) 방법론

• 기존 방법론은 프로젝트의 본질적인 목표보다 계획 수립, 문서화, 품질 관리 등 부수적으로 수행되는 작업이 오버헤드(Overhead) 비용을 발생시킨다.
• 1990년대 민첩성과 실용성을 앞세운 가벼운 경량급 개발 방법론인 애자일 기법을 제안

 

특징

• 기술적 부채 해결
• 리팩토링 활용
• 객체지향 기법의 적용

장점

• 빠른 프로토타입과 짧은 릴리즈 → 소프트웨어 개발 성공률을 높일 수 있다.
• 작은 프로젝트부터 쉽게 도입 → 비용과 위험도도 상대적으로 낮다.

단점

• 성공 사례가 많지 않다 → 개발자와 고객이 함께 협업
  • 사용자 스토리를 작성
  • 테스트 케이스를 작성
  • 자원을 추정
  • 릴리즈 계획의 수립
• 참여와 소통, 개인의 성숙도, 상호 협력이 중요
• 개발 프로세스 및 소프트웨어 공학에 관한 수준 높은 기술이 필요

 

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

• XP는 애자일 소프트웨어 개발 방법론 중 가장 많이 알려진 방법이다.
• XP는 의사소통, 단순함, 피드백, 용기, 존중 등 5가지의 가치에 시초
• XP는 개발 속도를 높이는 가속 기술이며, 그 중심은 단순한 디자인 정신, 테스트 우선 프로그래밍, 리팩토링이라 할 수 있다.

 

사용자 스토리 (User Stroty)

사용자 스토리는 고객이 원하는 기능을 짧게 표현해 놓은 것

• 고객과 직접 상의하고 작성한다.
• 간략한 설명이나 키워드를 포함하는 짧은 문장
• 스토리 작성은 다음을 가정한다.
  1. 요구사항은 변할 수 있다.
  2. 요구사항을 정확히 알지 못할 수가 있다.
• 사용자와 개발자가 지속적으로 대화

좋은 사용자 스토리

1. 독립적이다.
2. 협상 가능하다.
3. 사용자와 고객에게 가치가 있다.
4. 추정 가능하다.
5. 작다.
6. 테스트 가능해야 한다.