소프트웨어공학 - 2. SW Development Process

1. Terminologies

- 프로젝트를 만드는 과정은 여러 Activity들로 구성된다.

- 각 Activity는 여러 task들로 구성된다.

- task에 시간 자원을 쏟다보면 생기는 중간 결과물을 work product라고한다.

2. Activities

- 일반적인 소프트웨어 개발 과정의 Activity들을 살펴보자.

- 요구사항 분석 : 사용자의 요구사항 분석을 마치면 중간 결과물로 use case model이 산출된다.

- 분석 : 주어진 요구사항들을 분석해서 객체 모델의 형태를 만드는 작업이다. 

- 시스템 디자인 : 아키텍쳐 구성, 서브시스템 구성

- 세부 디자인 : OOP 설계 기법을 적용하여 각각 서브시스템 내부 컴포넌트들을 디자인

- 구현 : 코딩

- 테스트 : 검증

3. SW Development process

- activities의 집합과 그 집합들의 관계이다.

- sw 개발 프로세스를 다른말로 SW development life cycle(SDLC)이라고 한다.

- 대표적인 소프트웨어 개발 프로세스 모델, Model을 소개하고 살펴볼 것이다.

- Sequential model : 작업의 반복을 고려하지 않은 모델, Waterfall model, V-model

- Iterative model : 작업이 반복됨을 고려한 개발 모델, Spiral model, unified process

 

- 개발 프로세스의 성격을 기준으로 구분하면 크게 둘로 나눌 수 있다.

- Plan-driven processes : process의 activities들이 미리 계획되고 이 plan이 잘 이루어지는지 감시한다.

- Agile processes : 일부 계획을 가지고 프로젝트를 진행하다. 변화가 생기는 경우 빠르게 다시 적응하여 process를 수정하는 방식이다.

 

- 프로젝트의 특성을 잘 고려하여 개발 프로세스를 선택하게 된다. 예를들면 전체적으로는 Agile processes를 채택하면서도 작은 과정들은 plan-driven processes를 채택할수도 있다.

4. Waterfall model

- planned driven 방식으로 phase를 반복 없이 순서대로 거친다.

- 관리자가 모니터링하기 용이하다.

- 각 단계를 마칠때마다 상당한 양의 document가 생성된다.

- 단계가 고정되어 있기 때문에 Implementation이 끝나는 시점에서 새로운 기술이 등장하거나 하드웨어의 변화가 발생하면 고객에게 결과물이 인도되지 못할 가능성이 있다.

- 요구분석 단계를 지나면 다시 추가 요구사항을 반영하기가 매우 어렵다. 따라서 미리 사용될 가능성이 있다고 평가되는(실제 사용이 안되어도) 기능도 추가하는데 이를 requirement bloating이라고 한다.

5. V-Model

- planned driven 방식으로 phase를 반복 없이 순서대로 거친다.

- testing이 더 세분화 되어있다.

- 요구분석에서 설계, 세부 구현, 개발 단계를 거치는 것은 waterfall과 같은데 각 과정에서 사용할 테스트 케이스를 미리 만들어 둬서 더 체계적인 검증이 이루어질 수 있도록 한다.

- 따라서 높은 품질을 보장할 수 있다.

- 하지만 waterful의 flexible하지 않는 점들은 그대로 가지고 있다. (추가 요구 사항 반영 어려움, 변화 적응 어려움)

- 시스템의 동작이 엄밀하게 검증되어야 하는 자동차 설계 등에 많이 활용된다. (하드웨어와 함께 개발되는 프로젝트의 경우)

6. Prototyping

- 요즘날에는 요구사항의 변화가 생겨도 유연하게 대처할 수 있는 개발 프로세스가 요구되고 있다.

- 에러 처리, 이미 잘 알고 있는 특징 들은 배제하고 요구사항의 이해가 더 필요한 기능을 아주 빠르게 미리 개발하는 것이다. 프로토타입은 요구사항의 더 확실한 이해를 제공하고 나면 목적을 달성하는 것이다.

- 프로토타입은 실제로 들어갈 기능을 만드는 것이 아니라 요구조건을 확실히 파악하는데 사용되기 때문에 사실 이것을 만드는 것도 비용이긴 하다.

- 따라서 requirement를 파악하기가 어려운 경우 사용될 수 있는 개발 방법이다.

7. Iterative and incremental Development

- 한번에 소프트웨어를 개발하는 것이 아니라 기능을 점진적으로 조금씩 만들어 추가하면서 버전을 관리해 소비자에게 제품을 인도하는 방식이다.

- 그럼 사용자의 모든 요구조건을 한번에 확정할 필요가 없다.

- UP, Agile 개발 접근법이 이에 해당한다. 

- 요구사항 분석, 아키텍쳐가 올바르지 못함 등의 위험 요소는 소프트웨어 프로젝트의 아주 common한 위협이다. 이 개발방법론은 이와 같은 위험에 더 유연하게 대처할 수 있다.

- 일부 파악한 요구조건만 가지고 아키텍쳐를 설계하는 것은 사실 이상적이지 않다. 

- 또한 반복작업이 증가될 수 있다. -> cost

- 따라서 이 개발 방법론은 빠르게 시장에 접근해서 피드백을 얻어야 할 필요한 경우 채택된다.

8. Spiral Model

 

- 1. objective setting : 목표 탐색, 대안 설정, 제약조건 파악

- 2. Risk assessment & reduction : 위험 식별, 해소

- 3. Development and validation : 시스템 개발, 시스템 일부를 검증

- 4. Planning : 현재 cycle의 sector에 기반하여 다음 phase를 계획

- 이렇게 점진적으로 cycle 계획, 수행을 반복하며 나선이 뻗어나가는 모양을 한다.

9. Rational Unified Process(RUP) & Unified Process (UP)

- iterative : 반복적 phase를 구성한다.

- architecture-centric : 초기 아키텍처를 설계하고 그 중심으로 개발을 수행 (risk-driven)

- Use-case driven : use case 중심으로 요구사항 분석 (cliend-driven)

- UML을 기반으로 소프트웨어를 개발해나가는 프로세스이다.

10 UP (Unified Process)

- 현대적인 개발 방법. 상업용을 RUP이라고 한다.

- up는 크게 네가지 Phase를 거친다. 하지만 이 Phase는 waterfall같은 Sequential mode의 phase와는 명백히 다르다.

- inception : 프로젝트가 feasible(실현가능)한지 결정한다. 프로젝트 수행할지 말지 결정하는 단계.

- elaboration : risk파악 risk줄이기위한 baseline architecture를 구상

- construction : 빠르게 개발

- Transition : 소비자에게 인도

 

- 시간이 지나면서 새로운 phase로 진입하지만 각 phase안에서 세로로 나열된 작업들의 iteration들이 이루어진다.

- waterfall은 프로젝트 중간까지도 현재 상태의 위험 요소들이 드러나지 않는다(risk 그래프가 떨어지지 않음). 소비자에게 보이기 직전에서야 오류와 risk가 드러나게 된다. (ex.요구사항 잘못 파악, 추가, 시대가 빠르게 변해서 불필요한 점, 기술스택의 변화 등등)

- 번면 UP는 그림처럼 시간에 따라 risk감소가 점진적으로 이루어진다. (handling changes)