소프트웨어 공학 - Software Process

소프트웨어 프로세스란?

소프트웨어 시스템을 명세화 - 설계 - 구현 - 시험 하기 위한 활동들의 집합을 말한다.

그냥 제작 공정을 추상적으로 표현한 것이라고 생각하면 된다.

소프트웨어 프로세스에는 여러가지 모델이 있는데, 그 중 하나인 폭포수 모델을 한번 보겠음.

 

1. 폭포수(Waterfall) 모델​

개발의 흐름이 마치 폭포수처럼 지속적으로 아래방향을 향하는 것처럼 보인다는 데서 붙여진 이름이다.

 

위와 같은 과정으로 개발하는 프로세스를 폭포수 모델이라고 하는데,

 

여기서 약간 주의깊게 볼 부분은 1.요구 사항 정의 부분.

요구 사항 명세화 (Requirement Specification)와 구분 지어 생각해야한다.

'요구 사항 정의' 와 '요구 사항 명세화'는 다름.

 

그리고 폭포수 모델에는 문제점이 좀 있다. 

보다시피 피드백하는 과정도 뭔가 부족해 보인다. (피드백 개념은 후에 만들어 진것.)

일단 문제점 몇가지를 알아보자.

 

1. 프로젝트를 개별적인 단계로 나누면 비효율적이다.

2. 변화하는 고객의 요구사항에 응답이 힘들다.

 

딱봐도 너무 정형화된 과정 분할 때문에 동적인 반응이 힘들다.

해당 과정이 지나가고 나면 문제가 생겨도 되돌아가서 수정,진화시키기가 힘들다 이말이다.

폭포수 모델은 정말 요구사항이 기가 막히게 잘 정의되어 있을 시에만 사용하는 것이 좋다.

 

 

2. 진화적 개발

진화적 개발이란 말 그대로 소프트웨어의 진화에 초점을 맞춘 개발 프로세스이다.

그림을 보면 계속 명세화 - 개발 - 검증 과정을 반복하면서 초기버전, 중간버전, 최종버전 을 내놓는 것이다.

여기에 2가지 분류가 있다. (분류하는 기준은 다른것 같지만.. 일단 내가 배운대로 적겠음)

 

1. 탐험적 개발 (Exploratory Development)

개략적인 명세서를 작성하고 고객과 함께 의논하며 좀더 자세히 명세화 시키는 개발 방법이다.

요구사항이 잘 정의되어 있고, 상세한 명세서를 작성할 수 없을 때 적당한 방법이다.

 

2. Throw-away 프로토타이핑

시험 제품을 만들어 보는 방법이다. 시스템의 요구사항을 잘 이해하지 못했을 때

일단 만들어보고 요구사항에 대한 이해를 초점으로 하는 개발 방법이다.

 

S/W의 진화를 위해 고안된 방법.. 굉장히 좋아보인다 하지만

이 진화적 개발방법에도 역시나 문제점이 있다.

 

a. 프로세스 가시성의 부족

- 얼마나 개발했는지? 개발단계가 어디까지 와있는지 알 길이 없다.

 

b. 종종 시스템의 구조가 바람직하지 않게 망가진다.

 

c. 특별한 기술이 필요할 수도 있다.

- 빠른 프로토타이핑을 위해 개발 언어를 선택해야 된다던지. 그런 경우

 

그럼 이런 문제점이 있는데, 어디에 적용할 수 있을까?

진화적 개발의 적용성에 대해 알아보자.

 

ㄱ. 중소 규모의 대화식 시스템에 적용

ㄴ. 대형 시스템의 일부분 (e.g. 사용자 인터페이스)

ㄷ. 수명이 짧은 시스템

ㄹ. 요즘 강조되는 UX기반의 S/W에 적합할 수 있다.

 

 

3. 정형적 개발

