[소프트웨어 공학] Ch2: 소프트웨어 프로세스

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

: 소프트웨어 프로세스를 단순하게 나타낸 것

 

1) 폭포수 모델

1. 요구사항 분석 및 정의
2. 시스템/소프트웨어 설계
3. 구현 및 단위 테스팅
4. 통합과 시스템 테스팅
5. 운영과 유지보수

원칙적으로 폭포수 모델에서 각 단계의 결과로 승인된 하나 또는 그 이상의 문서들이 나와야 한다. 그리고 이전 단계가 끝나기 전까지는 다음 단계를 시작하지 않는다.

자유로운 팀 커뮤니케이션이 가능하고 소프트웨어 요구사항이 빨리 변경되는 상황에서 폭포수 모델은 적합한 프로세스 모델이 아니다. 이러한 경우에는 반복적 개발 애자일 방법론이 더 적합하다.

 

2) 점층적 개발

: 점층적 개발의 아이디어는 초기 구현을 개발하고, 사용자와 다른 사람들로부터 피드백을 받아서, 여러 버전을 거쳐 소프트웨어를 진화시킴으로써 요구한 최종 시스템을 개발하는 것이다. 명세화, 개발과 검증 활동은 분리되었다기보다는 활동 간 빠른 피드백을 가지고 중첩되어 있다.

 

▶ 장점

• 요구사항 변경을 구현하는 비용이 줄어든다. 다시 분석하고, 작성해야 하는 문서의 양이 폭포수 모델의 경우보다 훨씬 적다.
• 이미 진행된 개발 작업에 대해서는 고객의 피드백을 받기가 더 쉽다. 고객은 소프트웨어 시연에 대해 의견을 줄 수 있고, 얼마나 많이 구현되었는지 확인할 수 있다. 고객은 소프트웨어가 제공하는 가치를 경험하고 실제로 사용해볼 수 있다.
• 비록 전체 기능을 제공하지 못하더라도 고객에게 유용한 소프트웨어를 빠르게 전달하고 배포하는 것이 가능하다. 고객은 폭포수 프로세스를 사용하는 경우보다 더 일찍 소프트웨어가 제공하는 가치를 경험하고 실제로 사용해볼 수 있다.

▶ 단점

• 프소세스가 가시적이지 못하다. 관리자는 진척도를 확인하기 위해 정기적으로 중간 산출물(deliverable)이 필요하다. 만약 시스템이 빨리 개발되어야 한다면, 시스템의 모든 버전을 반영한 문서를 작성하는 것은 비용 측면에서 효율적이지 않다.
• 새로운 증가분이 반영되면서 시스템 구조를 훼손시키는 경향이 있다. 정기적인 변경때문에 새로운 기능이 추가되면서 어떤 방식으로든 코드를 망치게 된다. 시스템이 새로운 기능을 추가하는 작업은 하면 할수록 더 어렵고 많은 비용이 들게 된다. 애자일 방법에 의하면, 구조적인 품질 저하와 일반적인 코드 망가짐을 방지하기 위해서는 소프트웨어를 개선하고 재구성하는 정기적인 리팩토링(refactoring)이 필요하다.

 

3) 통합 및 환경 설정

대부분의 소프트웨어 프로젝트의 경우, 일부라도 소프트웨어를 재사용하게 된다. 재사용 중심 방법론은 재사용이 가능한 소프트웨어 컴포넌트와 이 컴포넌트를 조합하기 위한 통합 프레임워크에 기반을 두고 있다.

1. 요구사항 명세화
2. 소프트웨어 발견 및 평가
3. 요구사항 정제
4. 애플리케이션 시스템 설정
5. 컴포넌트 수정과 통합

 

 

2.2 프로세스 활동

1) 소프트웨어 명세화

1. 요구사항 도출과 분석
   : 기존 시스템 관찰, 잠재적 사용자 및 구매자와 토의, 업무 분석 등을 통해 시스템 요구사항을 얻어내는 프로세스
2. 요구사항 명세화
   : 요구사항 분석 과정에서 확고한 정보를 바탕으로 요구사항들을 담은 문서를 작성하는 활동
3. 요구사항 검증
   : 요구사항에 대한 현실성, 일관성과 완전성을 검사하는 활동

2) 소프트웨어 설계 및 구현

1. 아키텍처 설계
   : 시스템의 전체 구조, 주요 컴포넌트와 그 관계를 찾고, 이러한 구성요소들이 어떠한 방식으로 분산될지를 알아낸다.
2. 데이터베이스 설계
   : 시스템 데이터 구조를 설계하고 데이터베이스에서 어떻게 표현할지를 결정한다.
3. 인터페이스 설계
   : 시스템 컴포넌트들 사이의 인터페이스를 정의한다.
4. 컴포넌트 선택 및 설계
   : 재사용할 컴포넌트를 찾고, 만약 적합한 컴포넌트가 없는 경우에는 새로운 소프트웨어 컴포넌트를 설계한다.

3) 소프트웨어 검증

1. 컴포넌트 테스팅
   : 시스템 개발자가 시스템을 구성하는 컴포넌트를 테스트한다.
2. 시스템 테스팅
   : 시스템 컴포넌트를 통합해서 완전한 시스템을 구성하게 된다.
3. 고객 테스팅
   : 시스템이 실제 운영을 위한 인수가 결정되기 전, 테스팅 프로세스의 최종 단계에 해당한다.

