소프트웨어 개발 방법론
◆ 많이 사용되고 있는 4가지 패러다임
폭포수 모델 , 원형 패러다임 , 나선형 모델 , 4세대 기법
◆ 패러다임의 선정은 프로젝트의 성격, 소요되는 기간, 방법과 도구 등에 의해 이루어 진다.
1 . 폭포수 모델
특징
· 고전적 라이프 사이클 패러다임
· 가장 오래되고 널리 사용되는 패러다임
· 순차적인 접근방법
· 하향식 접근방법
장점
· 프로젝트 진행과정을 세분화하여 관리 용이
단점
· 대규모일 수록 부분 순환이 발생하기 때문에 순차적인 흐름을 따라가는 데 어려움이 있다.
· 요구사항을 초기에 구체적으로 기술하기 어렵다.
· 결과가 후반부에 가서야 얻어짐으로써, 중요한 문제점이 뒤에 발견된다.
2. 원형 (Prototyping) 패러다임
적용 환경
· 목표를 정하였으나 속성을 어떻게 만족시킬지 모르는 경우
· 사용자의 요구사항이 무엇인지, 요구를 어떻게 변경될지 구체적으로 모르는 경우
· 개발자들이 고객의 요구를 불완전하게 이해하고 있는 경우
· 고품질 시스템의 요구사항을 명세화하기 어려울 경우
◆ 프로토타입 개발
· 장점
- 개발 초기에 미리 결과물을 확인할 수 있다는 점에서 사용자의 이해를 도운다.
- 개발의 초기 단계에서 수정 / 보완할 사항을 미리 파악할 수 있다.
- 분석 및 설계 과정에 사용자가 동참하여 즉각적인 피드백을 줄 수 있다.
· 단점
- 일회적 프로젝트나 대규모 프로젝트의 개발에는 적용하기 쉽지 않다.
- 불완전한 요구사항을 바탕으로 시제품이 만들기 때문에 결과적으로 불완전한 시스템을 산출하여 수정과 보 완 에 많은 인력과 시간이 투입된다.
완료된 프로토타입을 이용하여 시스템을 구현하였으나 원하는 시스템이 아닐 경우
재 작업 실시
3. 나선형 패러다임
◆ 폭포수 모델과 원형 패러다임의 장점에 새로운 요소인 위험 분석을 추가하여 만든 것 (높은 위험도가 예상될 경우)
◆ 위험을 관리하고 최소화하려는 것이 이 패러다임의 주 목적
◆ 나선을 돌면서 점진적으로 완벽한 시스템 개발
◆ 각 나선은 4단계로 나뉘어져 있다.
1) 계획 및 정의 단계
2) 위험 분석 단계
3) 개발 단계
4) 고객 평가 단계
◆ 나선형 패러다임
· 장점
- 비용이 많이 들고 시간이 오래 걸리는 대형 시스템구축(대형사업)에 가장 현실적인 접근방법 성과를 보면서 위험부담을 줄일 수 있는 방법
· 단점
- 모델자체가 복잡하여 프로젝트 관리가 어려움 , 상업용 제품에는 이방법보단 프로토타입이 적합
4. 4세대 기법
◆ 요구사항 명세서로부터 실행코드를 자동으로 생성할 수 있게 하여주는 방법
◆ 현재 4GT 도구들은 자연언어를 실행코드로 바꾸어 줄 만큼 정교하지 못하다.
◆ 형식 규격 언어로 표현하려는 노력 ( 예 : EER(Enhanced Entity-Realtionship) 모델로 만들어진 명세서에서 데이터베이스의 코드가 생성)
5. 애자일(Agile) 방법론
◆ 기존 방법론은 프로젝트의 본질적인 목표보다 계획 수립, 문서화, 품질 관리등 부수적으로 수행되는 작업이 오버헤드(overhead) 비용을 발생시킨다.
◆ 1990년대 민첩성과 실용성을 앞세운 가벼운 경량급 개발 방법론인 애자일 기법을 제안
◆ 특징
· 기술적 부채 해결
· 리팩토링 활용
· 객체지향 기법의 적용
◆ 애자일 기법
· 장점
- 빠른 프로토타입과 짧은 릴리즈 → 소프트웨어 개발 성공률을 높일 수가 있다.
- 작은 프로젝트부터 쉽게 도입 → 비용과 위험도도 상대적으로 낮다
· 단점
- 성공 사례가 많지 않다 → 개발자와 고객이 함께 협업
사용자 스토리를 작성
테스트케이스를 작성
자원을 추정
릴리즈 계획의 수립
- 참여와 소통, 개인의 성숙도, 상호협력이 중요
- 개발 프로세스 및 소프트웨어 공학에 관한 수준 높은 기술이 필요
6. 익스트림 프로그래밍(XP)
◆ XP는 애자일 소프트웨어 개발 방법론 중 가장 많이 알려진 방법이다.
◆ XP는 의사소통, 단순함, 피드백, 용기, 존중 등 5가지의 가치에 시초
◆ XP는 개발 속도를 높이는 가속 기술이며, 그 중심은 단순한 디자인 정신, 테스트 우선프로그래밍, 리팩토링이라 할 수 있다.
※ 사용자 스토리 (user story)
◆ 사용자 스토리는 고객이 원하는 기능을 짧게 표현해 놓은 것
- 고객과 직접 상의하고 작성한다.
- 간략한 설명이나 키워드를 포함하는 짧은 문장
- 스토리 작성은 다음을 가정한다
1. 요구사항은 변할 수 있다.
2. 요구사항을 정확히 알지 못할 수가 있다.
- 사용자와 개발자가 지속적으로 대화
◆ 좋은 사용자 스토리
1. 독립적이다.
2. 협상 가능하다.
3. 사용자와 고객에게 가치가 있다.
4. 추정 가능하다.
5. 작다.
6. 테스트 가능해야 한다.