일종의 수학공식 같은(?) 수학적 명세서를 바탕으로 다양한 표현방식으로 실행가능한 프로그램으로 변환하는 개발 방법이다. 여기서 변환할 때 명세서와 변환한 결과물이 정확한지에 초점을 맞추므로 (Correctness-preserving program transformation 이라고 하더라.) 프로그램이 명세서에 적합하다는 것을 보여주는 것이 쉽다.

 

cleanroom접근법 (만들 때 부터 버그가 없도록 개발하는 것)에 포함된다.

 

정형적 개발은 아래와 같은 과정을 거친다.

개발한다는 느낌보단 명세서를 s/w로 변환시킨다는 느낌이 강하다.

 

요구사항 정의 - 공식적인 명세화 - 공식적인 변환 - 통합 및 시스템 테스트 가 되겠다.

그리고 정형적 개발은 공식에 맞춰 변환하므로 그것이 명세서와  일치하는지에 대한 증명과정이 필요하다. 

 

위에 보이는 P1, P2, P3, P4 가 Proof 즉, 변환에 대한 정확성을 증명하는 과정이다.

 

이 개발 프로세스 또한 문제점이 있겠지.

a. 이게 구현하는게 난이도가 높아서 전문 기술, 기술 적용에 대한 교육이 필요하다.

b. 시스템에 속한 부분부분들을 명세화 시키는거 자체가 일단 어렵다. (예를 들어, UI )

 

뭐 이렇게 문제점들이 있지만 또 적용이 용이한 곳도 있다.

시스템이 가동되기 이전에 안전도 또는 보안이 확실하게 이루어져야하는 중요한 시스템 등에 용이할 것이다.

 

 

4. 재사용 중심 개발

재사용 중심 개발은 기존의 컴포넌트, COTS(Commercial-off-the-shelf) 시스템으로 부터 통합되는 것과 같은 체계적인 재사용에 기초를 둔 개발 방법이다.

 

그냥 기존에 있는거 갖다가 쓰는 개발 방법이라고 보면된다. 오픈 소스, API 등을 재사용해서 쓰는거.

(COTS도 그냥 상용 기성품이라는 뜻인데, 자세하게 알 필욘 없는 듯하다.)

 

아래 그림은 개발 과정이다.

1.요구사항 정의 

2.컴포넌트 분석 ​(뭘 갖다가 쓸것인가??)

3.요구사항 수정

4.재사용을 고려한 시스템 설계

5.개발과 통합 

6.테스트

​뭐 이정도.. 과정을 거쳐 개발한다고 볼 수 있다. 

요즘 각광받고 있고 점점 더 중요해지는 개발 프로세스인데, 아직 이 방법에 대해 경험치가 많이 부족한 실정이다.

 

5. 반복적 모델

프로세스 반복적 모델에 대한 내용을 한번 보자.

시스템의 요구사항은 프로젝트가 진행되는 동안 계속해서 진화한다. 그래서 항상 초기 단계로 다시 돌아가서 작업을 해야하는 프로세스 반복 에 대한 접근법이 필요하다.

이 프로세스 반복은 아까 포스팅했던 프로세스 모델들 어떤 곳에 적용이 가능하다. (그냥 반복하는 것)

몇가지 접근법이 있는데.. 먼저 '점진적 개발' 이라는 접근법에 대해 알아보겠다.

 

5.1. 점진적 개발

시스템을 한번에 인도하지 않고, 개발과 인도가 중요도 순서 대로 여러번 이루어지는 것이다.

각각 증가분에서는 요구되는 기능을 인도함.

(증가분은 개발해야 하는 모듈 정도라 생각하면된다. 개발하면 할수록 증가하니까 증가분?)

 

위에서 말했듯이, 사용자의 요구사항을 우선순위 메겨서 그 우선순위를 토대로 중요도를 메겨서 중요한 것부터 먼저 넘겨준다. 증가분 개발이 시작되면 요구사항은 변경이 불가능하다.

무슨 말이냐면 내가 1,2,3 까지 만들어서 넘겨줬고 4를 개발하고 있으면 요구사항을 변경할 수 없다는 말이다.

 

