[소프트웨어공학] 조직, 사람, 컴퓨터 시스템1 (조직의 프로세스)

 2.3 조직, 사람, 컴퓨터 시스템

 사회-기술적 시스템은 조직과 경영의 목표를 달성하기 위해서 만들어진 기업 시스템으로, 판매를 증가시키고, 자재 사용을 줄이며, 세금을 징수하고, 안전한 우주 공간을 유지하는 데 사용된다. 조직의 환경 속에서 삽입되어 사용되기 때문에 이러한 시스템의 구매, 개발, 사용은 조직의 정책, 절차 그리고 작업 문화에 의해서 영향을 받는다. 시스템의 사용자는 조직이 관리하는 방법과, 조직의 내부 및 외부 사람과 상호작용에 의해서 영향을 받는 사람이다.

 그러므로 사회-기술적 시스템의 요구사항을 이해하기 위해서는 조직의 환경을 이해해야 한다. 그렇지 않으면 시스템이 경영상 필요사항을 충족시키지 못하고, 사용자와 관리자가 시스템을 거절할 수 있다.

 시스템 설계에 영향을 미치는 사람과 조직 요소는 다음과 같은 사항을 포함한다.

  

  1. 프로세스 변경 : 시스템이 업무 프로세스에 대한 변경을 요구하는가? 만약 그렇다면 훈련이 필요할 것이다. 만약 변경이 중요하거나 혹은 변경 때문에 일자리를 잃게 되는 사람이 있다면, 사용자는 시스템의 도입에 저항하려고 할 것이다.

 2. 업무 변경 : 시스템이 사용자의 일의 숙련도를 떨어뜨리거나 일하는 방법을 변경시키는가? 만약 그렇다면, 조직에 새로운 시스템을 도입하는 것을 적극적으로 반대할 수 있다. 컴퓨터 시스템에 적합하게 작업 방법을 변경하려고 하는 관리자를 포함하는 설계일 경우에 동의를 얻어낼 수 있다. 관리자는 조직 내에서의 그들의 신분에 따른 역할이 감소된다는 것을 느낄 수 있다.

 3. 조직 변경 : 시스템이 조직 내에서 정치적인 함의 구조를 변경하는가? 예를 들어, 조직이 복잡한 시스템에 의존한다면, 시스템을 어떻게 운영하는지를 아는 사람은 상당한 정치적 힘을 갖는다.

 

 이러한 사람, 사회, 조직의 요소는 시스템이 그 목표를 달성할 수 있는지를 결정하는데 중요하다. 불행히도 사회적, 문화적 연구 경험이 없는 엔지니어는 그 요소가 시스템에 미치는 영향을 예측하기가 매우 어렵다. 조직에 대한 시스템의 영향을 이해하기 위해서 멈포드의 사회 기술, 체크랜드의 소프트 시스템 방법론과 같은 여러 가지 방법론이 개발되었다. 또한 작업에 대한 컴퓨터 기반 시스템의 영향에 관한 광범위한 사회학적 연구가 이루어져 왔다.

 관련된 모든 조직의 지식이 시스템 명세에 포함되어 시스템 설계자가 그것을 고려하는 것이 이상이지만, 실제로는 불가능하다. 시스템 설계자는 다른 비교가능한 시스템에 기초하여 가정할 수 밖에 없다. 만약 잘못된다면, 시스템은 예측불가능한 방법으로 오작동을 할 것이다. 예를 들어 시스템의 설계자가 서로 상충된 목표를 갖고 있는 조직의 일부분을 잘못 이해하고 있다면, 범조직적인 시스템에 대해 불만족스러운 사용자가 있을 수도 있다. 

 

 2.3.1 조직의 프로세스

 앞선 포스팅에서 시스템 개발에 포함된 서브프로세스를 나타내는 시스템 공학 프로세스 모델을 소개했다. 그러나 개발 프로세스는 시스템 공학에 포함된 유일한 프로세스가 아니다. 그것은 시스템 구매 프로세스와 시스템을 사용하고 운영하는 것과 서로 관련이 있다. 

 구매 프로세스는 시스템을 사고 사용하는 조직(고객의 조직)내에 포함된다. 시스템 구매 프로세스는 그 조직이 시스템을 구매하고 그 시스템에 대한 최고의 공급자를 결정하는 것과 관련이 있다.

 크고 복잡한 시스템은 주로 기성품과 특별히 제작된 부품의 조합으로 구성된다. 더 많은 소프트웨어가 시스템에 포함되는 이유는 기존의 하드웨어를 더 많이 사용할 수 있고, 그 하드웨어 부품을 효율적으로 작용하게 하는 '접착제' 와 같은 역할을 하기 때문이다. 이와 같이 접착제 역할을 하는 소프트웨어를 개발하게 된 이유는 기성품이 생각한 것만큼 역할을 제대로 해 주지 못하기 때문이다. 

 아래는 기존의 시스템과 특별히 설계된 시스템에 대한 구매 프로세스를 보여준다. 이 다이어그램에 있는 프로세스는 다음과 같은 점이 중요하다.

 

 

 1. 기성품이 요구사항을 염두에 두고 특별히 제작된 것이 아니며 정확하게 요구사항에 맞지 않는 경우도 있다. 그러므로 시스템을 선택한다는 것은 시스템의 요구사항과 기성품이 제공하는 기능 중에 가장 잘 일치되는 것을 찾는 것이다. 그 후에 시스템 요구사항을 수정하고 다른 서브시스템에 도미노 효과를 미칠 수 있다.

 2. 시스템이 특별히 제작된 것일 경우, 요구사항은 시스템 구매에 대한 계약서의 기초가 된다. 따라서 그것은 법적인 그리고 기술적인 문서가 도니다.

 3. 시스템을 만들기 위한 계약자가 선택되면, 요구사항에 추가로 변경할 것이 없는지 혹은 비용의 변경이 없는지와 같은 것을 고려할 협상 기간을 갖는다.

 

 

 시스템 개발 프로세스의 주요 단계는 이미 설명하였다. 복잡한 시스템은 시스템을 구매하는 조직과는 다른 조직에 의해서 개발된다. 그 이유는 구매자의 비즈니스가 시스템 개발인 경우가 거의 없기 때문에 그 피고용인은 복잡한 시스템을 개발할 기술을 가질 필요가 없다. 사실 한 조직이 크고 복잡한 시스템의 모든 부품을 설계하고, 생산하고, 시험하는 능력을 모두 갖춘 경우는 거의 없다.

 이러한 공급자를 주계약자(principal contractor)라고 하는데 다른 서브시스템의 개발을 여러 하청계약자와 계약할 수 있다. 항공 관제 시스템과 같은 큰 시스템의 경우 그룹의 계약자가 컨소시엄을 이루어 계약에 참여할 수 있다. 컨소시엄은 하드웨어 공급자, 소프트웨어 개발자, 주변장치 공급자, 레이더와 같은 특별한 장치를 공급하는 필요한 모든 유형의 공급자를 모두 포함해야 한다.

 구매 부서는 하청계약자보다는 주계약자와 상대하여 단일 구매자/공급자 간의 인터페이스가 이루어지도록 한다. 하청계약자는 주계약자가 만든 명세서에 따라 시스템의 부품을 설계하고 제작한다. 일단 완성되면, 주계약자는 부품을 통합하고 고객에게 인도한다. 계약에 따라 주계약자가 하청계약자를 선택하거나 아니면 구매자가 하청계약자를 선택할 수도 있다.

 운영 프로세스는 주어진 목적에 따라 시스템을 사용하는 과정에 포함된 프로세스이다. 예를 들어, 항공 관제 시스템의 운영자는 항공기가 이륙하고 착률할 때나 고도를 높이거나 낮출 때, 또는 비상사태 등이 일어났을 경우 특정 절차를 따른다. 새로운 시스템의 경우에 이러한 운영 프로세스는 시스템 개발 프로세스에서 정의되고 문서화된다. 운영자는 새로운 시스템의 효율적 사용을 위해 다른 작업 프로세스를 적용하고 교육을 받아야 한다. 시스템이 명세서에 따라 성능은 낼 수 있지만 그 기능이 실제 운영에 맞지 않을 수도 있다. 결과적으로 운영자는 설계한 의도대로 시스템을 사용하지 않을 수도 있다. 

 시스템에서 사람을 고용하는 주요인은, 예상치 않은 상황이 발생할 경우에 그러한 상황을 겪어 보지 않았더라도 효율적으로 대응할 수 있는 능력이 있기 때문이다. 그러므로 문제가 생길 경우에, 운영자는 정해진 프로세스를 위반할 수도 있지만 상황을 원상태로 복구할 수 있다. 운영자는 자기의 지식을 이용하여 프로세스를 개선하고 적용할 수 있어야 한다. 정상적인 경우에 실제 운영 프로세스는 시스템 설계자가 예측한 것과는 다르다.

 이것은 설게자가 운영 프로세스를 유연하고 개선할 수 있도록 설계해야 한다는 것을 의미한다. 이 운영 프로세스는 너무 까다로워서는 안 되며, 특정 순서대로 운영하도록 요구하지 않아야 하며, 시스템 소프트웨어는 특정 프로세스에 의존하지 않도록 해야한다. 운영자는 실제 상황에서 해야 할 것과 하지 말아야 할 것을 알기 때문에 프로세스를 개선한다.

 시스템이 운영된 후에 생기는 문제는 레거시 시스템과 같이 새로운 시스템을 운영하는 문제이다. 비호환성에 의한 문제일 수도 있고, 한 시스템에서 다른 시스템으로 데이터를 옮기는 문제일 수도 있다. 더 미묘한 문제는 시스템이 서로 다른 사용자 인터페이스를 갖고 있는 경우에 생길 수 있다. 새로운 시스템을 소개하는 것은 운영자가 사용자 인터페이스 명령을 혼합하여 사용하기 때문에 레거시 시스템에 대한 운영자의 오류 비율이 증가될 수 있다.