소프트웨어 개발 모델
소프트웨어 개발 모델
소프트웨어 자체를 하나의 생명체로 간주하고 그것의 탄생부터 사망까지의 변화과정이다.
정보 시스템을 개발하는 절차, 개발 단계의 반복현상을 시스템 개발주기(SDLC ; System Development Life Cycle) 이라 한다
SDLC는 개발의 시작과 끝을 중요시 한다
소프트웨어 개발 위주가 아닌 사용자의 요구를 전략적으로 계획하기 위한 준비 단계와 사용자가 시스템을 사용하고 실효적인 이익을 얻을 수 있는 운영 단계를 중시한다
역할
프로젝트 비용 산정과 개발계획을 수립할 수 있는 기본골격이다
일정계획, 예산, 개발 요원 자원들을 산정, 분배하는데 좋은 도구가 된다
소프트웨어 개발의 각 단계를 뚜렷하게 구분할 수 있어, 개발 진행 상황을 명확히 파악할 수 있다
개발의 지연이나 예산초과 사태 역시 계획과 실정을 비교하면 쉽게 인지 가능하다.
문서화가 충실한 프로젝트 관리를 가능하게 해 주어, 각종 문서를 언제까지 작성해야 하고 언제 검토할 것인지를 개발자에게 알려준다.
선형순차 (폭포수) 모델
개요
폭포수 모델은 1970년대 보편적으로 많이 소개되어 소프트웨어 공학 교과서에 산업계 표준으로 많이 알려진 것이다. 1950년대에 항공 방위 소프트웨어 시스템 개발 경험으로 소개되었다
폭포에서 내려오는 물이 아래로만 떨어지듯, 각 단계가 순차적으로 진행되는 경우를 의미한다. 실제 사용되고 있는 폭포수 모델은 각 단계의 결과가 확인된 후에야 다음 단계로 넘어간다 이는 사용자 의견이 다르다거나 중간 결과를 점검한 결과, 전 단계의 작업에 결함이 있다면 다시 수정하도록 전 단계로 돌아가는 피드백 때문이다
응용분야가 단순하거나 잘 알고 있는 문제일 경우 적합하다. 복잡하고 잘 모르는 문제일 경우 정형화되고 세부적인 과정이 필요하나 단순한 문제는 한 번의 과정을 거쳐 개발할 수 있다. 또 비전문가가 사용할 시스템을 개발하는데 적합하다. 사용자를 교육시켜야 하는 설치 시점에 제품의 일부가 될 메뉴얼을 작성할 수 있기 때문이다
폭포수 모델을 채택한다면 각 단계가 끝난 후에 나와야 할 결과물을 명확히 정의해야 한다. 이를 생산하기 위하여 각 단계에 사용된 것을 "방법 (method)" 라 하고 개발 집단의 특수성을 고려하여 집단 내에서 정한 과정을 "소프트웨어 개발 방법론(software development methodology)" 라 한다.
절차
1. 타당성 검토
소프트웨어 개발 시나리오를 미리 예측하는 것으로 문제의 해결 방안들을 평가하고 가장 타당성있고 바람직한 해결 방안을 제안하기 위한 것이며 다음과 같은 사항을 포함해야 한다
1. 문제정의
2. 기술적인 면과 경제적인 면을 고려한 결정사항
3. 정의된 문제들의 해결 방안들과 각각의 기대 효과
4. 제안된 방안들에 대한 필요한 자원과 비용 및 인도 날짜
2. 계획
문제 실형 가능성을 타진하고, 시스템의 성격을 파악하여 비용과 기간을 예측한다. 또 사용자의 문제 정의와 해결 방안 및 이익 분석, 그리고 방법별로 필요한 비용, 자원, 기간 등을 분석한다.
3. 요구사항 분석
프로젝트의 요구사항과 필요성을 정확히 기술하는 단계이다
요구분석의 목적은 기능, 성능, 사용 용이성, 이식성 등 목표 시스템의 품질을 파악하는 것이다. 또 요구분석의 결과인 요구분석서는 의뢰자가 인도한 요구가 잘 반영되었는지 확인하기 위한 것이다
4. 설계
설계 단계의 결과인 설계서는 소프트웨어 구조를 기술한 것으로 각 모듈의 기능과 모듈 사이의 관계를 나타낸다.
5. 구현
프로그래밍을 하는 단계로 각 모듈(module)의 코딩과 디버깅(debugging)이 이루어지고 그 결과를 검증하는 단위(모듈) 시험을 실시한다.
6. 시험
적절한 계획 하에 모듈들을 통합하고 테스트하여 전체 시스템이 요구사항을 만족하는지 확인한다
모듈을 통합시키며 시험하는 통합시험 (integration test), 요구사항을 완벽히 관철시키는지 알아보는 시스템 검증(system test), 사용자가 직접 자신의 사용 현장에서 검증해 보는 인수시험(acceptance test) 등이 있다
7. 운영 / 유지보수
소프트웨어를 사용하며 문제점을 수정하거나 새로운 기능을 추가해 보다 유용한 소프트웨어로 발전시키는 단계이다
장점
1. 순차적인 선형 모델이므로 단순하고 이해하기 쉽다
2. 각 단계가 분리되어 있더 단계별로 정형화된 접근방법과 체계적인 문서화 작업이 가능하며 관리가 용이하다
3. 각 단계별로 산출물을 체크함으로써 프로젝트 진행 상황을 명확하게 알 수 있다
단점
1. 프로젝트 초기에 모든 요구사항을 완벽하게 작성해야 하나 사실상 거의 불가능하다.
2. 변경을 수용하기에 적합한 형태가 아니다
3. 동작이 되는 시스템 버전을 프로젝트 후반부에나 볼 수 있다
4. 대형 프로젝트에 제공하기 위한 확장은 어렵다
5. 문서화를 위해 지나친 노력을 소모하는 경향이 있다
6. 실수나 오류가 생기면 일정이 지연되거나 소요 자원이 증가한다
7. 각 단계의 종료를 위해 정형화된 문서를 요구하므로 모든 절차가 문서 위주로 진행된다
점증적 모델
개요
점증적 (incremental) 모델에서 소프트웨어는 여러 개의 모듈들로 분해되고 각각은 점증적으로 개발되어 인도된다. 이 모델은 선형 순차 모델을 여러 번 적용하여 그 결과들을 조합하는 것이다. 먼저 개발팀은 시스템의 핵심 모듈을 개발하고 인도한다. 계속적으로 새로운 기능을 추가한 모듈을 개발함으로써 앞서 개발된 모듈을 보완하고 새로운 시스템 버전을 만들게 된다
선형적으로 개발되는 각각의 소프트웨어 모듈을 점증이라 한다. 즉 시스템을 여러 번 나누어 릴리스하는 방법이다.
이 방법은 개발하여 운용하고 있는 시스템과 개발되어 있는 시스템이 병행 존재한다. 다음 릴리스 후에는 현재 운영되는 시스템을 개발 시스템으로 교체하게 된다
점증적 모델을 적용했을 때, 첫 점증을 주로 핵심 기능을 가지는 제품이 된다. 가장 기본적인 요구사항을 처리하고 부가적인 기능들은 개발되지 않은 채 남아 있다. 고객이 핵심 기능을 사용하여 평가함으로써 다음 점증에 대한 계획을 수립할 수도 있다.
진화형 모델에서는 이전 결과물을 바탕으로 다음을 계획하지만, 점증적 모델에서는 일련의 점증을 함께 계획할 수 있다
장점
1. 첫 번째 점증은 가장 중요한 요구사항들을 구현한 것이므로, 사용자는 전체 시스템이 개발될 때 까지 기다리지 않고 비교적 이른 시기에 사용할 수 있다
2. 소프트웨어 전체가 한꺼번에 릴리스되는 것 보다 시간차를 두고 점증을 개발하여 릴리스하는 방식이 사용자의 요구사항에 쉽게 대응할 수 있는 방법이다. 앞서 개발된 점증으로부터 얻어진 피드백을 차후 점증에 반영할 수 있기 때문이다.
3. 점증들은 점차적으로 규모나 기능이 축소되므로 프로젝트 관리가 비교적 쉽다
4. 중요한 부분이 먼저 개발되므로 차후에 개발되는 검증들을 통합하면서 반복적으로 테스트를 수행하게 되어 중요한 부분의 오류가 줄어들게 된다
단점
1. 기능적으로 분해하기 어려운 문제들이 있으며, 또 중요 기능들이 시스템의 여러 부분으로 나누어 배치되는 경우가 있다.
2. 요구사항들을 적당한 크기의 점증들로 나누기가 쉽지 않다
3. 점증을 구현하기 전에 명확하게 요구사항을 정의하지 못하면 개발 후에도 점증을 수정해야 하는 경우가 있다. 모든 모듈에 사용되는 공통의 기능을 미리 파악하지 못하는 경우가 그러하다
나선형 모델
개요
나선형 모델은 USC의 보엠(boehm) 교수가 1988년에 처음 제안한 모델로서, 반복 진화형 모델을 확장한 형태로 전체 생명주기에 걸쳐 일련의 프로토타이핑과 위험분석을 계획적으로 사용하여 프로젝트 수행 시 발생하는 위험을 관리하고 최소화 하려는 목적을 가진다.
즉, 고위험의 심각한 문제를 식별하고 제거하려는 데 초점을 두고 있다
각 단계를 작업하는 과정에서 대안의 타당성을 평가할 때 마다 프로토타이핑과 위험분석을 수행한다. 충분한 위험분석과 프로토타이핑을 통한 위험관리는 많은 비용이 들기도 하지만, 내장형 시스템과 같은 것을 개발할 때 특히 유용하고 가치가 있다. 소프트웨어 개발계획이 작성된 후와 설계와 테스트 계획을 개발한 후에 보다 충실히 프로토타이핑 방법을 사용한다. 그 후의 과정은 폭포수 모형과 유사하다.
나선형 모델은 선형적이지 않고 주기적으로 순환된다. 각 주기는 4단계로 구성되고 각 단계는 시계방향으로 진행되는 사분원으로 표현되며, 중심의 바깥으로 갈수록 총 비용은 증가한다
진화 단계
1. 계획 수립
목표, 기능 선택, 제약조건의 결정
2. 위험분석
기능 선택의 우선순위, 위험 요소의 분석
3. 개발
선택된 기능의 개발
4. 평가
개발결과의 평가
특징
순차적 모델의 제어와 프로토타이핑 모델의 반복적 특성을 수용하고, 새로운 요소인 위험분석을 추가한 모델이다. 대규모 시스템의 소프트웨어 개발에 가장 현실적인 소프트웨어 공학 패러다임으로 평가받고 있으며, 시스템 개발 시 생기는 위험을 최소화하여 관리하는 것이 주 목적이다
컴포넌트 기반 모델
정의
컴포넌트는 하나 이상의 기능을 가지는 독립적인 소프트웨어로, 조립하여 응용 프로그램을 작성할 수 있는 부품 형태의 소프트웨어이다.
표준 인터페이스 정의를 가진 컴파일된 바이너리 코드로서 복제되고 조합될 수 있는 소프트웨어 조각이며 서로 밀접한 관계에 있는 소프트웨어 패키지이고 독립적으로 개발하여 분배할 수 있는 단위이다.
특징
1. 인터페이스의 명세와 구현을 포함한 소프트웨어 프로세스이다
2. 컴포넌트가 쪼개져 일부만 전달될 수 없으며, 다른 컴포넌트와 구별되어야 한다
3. 다른 컴포넌트와 상호작용할 수 있는 유일한 방법은 제공된 인터페이스이다. 즉, 컴포넌트 명세는 클라이언트가 그 컴포넌트에 대하여 사용할 수 있는 모든 인터페이스를 제공해야 한다
4. 컴포넌트 소프트웨어는 구현과 인터페이스 명세를 완전히 분리해야 한다
5. 컴포넌트 간의 조립을 위해 다른 컴포넌트가 제공하는 인터페이스와 요구하는 인터페이스를 연결한다
CBD (component base development ; 컴포넌트 기반 개발) 프로세스
4GT (4th Generation Techniques)
CASE를 비롯한 자동화 도구들을 이용하여 요구사항 명세서로부터 실행 코드를 자동으로 생성할 수 있게 해 주는 방법이다.
자연어에 가까운 수준의 언어나 중요한 기능을 알려주는 표기법을 사용하여 소프트웨어를 명세화하는 데 초점을 두며, 소규모 응용에서는 요구사항 수집 단계에서 구현 단계로 직접 전환이 가능하다.
현재의 이용분야는 기업정보 시스템이나 정보 분석 등에 한정한다
장단점
목적하는 결과를 산출하는 코드를 자동 생산하는 방식으로, 목적하는 결과 표시가 가능하다.
대규모 소프트웨어 개발에 4GT를 사용하면 많은 비용을 분석, 설계, 검사에 소비한다.
불필요한 코드가 많고 유지보수가 어렵다.
현재 4GT 기법은 많이 활용되고 있지 않으며, 고급언어를 실행 코드로 바꾸어 줄 만큼 정교하지 못하다
UP (Unified Process) 모델
UML 방법과 도구를 위한 프레임워크로 설계된 Use-case 기반, 구조중심, 반복적이고 점정적인 소프트웨어 프로세스를 위한 필요성에 의해 대두 되었다.
한 사이클이 끝날 때 마다 테스트가 완료되어 통합 및 수행 가능한 시스템이 산출되는 점증적 프로세스 유형의 객체지향 개발 모형이다.
특징
전통적인 소프트웨어 프로세스 모델의 가장 좋은 기능과 특성을 이끌어 내고자 하는 시도라 볼 수 있다
최근의 소프트웨어 개발에서 꼭 필요한 전개적인 특성인 반복적이고 점증적인 프로세스 흐름을 제안한다
구축, 전이, 산출 단계가 수행되는 것과 동시에 다음 소프트웨어 점증을 시작한다. 즉 다섯 UP 단계가 순차적으로 일어나는 것이 아니라 시차적으로 병행성이 있음을 보여준다.
장점
1. 반복과정에서 높은 위험도를 잘 관리할 수 있다.
2. 반복 릴리스와 피드백을 통하여 요구사항을 잘 만족시킬 수 있다.
3. 초기 반복에서 소프트웨어 구조를 잘 확립할 수 있다
4. 시스템을 가시적인 모델(UML) 로 표현할 수 있다.
5. 소프트웨어의 변경을 잘 관리할 수 있다.
UP의 공정기술 구성
UP 의 개발 공정은 크게 두 축으로 나눌 수 있다. 가로축의 시간의 흐름에 따른 4단계 (Phases)와 세로축의 9가지 워크플로우(Process Workflows) 가 그것이다.
워크플로우는 컴포넌트 처럼 작업의 성격에 따라 일을 분리한 것이다. 또 하단부의 반복(Iterations)는 단계별로 일련의 공정들이 반복되는 것을 보여준다.
특징
6개의 엔지니어링을 위한 워크플로우의 명칭은 전통적인 폭포수 프로세스의 순차적인 단계를 연상시키지만, 반복적인 프로세스에서 이러한 워크플로우는 개발주기 동안 여러 차례 반복된다는 점에서 상이하다. 그리고 실제 프로젝트를 위한 워크플로우는 이러한 9개의 핵심 워크플로우를 이용하여 구성되고, 프로젝트를 완성하기 위해 구성한 워크플로우를 여러 차례 반복하게 된다.
프로세스 개발 중 워크플로우가 여러 번 반복 수행될 수 있지만, 각각의 반복마다 주안점은 조금씩 달라진다. 초기의 반복에서는 분석에 중점을 두지만, 점차 분석 및 설계, 구현 쪽에 중점을 두게 된다. 그리고 말기의 반복에서는 테스트와 배포에 중점을 두게 된다.
UP의 개발 단계
도입 -> 정련 -> 구축 -> 전이 -> 산출의 순서로 개발된다
| 단계 | 내용 |
| 도입 (inception) | 개발 범위 결정에 중점 프로젝트의 실현 가능성을 추정하고 개발 방향과 범위에 대해 팀원들 전체의 이해를 도모하는 수준 개념을 증명하는 프로토타입을 만들고, 이 프로토타입을 통해 몇 가지 요구사항을 명확하게 하는 수준 모든 요구사항을 정의하고 프로젝트에 대한 정확한 추정이 계획을 세우는 것은 아님 |
| 정련 (elaboration) | 요구사항들과 시스템 구성 요소들이 정해짐 소프트웨어의 중요한 기능들을 구현하고 테스트 함 기본 아키텍쳐가 만들어짐. 중요 구성 요소 구현, 위험 요소 파악 프로세스, 기반구조 및 개발환경을 구체화하고 도구 선정 |
| 구축 (construction) | 나머지 구성 요소 구현, 테스트 시나리오 작성, 배치계획 수립 사용자에게 인도할 수 있을 만큼 충분히 검증되고 품질이 최적화된 제품 만들기 테스트 실시 개발된 제품의 안정성과 완성도 마무리 |
| 전이 (transition) | 사용자 요구 충족 품질 수준 보장, 결점 제거, 사용자 교육, 최종적인 산출물 납품 소프트웨어 배치 및 인수 테스트 버그 제거 및 요구 성능 미흡 시 튜닝 활동 사용자 교육, 훈련 |
| 산출 (production) | 일반적 프로세스의 배포 액티비티와 일치 단계가 진행되는 동안 소프트웨어 사용을 모니터하고 운영환경을 지원하며 결점 보고서와 변경요구를 제출하고 평가 |
XP (eXtreme Programming) 모델
등장 배경
애자일 방법은 개발팀이 설계와 문서화 보다는 소프트웨어 그 자체에 더 초점을 두는 접근방법이다. 애자일 방법은 명세와 개발, 릴리스 등의 작업이 반복적으로 이루어지고 개발과정에서 사용자의 요구사항이 빈번히 변경될 수 있는 비즈니스 애플리캐이션 개발을 지원한다. 결국 애자일 방법은 고객에게 실행되는 소프트웨어를 가능한 한 빠르게 제공하고 여기에 대한 사용자의 피드백을 받아 변경된 요구를 다음 반복 단계에 또 반영시키려는 방법이다.
애자일 방법중 가장 많이 알려진 것이 익스트림 프로그래밍이며 그 외에도 Scrum, Crystal, Adaptive Software Development 등이 있다.
XP의 정의
반복형 모델의 개발주기를 극단적으로 짧게 함으로써, 프로그래머가 설계, 구현, 시험활동을 전체 소프트웨어 개발기간에 걸쳐 조금씩 자주 실시하도록 하고 소프트웨어 변경의 비용을 최소화하는 애자일 기법이다.
소프트웨어를 개발하기 위한 가볍고 효율적이며, 낮은 위험도를 가진, 그러면서 유연하고 예상 가능한 방법이다
XP의 특징
1. 시험 우선(test-first)
2. 시나리오부터 점증적인 시험 개발
3. 시험 개발과 검증에 사용자 참여
4. 자동화된 시험장치의 사용
XP의 12가지 실천사항
1. 계획 세우기
2. 작은 릴리스
3. 메타포
4. 단순한 설계
5. 지속적인 테스팅
6. 리팩토링
7. 페어 프로그래밍
8. 코드를 공유
9. 지속적인 통합
10. 40시간 작업
11. 현장 고객
12. 코딩 표준
XP의 문제점
1. 업무가 구현되기 전에 시험 가능한 컴포넌트를 작성해야 한다
2. 시험 우선 개발에서 업무를 구현하는 사람은 명세서를 완전하게 이해하여 시스템에 관한 시험을 작성할 수 있어야 한다.
3. 프로그래머는 시험보다 프로그래밍을 선호하고, 때로는 예외상황을 점검하지 못하는 불완전한 시험을 작성한다. 즉 시험 집합의 완전성을 판단하기 어렵다
4. 인수시험을 위해 사용자(고객)에게 의존하는 XP 시험 프로세스는 고객이 개발 프로세스 전 시간을 개발팀과 함께 하기도 어렵고, 고객은 요구사항을 충분히 제공했다 느껴 시험 프로세스에 참여하기를 꺼려할 수 있다.
XP의 프로세스
| 프로세스 | 내용 |
| 유저스토리 | 유저스토리는 일종의 요구사항이다 폭포수 모델이나 나선형 모델에서 'Requirement Process'나 'Software Requirements' 단계를 거치는 것과 비슷하다 UML의 use-case와 같은 목적으로 만들어지지만, 형식이 없고 고객이 작성한다는 점에서 다르다. 개발 일정을 수립하고 테스트(acceptance test)를 만드는 토대가 된다 |
| 스파이크 솔루션 | 유저스토리가 만들어지면 그 가운데 어려워 보이는 문제에 대해 스파이크 솔루션을 만든다. 기술적 또는 설계상의 어려운 문제를 해결하기 위한 것이다. 처리해야 하는 문제 외에 다른 조건들은 모두 무시하고 프로그램을 만든다 기술적인 문제를 줄이고 유저스토리를 가지고 추정한 개발 일정에 대한 신뢰도를 높이는 것이다 |
| 주기 계획 | 각 주기가 시작될 때 마다 주기계획회의를 한다 각 주기는 1 ~ 3주 정도로 정한다 고객에게 가장 가치 있는 부분을 가장 먼저 만들기 위해 각 주기에 처리할 유저스토리는 고객이 고른다 처리할 유저스토리는 이를 구현하기 위한 프로그램 과제로 나누고, 유저스토리는 고객의 말로 적는데 비해 과제는 개발자의 말로 적는다. 각 과제를 개발자에게 할당하고 소요기간을 예측하게 되는데, 같은 일이라도 소요기간은 사람마다 다를 수 있기 때문에 예측은 반드시 담당 개발자가 한다 |
| 주기 개발 | 각 주기의 길이를 비슷하게 유지하는 것이 좋다. 각 주기의 길이가 일정하면 프로젝트 진행에 대한 측정과 계획이 쉽다 프로그램 과제를 미리 스케줄링하면 안 된다. 각각의 주기에 해야 할 일은 해당 주기가 시작될 때 주기계획회의를 통해 결정한다. 고객의 요구사항은 계속 바뀌기 때문에 미리 계획하지 않는 것이 좋다. 주기 데드라인을 엄수한다. 주기 중 진척 상황을 확인해서 데드라인을 넘길 것 같으면 주기계획회의를 다시 소집하여 일부 과제를 뺀다. 다른 과제를 구현 안 된 채로 남기더라도 고객이 고른 가장 중요한 과제에 집중한다 |
| 승인 테스트 | 주기가 시작되면 주기계획회의에서 고른 유저스토리를 가지고 승인 테스트를 만든다. 여기서도 고객이 참여해 구현될 코드를 검사할 시나리오를 만든다 승인 테스트는 블랙박스 테스팅이다. 고객은 승인 테스트가 올바르게 만들어졌는지를, 그리고 실패한 테스트의 중요도를 확인한다. 또한 올바르게 만들어졌는지를, 그리고 실패한 테스트의 중요도를 확인한다. |