[소프트웨어공학] 소프트웨어 프로세스1 (폭포수 모델)

 소프트웨어 프로세스는 소프트웨어 제품을 생산하기 위해서 필요한 활동의 집합이다. 이러한 활동은 Java나 C와 같은 일반적인 프로그래밍 언어로 시작해서 소프트웨어를 개발하는 활동을 포함한다. 그러나 소프트웨어나 시스템 컴포넌트에 의해서 점점 더 기존의 시스템을 수정하고 확장하여 새로운 소프트웨어가 개발된다.

 소프트웨어 프로세스는 모든 다른 지적이고 창의적인 프로세스처럼 복잡하며, 의사 결정하는 사람에 의존한다. 판단력과 창의력이 필요하기 때문에 소프트웨어 프로세스를 자동화하기 위한 시도는 제한적으로 성공할 수밖에 없었다. CASE도구는 약간의 프로세스 활동을 지원한다. 그러나 적어도 앞으로 몇 년 내에는 소프트에어 프로세스에 참여한 엔지니어로부터 창의적인 설계를 떠맡을 정도로 광범위하게 자동화될 가능성은 거의 없다.

 CASE 도구가 제한적인 이유 중의 한 가지는 다양한 종류의 소프트웨어 프로세스 때문이다. 여기에는 이상적인 프로세스는 없으며 많은 조직이 소프트웨어 개발을 위해 자신만의 접근 방법을 개발해 왔다. 프로세스는 조직에서 사람의 능력과 개발될 시스템의 특징을 파악하기 위해서 발전되어 왔다. 증대한 시스템과 같은 시스템에서는 매우 구조적인 개발 프로세스가 필요하다. 비즈니스 시스템에서는 유연하고 기민한 프로세스가 더 효과적이다.

 많은 소프트웨어 프로세스가 있지만 기본적인 활동은 모든 소프트웨어 프로세스에 공통적이다.

 

 

 

 1. 소프트웨어 명세화 : 소프트웨어 기능과 소프트웨어 운영상의 제약 조건을 정의한다.

 2. 소프트웨어 설계와 구현 : 명세사와 일치하는 소프트웨어를 생산한다.

 3. 소프트웨어 검증 : 고객이 원하는 소프트웨어인지를 검증한다.

 4. 소프트웨어 진화 : 소프트웨어는 변하는 고객의 요구에 맞도록 개선되어야 한다.

 

 비록 '이상적인' 소프트웨어 프로세스는 없지만, 많은 조직에서 소프트웨어 프로세스를 개선할 수 있는 여지가 있다. 프로세스는 과거의 기술을 포함할 수도 있고, 산업계에서 사용하고 있는 최선의 기술을 잘 이용하지 못할 수도 있다. 많은 조직에서는 소프트웨어 개발 시 소프트웨어 공학 방법을 잘 이용하지 못하는 기업도 있다.

 소프트웨어 프로세스가 다양하지 않은 조직에서 프로세스 표준에 의해 소프트웨어 프로세스가 개선될 수 있다. 이것은 의사교환 시간을 줄여 주고 훈련 시간을 줄여 주며 좀 더 경제적으로 자동화된 프로세스를 만들 수 있게 해 준다. 표준은 새로운 소프트웨어 공학 방법과 기술을 도입하는 중요한 첫 번째 단계이다. 

 

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

  소프트웨어 프로세스 모델은 소프트웨어 프로세스의 추상적인 표현이다. 각 프로세스 모델은 특정 관점에서의 프로세스를 나타내고, 따라서 그 프로세스에 대해 부분적인 정보만을 제공한다. 여러 가지 프로세스 모델(프로세스 패러다임)을 소개하고 구조적인 관점에서 모델들을 나타낸다. 즉, 특정 활동에 대한 상세한 내용이 아닌 그 프로세스의 특징을 관찰한다.

 일반적인 모델은 소프트웨어 프로세스의 명확한 기술이 아니다. 오히려, 소프트웨어 개발의 방법을 설명하기 위해서 사용될 수 있는 프로세스의 추상화이다. 특정 소프트웨어 공학 프로세스를 만들기 위해서 인용되고 확장될 수 있는 프로세스 프레임워크로 생각할 수도 있다.

 프로세스 모델은 다음과 같다.

 

 1. 폭포수 모델 : 이 모델은 명세화, 개발, 검증, 진화를 기본적인 활동으로 취하며, 요구사항 명세화, 소프트웨어 설계, 구현, 시험 등과 같은 개별적인 프로세스 단계로 프로세스 모델을 나타낸다.

 2. 진화적 개발 : 이 접근법은 명세화, 개발, 검증 활동이 서로 중첩된다. 초기 시스템은 추상적인 명세로부터 빨리 개발되고 고객의 요구를 만족시키기 위한 시스템을 만들기 위해 고객의 입력과 함께 개선된다.

 3. 컴포넌트 기반 소프트웨어 공학 : 이 접근법은 많은 재사용 컴포넌트의 존재를 기반으로 한다. 시스템 개발 프로세스는 원점에서 개발하기보다는 컴포넌트를 통합하여 시스템을 개발하는 데 초점을 맞춘다.

 

 이러한 세 가지 일반적인 프로세스는 현재 소프트웨어 공학 실무에서 널리 쓰인다. 위의 방법들은 서로 배타적이지 않으며, 특히 대규모 시스템 개발 시에는 함께 사용되기도 한다. RUP라는 기법은 위 세 가지 모델의 요소를 모두 결합하였다. 대형 시스템 내에서의 서브시스템은 서로 다른 방법을 사용하여 개발될 수 있다. 그러므로 이러한 모델을 따로 설명하는 것이 편리할 수도 있지만, 실제로는 모두 통합해서 이해해야 한다.

 이러한 일반적인 프로세스의 변형이 제안되고 일부 조직에서 사용되기도 한다. 가장 중요한 변형은 아마도 정형적인 수학 모델이 생성되는 정형화된 시스템 개발이다. 이 모델은 일관성을 유지하는 수학적 변환을 사용하여 실행가능한 코드로 변환된다.

 정형화된 개발 프로세스 중에서 가장 널리 알려진 것은 원래 IBM에서 개발된 클린룸 프로세스이다. 클린룸 프로세스에서 소프트웨어 증분은 정형 명세로 작성되고, 이 명세는 바로 구현된다. 소프트웨어 수정은 정형적인 방법으로 이루어진다. 프로세스에서 결점을 시험하지는 않으며, 시스템 시험은 시스템의 신뢰성을 평가하는 것에 초점을 맞춘다.

 클린룸 방법과 B 방법에 기초한 또 다른 정형화된 개발 기법 모두는 엄격한 안전성, 신뢰성, 보안성 요구를 가진 시스템 개발에 적합하다. 정형 기법은 실제로 시스템이 보안성 요구 혹은 안전성 요구와 일치하는지를 확인하는 기관이나 고객에서 시연할 수 있는 안전성과 보안성 사례를 생성하는 과정을 단순하게 해 준다.

 이러한 특화된 도메인 외에 정형 변환 기법에 기초한 프로세스는 널리 쓰이지 않는다. 그것은 특화된 전문가를 필요로 하고 실제로는 시스템의 대부분에 대해 이 프로세스가 다른 방법에 비해 중요한 비용 절감이나 품질을 높여 주지는 못한다.

 

 4.1.1 폭포수 모델

 소프트웨어 개발 프로세스 중에서 가장 첫 번째로 발표된 모델은 매우 일반적인 시스템 공학 프로세스로부터 유도되었다. 이것은 한 단계에서 다른 단계로의 전환 때문에, 이 모델은 폭포수 모델 혹은 소프트웨어 생명주기라고 한다. 이 모델의 주요 단계는 다음과 같은 기본적인 개발 활동으로 나뉜다.

 