아래는 점진적 개발의 과정이다.

딱히 설명할게 없다. 보고있는 그대로다. 굳이 보자면

Assign requirements to increments 는 고객에게 뭘 인도할 건지 정하는 과정

 

그냥 고객에게 증가분 하나 넘겨주고 유효한지 보고 기존에 만들어진 것들과 통합해서 시스템 단위에서 잘 돌아가는지 테스트하고 또 새로운 증가분을 만들어 덧붙이고 .... 이런식으로 반복하는 것이 점진적 개발이다.

 

점진적 개발의 이점들이 많은데,

1. 고객은 중요하고 필요한 부분부터 요구하고 인도 받으므로, 시스템을 초기에 이용할 수 있다.

2. 고객과 함께 소통하여 개발 과정을 반복하므로 실패확률이 적다.

3. 초기에 인도해준 증가분이 후에 인도되는 증가분의 프로토타입 역할을 한다. 즉, 

    프로토타입을 토대로 요구사항들을 이끌어낼 수 있다.

4. 중요한 증가분을 가장 먼저 주니까, 계속해서 테스트하게 된다. (인도받을 때마다 통합시키고 시스템 테스트하잖아)

    그래서 가장 중요한 녀석이 많은 테스트를 해서 안정성이 높다.

 

점진적 개발 접근법은 정도 이점을 가진다. 

 

5.2. Extreme Programming

다음은 Extreme Programming (극단적 프로그래밍)에 대해 알아보자.

증가분의 개발주기를 굉장히 짧게 즉, 기능이 매우 적은 증가분을 계~~속 만들어서 소프트웨어 변경에 대한 리스크를 최소화하는 새로운 접근 방법이다.

모토는 "고객이 원하는 소프트웨어를 빠른시간안에 전달하는 것" 이다.

지속적으로 코드를 향상시키고, 소프트웨어 개발 팀에 사용자를 포함시킨다. 계~속 짧게짧게 인도하니까 그런듯?

개발 과정에 사용자를 포함 시켜 고객 위주의 개발이 가능하도록 한다.

 

​익스트림 프로그래밍 방법은 Pairwise Programming 즉, 짝 프로그래밍. 2명이 한조가 되어 프로그래밍 하는 방법에 주로 의존한다. 코드짜는 기계와 훈수꾼인가

결국 그냥 소프트웨어를 최대한 빨리, 짧은 주기로, 작고 간단하게 자주 릴리즈 하는 방법이다.

 

5.3. 나선형 개발

b.w boehm(뭐라고 읽지 보햄? 보임?) 이라는 분께서 만든 프로세스 반복 방법론이다.

프로세스 과정을 순서도가 아닌 나선형으로 표현한 것이다.

그림을 보고 설명하는게 이해가 더 빠를 듯 하다.

 

 

안쪽에서 부터 시작해서 360도 회전하는 하나의 루프를 프로세스의 한 단계로 본다.

나선형 개발 방법론은 S/W의 리스크(위험)를 명백히 측정하는 데에 좋은 모델이다.

 

4개의 사분면이라고 생각하고 보자. 하나의 루프는 2사분면 -> 1사분면 ->​ 4사분면 -> 3사분면​ 순서로 진행된다.

순서대로 설명하자면,

 

2사분면 → 계획 수립, 목표 설정

: 프로젝트 단계를 위한 특정한 목적을 식별함.

 

1사분면 → 리스크(위험) 측정과 해결

: 나선형 모델에서 가장 중요시 여기는 리스크를 측정하고 감소시킬 활동들이 위치한다. 

 

4사분면 → 개발과 확인

: 시스템에 대한 개발 모델을 선택, 우리가 배운 프로세스 모델들 중에 하나 고르면 됨~ 

 

3사분면 → 다음 단계 계획

: 프로젝트 검토, 다음 단계에 대한 계획을 세운다. 

 

위 단계들이 나선을 돌며 반복적으로 수행하는 것이 나선형 모델이다.