4) 소프트웨어 진화

 

 

2.3 변경 처리

1) 시스템 프로토타이핑
: 고객의 요구사항 및 결정한 설계의 타당성을 확인하기 위해 시스템의 한 버전이나 부분을 빠르게 개발하는 것

1. 프로토타입 목표 설정 -- 프로토타이핑 계획
2. 프로토타입 기능 정의 -- 정의에 대한 개요
3. 프로토타입 개발 -- 실행 가능한 프로토타입
4. 프로토타입 평가 -- 평가 보고서

 

2) 점증적 인도

: 의견을 받거나 사용할 수 있도록 시스템 증가분을 고객에게 전달하는 것

1. 요구사항 개요 정의
2. 요구사항을 증가분에 할당
3. 시스템 아키텍처 설계
4. 시스템 증가분 개발
5. 증가분 검증
6. 증가분 통합
7. 시스템 검증
8. 증가분 배포
9. 최종 시스템

 

 

2.4 프로세스 개선

1) 프로세스 성숙도 접근법

: 프로세스와 프로젝트 관리 기법을 개선하는 것과 바람직한 소프트웨어 공학 실무를 조직에 소개하는 것에 중점을 둔다. 프로세스 성숙도의 수준은 기술적, 관리적 실무가 소프트웨어 개발 프로세스에 얼마나 잘 적용되고 있는지에 대한 정도를 나타낸다.

 

▶ 프로세스 개선 사이클

: 프로세스 측정 --> 프로세스 분석 --> 프로세스 변경

 

▶ 역량 성숙도 수준

1. 초기(initial)
   : 프로세스 영역과 연관된 목표를 만족하고, 모든 프로세스에 대해 수행해야 하는 업무의 범위를 명확히 설정하고 팀 구성원에게 정확하게 전달한다.
2. 관리(managed)
   : 프로세스 영역과 연관된 목표를 만족하고, 조직 차원의 방침을 마련해서 각 프로세스를 적용해야 할 시점을 정의하였다. 프로젝트 목표를 정의하고 있는 문서화된 프로젝트 계획을 마련해야 한다. 조직에 대한 자원 관리와 프로세스 모니터링 절차를 시행해야 한다.
3. 정의(defined)
   : 조직 차원의 표준과 프로세스 배포에 중점을 둔다. 모든 프로젝트는 정의하고 있는 조직의 여러 프로세스로부터 프로젝트 요구사항에 적합하도록 맞추고, 관리하는 프로세스를 가진다. 프로세스 자산과 프로세스 측정 내용을 수집하고 향후 프로세스 개선에 사용해야 한다.
4. 정량적 관리(quantitatively managed)
   : 하위 프로세스를 통제하기 위해 통계 및 다른 정량적 방법을 사용하는 것이 조직의 책임이 된다.
5. 최적화(optimizing)
   : 조직이 프로세스와 제품 측정을 통해 프로세스 개선을 추진해야 한다. 추세 분석을 해야 하고, 변화하는 비즈니스 요구에 맞추에 프로세스를 조정해야 한다.

 

2) 애자일 접근법

: 소프트웨어 프로세스 중 반복적 개발과 오버헤드의 감소에 중점을 둔다. 애자일 방법의 주요 특징은 기능을 빠르게 구현해서 배포하면서 고객의 요구사항 변경에 대해 대응을 한다는 것이다.

 

 

키 포인트

• 소프트웨어 프로세스는 소프트웨어 시스템을 제품화하는 것과 관련한 활동들이다. 소프트웨어 프로세스 모델은 이러한 프로세스들을 추상적으로 표현한 것이다.
• 일반적인 프로세스 모델은 소프트웨어 프로세스의 구조를 설명한다. 폭포수 모델, 점층적 개발과 재사용 가능한 컴포넌트 환경설정 및 통합이 이러한 일반적 모델에 해당한다.
• 요구공학은 소프트웨어 명세를 개발하는 프로세스이다. 명세서는 고객의 시스템 요구를 시스템 개발자들에게 잘 전달하기 위한 용도로 쓰인다.
• 설계 및 구현 프로세스는 요구 명세서를 실행 가능한 소프트웨어 시스템으로 바꾸는 것과 관련이 있다.
• 소프트웨어 검증은 시스템이 주어진 명세를 잘 따르는지와 시스템 사용자의 정확한 요구를 충족하는지를 확인하는 프로세스이다.
• 소프트웨어 진화는 새로운 요구를 충족시키기 위해 기존 소프트웨어 시스템을 변경할 때 이루어진다. 변경은 지속적으로 이루어지기 때문에, 소프트웨어가 유용하기 위해서는 진화를 해야만 한다.
• 프로세스는 변경에 대응하는 활동을 포함해야 한다. 이것은 요구 및 설계에 대한 어설픈 의사결정을 피하는 데 도움을 주는 프로토타이핑 단계와도 관련된다. 시스템 전체에 영향을 주지 않은 채 변경 작업을 할 수 있도록 반복적 개발과 인도를 고려해서 프로세스를 구축할 수 있다.
• 프로세스 개선은 소프트웨어 품질을 높이고, 개발 비용을 줄이거나 개발 소요 시간을 감소시키기 위해 기존 소프트웨어 프로세스를 향상시키는 과정이다. 프로세스 개선은 프로세스 측정, 분석과 변경과 관련한 사이클 프로세스이다.