소프트웨어 생명주기

 

 1. 요구 분석과 정의 : 시스템의 서비스, 제약 조건, 목표가 시스템 사용자와의 면담을 통해 설정된다. 상세하게 정의되어 시스템 명세서로 사용된다.

 2. 소프트웨어 설계 : 시스템 설계 프로세스는 하드웨어 혹은 소프트웨어 시스템에 대한 요구사항으로 나누고, 전체 시스템 아키텍처를 설정한다. 소프트웨어 설계는 기본적인 소프트웨어 시스템 추상화와 이들 간의 관계를 기술하고 식별하는 것을 포함한다.

 3. 구현과 단위 시험 : 이 단계에서 소프트웨어 설계는 프로그램 혹은 프로그램 단위의 집합이 실체화된다. 단위 시험은 각 단위가 그것의 명세에 맞는지를 검증한다.

 4. 통합과 시스템 시험 : 각 프로그램 단위와 프로그램은 통합되며 소프트웨어 요구사항에 맞는지를 보증하기 위해서 전체 시스템을 시험한다. 시험 후에 소프트웨어 시스템은 고객에게 인도된다.

 5. 운영과 유지보수 : 정상적인 경우에 이것은 가장 긴 생명주기 단계이다. 시스템이 설치되고 실제로 사용된다. 시스템은 생명주기의 초기 단계에서 발견되지 않은 오류를 수정하고 시스템 단위의 구현을 개선하고 새로운 요구사항이 발견됨에 따라 시스템의 서비스를 향상시키는 것을 포함된다.

 

 

 

 원칙적으로 각 단계의 결과는 승인된 하나 또는 그 이상의 문서이다. 다음 단계는 이전 단계가 끝날 때까지 시작되지 않는다. 실제로 각 단계들은 중첩되고 서로에게 정보를 준다. 설계하는 동안에 요구사항이 가진 문제점이 식별되고, 코딩하는 동안에 설계 문제가 발견된다. 소프트웨어 프로세스는 단순 선형 모델이 아니라 개발 활동의 연속적인 일련의 반복을 포함한다.

 문서를 만들어 승인받는 데 대한 비용 때문에 반복은 비용이 많이 들며 재작업이 포함된다. 그러므로 몇 번 반복한 후에, 보통 명세화와 같은 개발의 일부분을 고정시키고 다음 개발 단계를 계속한다. 문제점은 차후에 해결하는 것으로 하고 무시하거나 건너뛴다. 이렇게 요구사항을 조기에 고정하는 것은 시스템이 사용자가 원하는 것을 하지 않을 수도 있다는 것을 의미한다. 그것은 또한 설계 문제가 구현 트릭에 의해서 묻힐 수 있는 나쁜 구조적 시스템으로 유도될 수 있다.

 마지막 생명주기 단계 동안에 소프트웨어는 사용 단계로 들어간다. 원래 소프트웨어 요구사항에서의 오류와 생략이 발견된다. 프로그램과 설계 오류가 나타나고 새로운 기능이 식별된다. 그러므로 시스템은 유용하게 쓰일 수 있도록 진화되어야 한다. 이러한 변경은 앞 단계를 반복하는 것을 포함한다.

 폭포수 모델의 장점은 문서가 각 단계마다 만들어지고 그것이 다른 공학 프로세스 모델에 잘 들어맞는다는 것이다. 중요한 문제점은 프로젝트를 서로 다른 단계로 나누는 융통성 없는 분할에 있다. 프로세스 초기 단계에서의 결정은 고객은 요구사항을 변경하기 어렵게 한다.

 그러므로 폭포수 모델은 요구사항이 잘 이해되고 시스템을 개발하는 동안 급격하게 변경되지 않는 경우에 사용되어야 한다. 그러나 폭포수 모델은 다른 공학 프로젝트 모델에서 사용되는 프로세스 모델을 반영한다. 결과적으로 이 방법에 기초한 소프트웨어 프로세스는 소프트웨어 개발에 사용되며 특히 소프트웨어 프로젝트가 대규모 시스템 공학 프로젝트의 일부분일 경우에 사용된다.