소프트웨어 개발 방법론
많이 사용되고 있는 4가지 패러다임
- 폭포수 모델
- 원형 패러다임
- 나선형 모델
- 4세대 기법
패러다임의 선정은 프로젝트의 성격, 소요되는 기간, 방법과 도구 등에 의해 이루어진다.
폭포수 모델

특징
- 고전적 라이프 사이클 패러다임
- 가장 오래되고 널리 사용되는 패러다임
- 순차적인 접근방법
- 하향식 접근방법
장점
- 프로젝트 진행 과정을 세분화하여 관리 용이
단점
- 대규모일수록 부분 순환이 발생하기 때문에 순차적인 흐름을 따라가는 데 어려움이 있다.
- 요구사항을 초기에 구체적으로 기술하기 어렵다.
- 결과가 후반부에 가서야 얻어짐으로써, 중요한 문제점이 뒤에 발견된다.
원형 (Prototyping) 패러다임
적용 환경
- 목표를 정하였으나, 속성을 어떻게 만족시킬지 모르는 경우
- 사용자의 요구사항이 무엇인지, 요구가 어떻게 변경될지 구체적으로 모르는 경우
- 개발자들이 고객의 요구를 불완전하게 이해하고 있는 경우
- 고품질 시스템의 요구사항을 명세화하기 어려울 경우

장점
- 개발 초기에 미리 결과물을 확인할 수 있다는 점에서 사용자의 이해를 도운다.
- 개발의 초기 단계에서 수정 / 보완할 사항을 미리 파악할 수 있다.
- 분석 및 설계 과정에 사용자가 동참하여 즉각적인 피드백을 줄 수 있다.
단점
- 일회적 프로젝트나 대규모 프로젝트의 개발에는 적용하기 쉽지 않다.
- 불완전한 요구사항을 바탕으로 시제품을 만들기 때문에 결과적으로 불완전한 시스템을 산출하여 수정과 보완에 많은 인력과 시간이 투입된다.
완료된 프로토타입을 이용하여 시스템을 구현하였으나 원하는 시스템이 아닐 경우, 재작업 실시
나선형 패러다임
폭포수 모델과 원형 패러다임의 장점에 새로운 요소인 위험 분석을 추가하여 만든 것(높은 위험도가 예상될 경우)
위험을 관리하고 최소화하려는 것이 이 패러다임의 주 목적
나선을 돌면서 점진적으로 완벽한 시스템 개발
각 나선은 4단계로 나뉘어져 있다.
- 계획 및 정의 단계
- 위험 분석 단계
- 개발 단계
- 고객 평가 단계

장점
- 비용이 많이 들고, 시간이 오래 걸리는 대형 시스템 구축(대형 사업)에 가장 현실적인 접근방법과 성과를 보면서 위험부담을 줄일 수 있는 방법
단점
- 모델 자체가 복잡하여 프로젝트 관리가 어려움.
- 상업용 제품에는 이 방법보다는 프로토타입이 적합
4세대 기법
요구사항 명세서로부터 실행 코드를 자동으로 생성할 수 있게 해주는 방법
현재 4GT 도구들은 자연 언어를 실행 코드로 바꾸어 줄 만큼 정교하지 못하다.
형식 규격 언어로 표현하려는 노력(예 : EER(Enhanced Entity-Relationship) 모델로 만들어진 명세서에서 데이터베이스의 코드가 생성)
애자일(Agile) 방법론
기존 방법론은 프로젝트의 본질적인 목표보다 계획 수립, 문서화, 품질 관리 등 부수적으로 수행되는 작업이 오버헤드(Overhead) 비용을 발생시킨다.
1990년대 민첩성과 실용성을 앞세운 가벼운 경량급 개발 방법론인 애자일 기법을 제안
특징
- 기술적 부채 해결
- 리팩토링 활용
- 객체지향 기법의 적용
장점
- 빠른 프로토타입과 짧은 릴리즈 → 소프트웨어 개발 성공률을 높일 수 있다.
- 작은 프로젝트부터 쉽게 도입 → 비용과 위험도도 상대적으로 낮다.
단점
- 성공 사례가 많지 않다 → 개발자와 고객이 함께 협업
- 사용자 스토리를 작성
- 테스트 케이스를 작성
- 자원을 추정
- 릴리즈 계획의 수립
- 참여와 소통, 개인의 성숙도, 상호 협력이 중요
- 개발 프로세스 및 소프트웨어 공학에 관한 수준 높은 기술이 필요
익스트림 프로그래밍(XP)
XP는 애자일 소프트웨어 개발 방법론 중 가장 많이 알려진 방법이다.
XP는 의사소통, 단순함, 피드백, 용기, 존중 등 5가지의 가치에 시초
XP는 개발 속도를 높이는 가속 기술이며, 그 중심은 단순한 디자인 정신, 테스트 우선 프로그래밍, 리팩토링이라 할 수 있다.
사용자 스토리 (User Stroty)
사용자 스토리는 고객이 원하는 기능을 짧게 표현해 놓은 것
- 고객과 직접 상의하고 작성한다.
- 간략한 설명이나 키워드를 포함하는 짧은 문장
- 스토리 작성은 다음을 가정한다.
- 요구사항은 변할 수 있다.
- 요구사항을 정확히 알지 못할 수가 있다.
- 사용자와 개발자가 지속적으로 대화


좋은 사용자 스토리
- 독립적이다.
- 협상 가능하다.
- 사용자와 고객에게 가치가 있다.
- 추정 가능하다.
- 작다.
- 테스트 가능해야 한다.
'Computer Science > 소프트웨어 모델링' 카테고리의 다른 글
애자일(Agile) 소프트웨어 개발 방법론 (0) | 2021.01.25 |
---|