computer_study

[소프트웨어공학] 02. Software processes 본문

카테고리 없음

[소프트웨어공학] 02. Software processes

knowable 2020. 9. 10. 00:01

Software process란?

누가 무엇을 언제 어떻게 특정 목표에 도달하는지를 정의한다. (product의 성능은 process의 성능과 비례한다고 알려져있다.)

"software life cycle" 혹은 "software development process"라고 하기도 한다.

software는 굉장히 다양하기때문에, software를 만드는 표준화된 process는 존재하지 않는다. 하지만 대부분 유사한 issue들을 가지고있기 때문에, 통상적인 process model을 살펴볼 수 있다.

 

 

Basic process steps

각 단계를 명확히 구분하고, 현재 개발이 어느 단계에 위치해 있는지를 아는 것이 중요하다.

 

1. feasibility study (타당성 연구)

프로젝트를 진행할지 말지 의사결정하는 단계로, 실제 개발 단계를 말할때에는 생략되기도 한다.

  • 프로젝트 진행시 이익이 무엇인가?
  • 프로젝트의 범위는 어떻게 되는가?
  • 기술적으로 가능한가?
  • 진행하는데 드는 비용과 시간은 어떠한가?

2. requirements engineering

제공할 서비스, 제약사항, system의 목적은 user와 협의를 통해 설정하고, 명확히 하여야된다.(서로 이해되도록)

  • 요구사항 도출 및 분석
  • 요구사항 문서화(명세)
  • 교구사항의 합당성 합리성 검사

3. design and implementation (두 단계로 나눠서 생각하기도 함)

요구 사항을 실행 가능한 시스템으로 변환하는 프로세스이다.

 

4. verification and validation (검증과 검사) (acceptance and release)

시스템의 사양이 준수하고 고객의 요구사항을 충족했음을 보여주는 과정이다.(명세 모두를 만족시키는지를 확인하는 절차)

  • 코드를 review하거나 executable 파일을 실제 실행해가면서 test한다.
  • 테스트 시 실제 데이터와 비슷한 테스트 케이스로 실행해야된다.(요구사항에 따라)

5. operation, maintenance, and evolution(유지보수)

  • operation : 실제 현장에서 작동시켜보는 과정
  • maintenance : 문제를 찾아서 고치는 과정 (유지보수)
  • evolution : 새로운 기능을 추가하거나 기술 환경을 조정하는 등 요구사항이 있을 때, system은 점점 발전해야된다.
  • phase out : system이 더이상 필요없다면 소멸시킨다.

이러한 과정은 다양한 과정으로 combine이 가능하고, 이 글에선 "waterfall model",  "iterative and incremental development", "spiral development", "V model" 을 살펴본다.

 

 

The Waterfall Model

앞 단계를 순차적으로(sequential 하게) 진행한다.

그림에서 보이는 것 처럼 요구사항 분석, 설계, 구현, 테스트, 유지보수 단계가 꾸준히 아래로만 흐른다.

 

장점

  • 모델이 쉽고 간단하기 때문에, 이해하고 사용하기 쉽다.
  • 각 단계마다 "산출물"이 있고, 검토 process가 있기때문에 (산출물이 나오는지 안노오는지 확인) 관리가 쉽다.
  • 때문에 진척사항을 쉽게 알 수 있다.

단점

  • 앞 단계에서 문제가 생긴 경우 다시 앞으로 돌아가기가 어렵다.
  • 요구사항이 중간에 변경될 확률이 높은 프로젝트에는 알맞지 않은 방법이다.
  • cycle의 마지막 부분에 가기 전 까진 software의 동작 여부를 알 수 없고, 데모도 만들 수 없다.

이러한 단점을 극복하기 위해 개선된 waterfall model또한 존재한다.

modified waterfall model

 

 

Iterative and Incremental Development

iterative(increment는 전제가 아니다)

시스템의 일부를 수정하고 개선하기 위해 반복적으로 작업하는 scheduling 전략이다.

 

시스템을 다양한 부분으로 나누어 서로 다른 시간 또는 속도로 개발하고, 완료되는 이들을 모두 통합하여 시스템을 개발한다. (이에 반대되는 개발 방법으로는 "빅뱅"통합이 있고, 이는 전체 시스템을 한꺼번에 개발하는 것이다.)

 

incremental

각 iteration마다 increment가 나오며, 진행 과정은 위 그림과 같다.

 

장점

  • 시스템이 완성되기 전, 기능은 제한되지만 실행 가능한 proto type을 빨리 만들어낼 수 있다.
  • 중요한 부분을 초반에 만들고, 다음 iteration마다 반복적인 testing이 가능하다.
  • 중간중간 increment를 확인 가능하기에 프로젝트 실패 위험이 감소한다.

단점

  • 프로젝트 시작에 필요한 비용, 시간 및 리소스같은 요소들을 예측하기 어려워, 개발 계획 수립이 어렵다.
  • 모든 요구사항이 사전에 수집되지 않기 때문에, 내부 구조가 좋기 어렵다.

 

Spiral Development

  • iterative와 비슷하지만 risk에 초점을 맞춘 방법이다.
  • 프로세스는 sequence가 아닌 나선형으로 표현된다.
  • 각 루프는 process를 나타낸다.
  • 필요에 따라 루프가 선택된다.
  • risk는 프로세스 전반에 걸쳐 명시적으로 평가되고 해결된다. (분석 과정을 명시적으로 개발 process에 넣어놓음)

 

V Model

  • "waterfall model"의 확장버전으로, testing에 초점을 맞춘 방법이다.
  • 개발 cycle의 각 단계와 테스트 단계 간의 관계를 보여준다.
  • v는 verification, validation(확인) 을 의미하기도 한다.

설계 시 test case를 미리 만들고, 그를 적용하여 testing한다.

testing시 test case를 미리 만들면, 각 case들을 엄격하게 만들지 않을 가능성이 있기 때문에 설계 단계에서 test case를 만든다. (시스템을 모두 만든 후 test case를 만들면, 그냥 맞겠다고 생각하고 넘어가는 부분들이 생긴다.)

Comments