[소프트웨어공학] 사회-기술적 시스템3 (시스템 통합에서 폐기까지)

 2.2.4 서브시스템 개발

 서브시스템을 개발하는 동안에 시스템 설계 시 식별된 서브시스템이 구현된다. 이것은 또 다른 각각의 서브시스템마다 시스템 공학 프로세스의 시작을 의미하고, 만약 서브시스템이 소프트웨어 프로세스는 요구 분석, 설계, 구현, 시험을 의미한다.

 때로는 모든 서브시스템이 개발 프로세스 동안 처음부터 개발되는 경우가 있다. 보통의 경우 어떤 서브시스템은 시장에서 완제품을 사와서 시스템에 통합되는 경우도 있다. 특정 목적의 컴포넌트를 개발하기보다는 기성품을 사는 것이 더 저렴하다. 이 단게에서 기성품을 사오는 것을 고려하기 위해서 재설계를 할 수도 있을 것이다. 기성품이 요구사항에 정확히 맞지는 않지만, 기성품을 사용할 수 있다면 설계를 재고하느 것도 그만큼의 가치는 있을 것이다.

 서브시스템은 대개 동시에 개발된다. 서브시스템 경계 간에 문제가 생기면, 시스템의 수정을 요청해야 한다. 서브시스템이 광범위한 하드웨어 공학을 포함하고 있다면, 생산이 시작된 후에 수정을 하는 경우 대개 비용이 많이 든다. 종종 문제를 보완하는 '차선책'을 찾아야 한다. 소프트웨어의 본질적인 융통성 때문에 이러한 차선책들은 대개 소프트웨어의 변경을 포함한다. 1장에서 설명한 것처럼, 이것은 소프트웨어 요구사항의 변경으로 귀결되므로, 커다란 추가적인 비용 없이 새로운 요구사항이 구현 될 수 있도록 소프트웨어를 설계하는 것이 중요하다.

 

 2.2.5 시스템 통합

 

 시스템 통합 프로세스 동안에는 각자 독립적으로 개발된 서브시스템을 하나의 통합시스템으로 만들기 위해서 합치는 과정을 거친다. 통합은 한꺼번에 동시에 모두 합치는 '빅뱅' 방법을 이용할 수 있다. 그러나 기술적, 관리상의 문제로 한 번에 하나씩 서브시스템을 통합하는 점증적 통합이 다음과 같은 이유로 가장 좋은 방법이다. 

  

 1. 모든 서브시스템의 개발 계획을 세우는 것이 불가능하기 때문에 거의 동시에 끝난다.

 2. 점증적 통합은 오류의 위치를 찾아내는 비용을 줄여준다. 만약 많은 서브시스템이 동시에 통합된다면, 시험하는 동안에 생기는 오류는 통합에 참여하는 서브시스템 중의 하나일 것이다. 기존에 이미 작업 중인 시스템에 하나의 서브시스템이 통합된다면, 오류는 기존의 서브시스템과 새로운 서브시스템의 관계에서 생기는 문제일 것이다.

 

 일단 컴포넌트가 통합되면 시스템의 집중적인 시험을 실시해야 한다. 이 시험은 컴포넌트 간의 인터페이스와 전체로서의 시스템 동작을 시험하는 것이 주 목적이다.

 잘못된 가정의 결과로서 생긴 서브시스템의 결함은 시스템을 통합하는 동안에 나타난다. 이것은 서브시스템에 대한 책임이 있는 계약자와 분쟁을 야기할 수 있다. 문제가 서브시스템 통합 중에 일어나면 계약자는 서브시스템에 결함이 있다는 것에 대해 이의를 제기할 수 있다. 이 문제를 해결하는 데 몇 주 혹은 몇 달씩 걸리는 경우가 있다.

 점점 더 많은 시스템이 COTS(commercial, off-the-shelf) 하드웨어나 소프트웨어를 구입하여 통합됨에 따라, 시스템 통합이 점점 더 중요해진다. 어떤 경우에는 서브시스템을 개발하지 않고 시스템 통합이 개발 자체가 되는 경우도 있다.

 

 2.2.6 시스템 진화

 큰 시스템은 매우 오래 사용한다. 사용하는 동안에 원래의 시스템 요구사항의 오류를 고치거나 새로운 요구사항을 구현하기 위해 시스템을 변경해야 한다. 컴퓨터는 새 것이나 빠른 것으로 교체할 수도 있다. 그 시스템을 사용하는 조직은 조직을 재구성하여 시스템을 다른 방법으로 사용하기도 한다. 시스템의 외부 환경이 변하여 시스템을 변경하는 경우도 있다.

 시스템 진화는 소프트웨어 진화처럼 다음과 같은 이유로 본질적으로 비용이 많이 든다.

 

 1. 제안된 변경은 비즈니스 관점과 기술적 관점에서 매우 주의 깊게 분석되어야 한다. 그 변경은 시스템은 목표에 기여해야 하며 기술적인 이유가 동기가 되어서는 안 된다.

 2. 서브시스템은 완전히 독립적일 수 없기 때문에 하나의 시스템에 대한 변경은 다른 서브시스템의 동작과 성능에 나쁜 영향을 미칠 수 있다. 이러한 서브시스템에 대한 후속 조치도 이루어져야 한다.

 3. 원래의 설계에 대한 이유가 기록으로 남아 있지 않을 수도 있다. 시스템 진화를 위해서는 왜 그렇게 설게했는지에 대한 이유가 밝혀져야 한다.

 4. 시스템이 오래 될수록 그것의 구조는 변경에 의해서 많이 망가져 있기 때문에 추가 변경을 위한 비용이 많이 든다.

 

 시간이 흐르면서 진화된 시스템은 구식의 하드웨어와 소프트웨어가 되어 있지만 믿을 만한 경우가 있다. 만약 조직에서 그것이 중요한 역할을 한다면 그것은 레거시 시스템(legacy system), 즉 조직에서 새로운 것으로 대체하고 싶지만 새로운 시스템 도입시 위험성이 매우 높은 시스템이라고 한다. 

 

 2.2.7 시스템 폐기

 

  시스템 폐기는 시스템이 소기의 목적을 달성하고 더 이상 서비스를 하지 않는다는 것을 의미한다. 하드웨어 시스템에서의 시스템 폐기는 시스템을 분해해서 재사용하거나 유해물질을 제거해야 하며, 소프트웨어는 더 이상 폐기할 실체가 없다. 그러나 어떤 소프트웨어는 폐기 과정을 돕기 위해서 시스템에 통합될 수도 있다. 예를 들어, 소프트웨어는 하드웨어 컴포넌트의 상태를 감시하기 위해서 사용될 수도 있다. 시스템이 폐기 되었을 때, 손상되지 않은 부품을 찾아내어 다른 시스템에 사용할 수 있다.

 만약 폐기되어야 할 시스템에 있는 데이터가 조직에 매우 가치가 있는 것이라면, 다른 시스템에서 사용할 수 있도록 변환해야 한다. 이것은 데이터 구조가 시스템에서 내부적으로 정의되어 있기 때문에 비용이 많이 들 수도 있다. 어떻게 저장되어 있는지를 알아내기 위해서는 소프트웨어를 분석해야 하고 데이터를 재구성하기 위한 프로그램을 다시 작성해야 한다.