소프트웨어 프로세스 소프트웨어 제품을 생산하기 위해서 필요한 활동의 집합이다.
소프트웨어 프로세스의 기본적인 활동은 다음과 같으며 모든 프로세스에 대해서 공통적이다.
1. 소프트웨어 명세화 : 소프트웨어 기능과 운영상의 제약 조건을 정의
2. 소프트웨어 설계와 구현 : 명세서와 일치하는 소프트웨어를 생산
3. 소프트웨어 검증 : 고객이 원하는 소프트웨어인지 검증
4. 소프트웨어 진화 : 소프트웨어는 변하는 고객의 요구에 맞도록 개선되어야 함
비록 '이상적인' 소프트웨어 프로세스는 없지만 많은 조직에서 소프트웨어 프로세스를 개선할 수
있는 여지는 있다.
소프트웨어 프로세스 모델(프로세스 패러다임)은 소프트웨어 프로세스의 추상적인 표현이며, 명확한
기술이 아니다.
오히려 소프트웨어 개발의 방법을 설명하기 위해서 사용될 수 있는 프로세스의 추상화이다.
특정 소프트웨어 공학 프로세스를 만들기 위해서 인용되고 확장될 수 있는 프로세스 프레임워크로
생각할 수도 있다.
이 프로세스 모델을 도식화 하여 나타낸 일련의 흐름을 Software LifeCycle 이라고 하며 주요한 요소
1. Phases | 2. Intermediate Products | 3. Reviews
를 포함하고 있다.
어떤 LifeCycle 이 옳다거나 혹은 잘 못되었다는 기준은 없다.
개발 상황이나 목표 등을 명확하게 고려하여 적절한 모델을 택하는 것이 중요하며 그것이 S/W 공학
을 전공한 Architect 의 역량이 아닐까라고 생각해본다.
[ 1. Build and Fix Model ]
소위 'Simple is Best' 의 명확한 보기가 될 수 있는 모델로..
내 노트에 '될 때 까지 계속해, 어서~♡(싸모님 ver)' 라고 적혀있다.
제목 그대로 First 작업 후 test 를 하여 Modify 를 반복하는 방법이다.
거의 대부분의 학생들이 report 할 때 적용하는 방식이라고 강석중 교수님께서 농담을 하셨는데..;;
사실이라는..;;;
Build & Fix Process Model
한글번역본을 보면 '폭포수' 모델로 번역되어 있다.
흔히 순차적인 작업을 일컫는 용어로써 단계별로 Verify 와 Test를 거치며..
단순하고 간단하다는 장점이 있다.
또한 문서가 각 단계마다 만들어지기에 다른 공학 프로세스 모델에 잘 어울리기도 한다.
하지만 폭포수는 한 번 물이 떨어지면 다시 역으로 올라오지 못하는 자연의 진리처럼...
WaterFall Model 은 오류가 생겼을 경우 이전 단계로 돌아갈 수 없다는 단점이 있다.
그래서 수정시에는 Intergration 이라는 단계를 거치게 된다.
WaterFall Process Model
개인적인 모토이기도 한 Speed & Fast 를 중점적으로 고려하는 Model 이다.
진화적 모델이라고도 변역하는데 여기서 Prototype 은 '원형' '시제품' 'Demo' 등을 의미한다.
즉 초기에 구현을 한 후 이것을 이용하여 사용자의 의견을 반영, 만족스러운 시스템이 개발될 때
까지 Version UP 을 하는 방법이다.
Prototype 의 운명은 다음의 두 가지로 나누어지게 된다.
1. 실험적 개발(testing)
고객과 함께 그들의 요구사항을 찾아내면서 최종 시스템을 만들어가는 과정으로 Prototype의
일부분을 가지고 개발이 시작되며 그 시스템은 고객에 의해 제안된 사항을 토대로 수정/추가
되면서 발전한다.
즉, Prototype 을 실제적으로 사용하게 된다.
2. 쓰고 버리는 프로토타이핑(Throwaway Prototyping)
사용자의 요구사항을 이해하고 시스템에 대한 요구사항을 더 잘 정의하기 위한 프로토타입으로
이해가 잘 되지 않는 고객의 요구사항을 실험하는데 쓰이며 추후에는 버려지게 된다.
이 방식의 문제점은 Abstract(추상화)이 가능하기 때문에 Design 과 실제 Implement 된 시스템
사이의 Gap 이 생길수가 있다는 점이다.
대형 시스템의 경우 WaterFall 과 함께 Prototype model 를 혼용하는 것을 추천한다.
Rapid Prototyping Model
순차적, 점증적이라는 뜻의 Increments 를 정의하고 각 증분에 대한 우선순위를 적용한 후에
단계별로 순차적으로 개발하는 Process Model 을 일컫는다.
이전의 WaterFall 과 Prototype 의 단점인 유지보수의 어려움 및 설계 및 요구분석에서의 난해함을
보완하기 위해서 나온 모델이다.
점증적 개발 프로세스는 다음과 같은 장점을 지닌다.
1. 고객은 전체 시스템이 인도될 때 까지 기다릴 필요가 없다.
각 증분마다 결과물이 나오며 첫 번째 증분이 고객의 가장 핵심적인 요구사항을 충족하기 때문
이다.
2. 고객은 초기의 증분을 프로토타입으로 사용하고 추후에 시스템 증분에 대한 요구사항을 정보
또한 얻을 수 있는 경험을 획득할 수 있다.
3. 전체 프로젝트 실패에 대한 위험이 적다.
한 증분에서 문제가 생기면 그 부분을 집중적으로 보완하면 결과적으로 성공적인 개발이 된다.
4. 가장 높은 우선순위 서비스가 먼저 인도되고 추후의 증분이 그것과 통합되기 때문에, 가장
중요한 시스템 서비스가 가장 많이 시험된다.
그러나 모든 것은 양면적인 성향을 띄듯이, Incremental Model 에도 문제는 있다.
증분되는 각각의 작업은 비교적 작아야 하며(20,000라인 이하) 각 증분은 시스템 기능을 제공해야
한다는 점이다.
또한 전체 Frame Work Architecture 를 미리 설계해야 하는 어려움이 따르며 각 증분을 check 하기
위한 check List 가 존재해야 한다.
Operations 가 각 단계별로 보이지 않는다는 단점도 가지고 있다.
이러한 점증적 방법의 변형을 익스트림 프로그래밍(Extreme Programming) 이라고 한다.
이 방법은 매우 작은 증분을 개발하고 인도하는 것으로, 이 프로세스에 고객이 참여하고 지속적인
개선과 프로그래밍이 이루어진다.
Incremental Process Model
나선형 모델(달팽이 모델, Boehm, 1988)은 내부 반복을 동해서 시스템의 타당성을 증진시키고
요구사항 정의, 시스템 설계 등의 단계를 완성시키는 프로세스 모델이다.
나선에 있는 각 반복을 네 부분으로 나타내면 다음과 같다.
1. 목표 설정 : 프로젝트의 단계에 대한 목표와 Risk, 대안전력 등이 설정된다.
2. 위험 평가 및 감소 : 식별된 각 위험의 종류에 따라 상세 분석이 수행.
필요에 따라서 프로토타입 시스템을 개발하기도 한다.
3. 개발과 검증 : 위험평가 후에 그 시스템에 대한 개발 모델이 선택된다.
예를 들어 UI에 대한 Risk 가 높다면 Prototyping Model을 선택하게 될 것이며
주요 위험이 서브시스템 통합이라면 WaterFall Model 이 적합할 것이다.
4. 계획 수립 : 나선에 대한 추가 반복을 수행할 지의 여부를 결정 후 다음 단계 계획을 수립
The Spiral Process Model
