소프트웨어공학

[소프트웨어공학] 4. Software Processes (1)

leziwn.cs 2023. 9. 21. 18:51
The Software Process

: 소프트웨어 시스템을 개발하기 위한 체계적인 활동들

- 많은 소프트웨어 프로세스가 존재한다.

 

▶ 반드시 포함되어야 하는 활동들:

  1. 명세화: 소프트웨어 시스템이 해야 할 일을 정의한다.
  2. 설계 및 구현: 시스템의 구조를 정의하고 구현한다.
  3. 검증: 소프트웨어가 고객이 원하는 것과 일치하는지 확인한다.
  4. 진화: 변화하는 고객의 요구를 만족시키기 위해 진화한다.

 

▶ 소프트웨어 프로세스 모델

: 소프트웨어 프로세스를 단순하게 나타낸 것 (추상화시켜 표현한 것)

  • 폭포수 모델 -- 예) 기차/자동차 제어 모델 (요구사항이 명확하고, 변경되지 않는다.)
  • 점증적 개발 -- 예) 여행 (사용자와 상호작용)
  • 재사용 기반 소프트웨어 공학 모델 -- 예) 수강신청 시스템 개발 경험이 있는 사람이 우리학교 수강신청 시스템을 개발할 때 (재사용)

 

Software Process Descriptions

▶ 프로세스를 설명할 때 포함되는 것:

  • 제품: 프로세스 활동의 결과물
  • 역할: 프로세스에 참여하는 사람들의 책임
  • 사전/사후 조건: 프로세스 활동이 이루어지거나 제품이 만들어지는 전과 후에 만족해야 하는 조건들

 

Software Process Model
  • 실무에서, 특히 대규모 시스템에서는 모든 일반적인 프로세스에서 가장 좋은 특징을 일부 조합해서 사용하여 개발한다.
폭포수 모델 (Waterfall model)

폭포수 모델

  • 소프트웨어 개발 프로세스를 별도의 식별된 단계로 나누어 표현한다.
  • 앞 단계가 끝나야 다음 단계로 넘어갈 수 있다.
  • 예) 국방 (안정성이 중요하고, 요구사항이 명확)

▶ 폭포수 모델 - 단점

  • 프로젝트를 개별 단계로 유연하지 않게 분할하면, 고객의 요구사항 변경 요구에 대응하기 어렵다.
    --> 요구사항이 잘 이해되고, 설계 과정에서 변경이 제한될 때 적합하다.

▶ 폭포수 모델 - 사용

  • 시스템이 여러 사이트에서 개발되는 대규모 엔지니어링 프로젝트에서 주로 사용된다. 
    - 폭포수 모델의 계획 중심적 특성이 작업을 조정하는 데 도움이 된다.

 

점증적 개발 (Incremental development model)

점증적 개발

▶ 점증적 개발 - 장점

  • 고객 요구사항 변경을 수용하는 비용이 절감된다.
    - 다시 분석하고 작성해야 하는 문서의 양이 <폭포수 모델>보다 훨씬 적다.
  • 이미 진행된 개발 작업에 대한 고객 피드백을 더 쉽게 얻는다.
    - 고객은 소프트웨어 시연에 의견을 줄 수 있고, 얼마나 많이 구현되었는지 확인할 수 있다.
  • 고객에게 유용한 소프트웨어를 빠르게 전달하고 배포할 수 있다.
    - 고객은 <폭포수 모델>보다 더 빨리 소프트웨어가 제공하는 가치를 경험하고 실제로 사용해볼 수 있다.

 

▶ 점증적 개발 - 단점

  • 프로세스가 가시적이지 않다.
    - 중간 산출물을 문서로 확인하기 어렵다.
  • 새로운 증가분이 반영되면서 시스템 구조를 훼손시키는 경향이 있다.
    - 소프트웨어 개선을 위해 리팩토링 하는 데 시간과 돈을 들이지 않으면, 정기적인 변경으로 인해 구조가 손상되는 경향이 있다.

 

재사용 기반 소프트웨어 공학 모델 (Reuse-oriented software engineering model)

: 시스템이 기존 구성요소 또는 COTS 시스템에 통합되는 체계적인 재사용을 기반으로 한다.

재사용 기반 소프트웨어 공학 모델

▶ 재사용 기반 소프트웨어 공학 모델 - 장점

  • 개발해야 하는 소프트웨어 양을 줄인다.
  • 비용이 감소한다.
  • 소프트웨어를 고객에게 빠르게 전달할 수 있다.

 

▶  재사용 기반 소프트웨어 공학 모델 - 단점

  • 요구사항 타협은 불가피하다.
  • 시스템이 사용자의 진정한 요구사항을 만족시키기 어려울 수 있다.

 

Process activities
1) 명세화 (Software specification)

: 시스템을 개발하기 위해 어떤 서비스가 필요한지 이해하고 정의하며, 시스템의 운영/개발에 대한 제약사항을 찾아내는 프로세스

1) 명세화

 

2) 설계와 개발 (구현, 코딩) (Software design and implementation)
  • 소프트웨어 설계: 명세를 실현하는 소프트웨어 구조를 설계한다.
  • 구현: 소프트웨어 구조를 실행 가능한 프로그램으로 변환한다.

 

※ Design Process

Design Process

▶ 설계 활동 --> 설계 결과

  • 아키텍처 설계: 시스템의 전체 구조, 주요 구성 요소(하위 시스템/모듈), 이들의 관계 및 배포 방법을 식별한다.
    --> 시스템 아키텍처
  • 인터페이스 설계: 시스템 컴포넌트들 사이의 인터페이스를 정의한다.
    --> 인터페이스 명세
  • 컴포넌트 설계: 각 시스템 구성 요소의 작동 방식을 설계한다.
    --> 컴포넌트 명세
  • 데이터베이스 설계: 시스템의 데이터 구조를 설계하고, 데이터베이스에서 어떻게 표현할지 결정한다.
    --> 데이터베이스 명세

 

3) 검증 & 확인 (Software verification & validation)

: 시스템이 주어진 명세를 잘 따르고 있다는 것과 시스템 고객의 요구사항을 만족시키고 있다는 것을 보이기 위한 것

+ 확인(checking)/검토(review) 프로세스, 테스팅

 

※   Stages of Testing

: 컴포넌트 테스트 --> 시스템 테스트 --> 수락 테스트

  1. 개발/컴포넌트 테스트
    - 개별 구성요소는 독립적으로 테스트된다.
    - 구성요소는 함수, 객체, 관련된 엔티티 그룹일 수 있다. --> 서브시스템, 모듈
  2. 시스템 테스트
    : 시스템 전체를 테스트한다.
  3. 수락 테스트
    : 시스템이 고객의 요구사항을 충족하는지 확인하기 위해, 고객 데이터로 테스트한다.

 

4) 진화 (Software evolution)

: 변화하는 비즈니스 환경으로 요구사항이 변경됨에 따라, 비즈니스를 지원하는 소프트웨어도 진화하고 변경되어야 한다.

진화

저작자표시 (새창열림)