카테고리 없음2010. 5. 28. 08:33
관련논문 및 오라클 기능(오라클 spatial 기능을 이용한 GIS 구축 논문)


관련 사이트 

openmap-xr
어떤 특정 공간 데이터 파일을 화면에 그래픽적으로 나타낼 수 있는 라이브러리

C#에서 화면에 특정부분을 선택하는 코드 

GIS 프로그래밍 연구소
Shape 파일-> 잘모르겠지만 이것을 화면에 표시하는 방법이 상세히 나타나 있다

C#으로 OSM파일 노드들 읽어오기

OSM WIKI 



이정도를 기반으로 개발하면 될듯허다.


Posted by 태씽
카테고리 없음2010. 4. 17. 17:02
13.1 INTRODUCTION
3장에서 테크놀로지(기술)에는 공백이 없다고 했다. 그것은 명확한 컨텍스트 내에서 사용이 되며 컨텍스트 내에 많은 팩터들에 에 영향을 받는다.  시스템의 도입에 영향을 받는 사람들을 알려진 대로 stakeholder라고 하고 그들의 요구가 complex하고 conflicting하게 될 수 있다. 게다가 우리는 어떻게 시스템의 도입이 실제로 조직과 작업 방식을 변화시키는지 이해할 필요가 있다. 그리고 어떤 임팩트가 나타나는지에 대해서도 알아야한다. 
이번 챕터에서는 scio-organizational의 사용환경에 대해 상세히 알아보고 조직에서 테크놀로지를 승인하게 되는데 영향을 미치는 몇몇 포괄적인 이슈들에 대해서 논의를 해보도록 한다. 요구사항을 capture하는것은 모든 소프트웨어 엔지니어링 방법론에서 중요한 부분이다. 하지만 때때로 이 활동은 주로 시스템의 기능적 요구사항에 초점을 맞추게 된다.-시스템이 어떤것을 할 수 있는가 하는 요구사항이다. 기능성이나 수용성같은 non-functional human issue에 대해서 덜 초점을 맞추게 되는것 또한 마찬가지이다. 이런 문제들이 고려가 될지라도 그들은 오직 유저 자신들에서 정보를 얻는것보다는 유저의 요구를 관리하는 못적으로만 반영을 하게 된다. stakeholder requirement modeling은 유저 뿐아니고 시스템에 영향을 미치든 모든이의 요구를 알아냄으로서 이 밸런스를 맞추게 된다, 이것은 앞으로 사용될 컨텍스트안에서 행해 진다.
우리는 처음에 새로운 기술적인 솔루션이 도입이 될때 생기는 몇몇 organizational issue에 대해서 논의를 하고 stakeholder의 요구사항을 capture하는 model과 method들에 대해서 알아볼 것이다.;


13.2 ORGANIZATIONAL ISSUE(조직적인 이슈)
정보 통신 시스템의 도입에 영향을 미치는 organizational issue에 대해서 알아봐야 한다. 이들 factor들 중에는 system 밖에 존재하는 factor가 있다. 즉 이말은 이 시스템을 전혀 사용하지 않는 사람들에 의해서 도입이 결정되기도 한다는 것이다. 하지만 이들 factor가 시스템을 도입해서 성공하는가 실패하는가에 대해서 매우 중요한 요소가 된다. 

13.2.1 Cooperation or conflict(협동 혹은 갈등)

computer-supported cooperative work(CSCW)라는 용어는 그룹이 어떤 협동적인 방법으로 행동을 한다는 것을 가정한 것 차럼 보인다. 이것은 어떤 범위에서는 명백히 사실이다; 심지어 경쟁하는 축구 팀들이 게임의 룰을 위반하지 않는 범위에서 서로 협동을 할수도 있다. 하지만 그들의 협동은 어느정도 까지 밖에 되지 않는다. 어떤 조직내에 있는 사람들과 그룹은 서로 상반된 목표를 가진다.그리고 시스템은 이것을 무시하게 되면서 시스템이 실패할 가능성이 있다. 

조직이 이미 매우 전산화가 되어 있다고 가정하면, 각각의 부서들은 그들 자신의 시스템이 있을 것이고 이사진이 통합된 정보가 필요한지를 결정해야 될 것이다. production manager는 이제 주중 작업계획을 세울 때 재고를 바로 파악할 수 있다, 그리고 마케팅 부서는 마케팅 설문지를 보내기 위한 판매 사업부 컨택트 리스트를 컨설트할 수 있다. 모든것이 희망적이고 회사는 좀더 효율적으로 운영이 될것이다. 하지만 정말 그것이 가능할 것인가??
창고 관리인은 항상 비상사의 공급을 위해서 제고 레벨을 약간 축소해서 이야기를 한다. 때때로 신뢰할만한 공급자가 있다면 레벨을 부풀리기도 한다. 또한 재고 정보에 대한 요청은 앞으로의 수량에 대한 정보를 지속적으로 얻고 미래의 주문에 대비할 수 있게 한다. 이제 창고 관리인은 제어하는 감각을 일어버렸고 정보의 중요한 source들을 잃어버렸다. 판매부서에 있는 멤버들은 또한 행복하지 않을 것이다.: 그들의 contact(관계, 접촉, 연줄)는 그들의 생계다. 
=> 창고관리인이 관리하는 감각과 중요한 정보를 잃어버린다면 판매 부서에 까지 영향을 미치게 된다. 판매부서에 있어서 창고관리인과의 contact는 그들의 직접적인 일이므로 생계와 관련이 있다는것이다. 
여기서 people은 창고 관리인 group은 시스템을 이용하는 조직적인 그룹


그들이 원하는 마지막은 마케팅에서 실수를 하고 수년동안 이어져 왔던 고객과의 관계를 망쳐버린 누군가이다. 이들중 누군가는 시스템을 타도를 할려고 하고 온라인 상에 있는 정보를 무해하게 유지하지만 개인적인 파일에는 진짜 정보는 그렇게 하지않는다. 시스템은 점진적으로 데이터에서의 측면을 잃고 그 데이터는 부정확해진다. 그렇게 하므로써 조직내에 사기가 떨어지고 생산성이 감소할 것이다. 위원회는 컴퓨터 시스템을 업그레이드 하느것을 고려를 할 것이다. 
=> 시스템의 정보를 제대로 유지 하지 못하게 하는(예를 들어서 온라인 상의 정보와 실제 정보가 다르다 던가) 누군가가 존재한다면 시스템의 데이터는 점진적으로 부정확해지고 조직내에 사기가 떨어지며, 생산성이 감소할 것이다. 그렇게 됨으로서 이사회 같은곳에서 회의를 해서 컴퓨터 시스템을 업그레이드를 하는것을 고려할 것이다.  

새로운 컴퓨터 시스템을 설치하기 전에 명시적으로 협동적이든지 아니던지, 누군가는 그것에 영향을 미치는 stakeholder에 대해서 알아야한다. 이들은 단지 유저가 아니고 시스템으로 부터 정보를 제공하거나 얻게되고 그들의 조직에서의  능력이나 영향력을 증가시키거나 감소 시킨다. 시스템이 이들 영향을 미치는 것의 리스트에 매우 낮게 떨어지는것은 시스템을 주문한 일반적인 고객의 경우에서 빈번하게 일어난다. 변화를 매우 신중하게 하는것은 그들에 장소에서 어떤 존재하는것의 반환없이 힘과 영향력을 가지거나 몇몇 stakeholder로 부터의 제어를 얻을 수 있다.

=> stakeholder는 역활만 바꾸면 시스템으로 부터 정보를 제공하거나 받거나, 조직에 대한 권력이나 영향력이 작거나 크거나에 관계 없이 가능하다. 시스템에 의해 영향을 받는 사람을 stakeholder라고 한다.
 시스템 도입시 커다란 영향을 미치게 된다.
이들을 직접적으로 시스템을 이용하는 유저는 아닌 반면에 시스템으로 부터 정보를 주고 받거나 조직내에 권력이나 영향력을 작게 혹은 많이 행사할 수 있다.

13.2.2 Changing power structures(권력 구조의 변화)
stakeholder의 증명은 조직적 구조에서 정보의 흐름과 권력관계를  알아내는것이다. 확실히 모든 조직들은 이런 정보의 네트워크를 가진다. 이것은 사회적, 기능적 접촉을 서포트 해준다. 하지만 권한과 정보의 흐름은 line management를 통해서 상승하거나 하강하게 된다. 
조직의 물리적인 레이아웃은 때로 정형적인 계층구조를 나타낸다: 각 부서는 다른 층에 존재하고 각 구역별로 일이 진행이 될것이다. 판매부서의 누군가가 마케팅 부서의 누군가와 이야기 하기를 원한다면 다른 오피스로 가야될 것이다. 그들 각각의 관리자들이 그들의 contact를 모니터할 수 있다. 동료가 물리적으로 가깝다면 부서에 대해서 일의 충실함이 커질것이다. 이메일 시스템은 이런 장벽이 존재하지 않는다; 다른 부서에 있는 동료들과 잡담하듯이 대화가 가능하다. 이런 시도가 라인매니저의 중재나 제어의 역활이다.
 
게다가 face-to-face 대화에서는 매니저는 쉽게 부하에게 영향을 가할 수 있다: 그들의 상대적인 직위와 대화와 대화가 아닌 다른 행동의 패턴역시 알 수 있다. 
 이메일 메시지는 이런 것을 알 수 없게 되고 관리자가 권한을 행사하기가 힘들어진다. 심지어는 계층구조를 무시하고 바로 메시지를 보내는 것 역시 가능하다, 관리자의 관리자 한테도 메시지를 보낼 수 있다는 것이다.  

많은 조직들이 수평적인 조직 구조로 가는 가운데 전략적인 측면에서 이런 효능들이 받아들여 지고 있다. 하지만 변화의 과정에서 불만있는 하급 관리진에 대한 조직의 대처가 가능할까?  

이런 영향들이 별로 환영을 받지 못하는 경우가 발생하면서 시스템의 성능이 떨어지고 규제가 강하게 된다. 한가지 경우로 이메일 시스템이 도입되고 잘돌아 가고 있다고 하자. 하지만 관리진 입장에서는 제어가 잘 안되고 그들의 하급자들의 커뮤니케이션에 의심이 갈것이다. 그래서 로깅시스템이 도입됨으로 모든 이메일 모니터가 모니터할 수 있게 된다.
 
시스템은 빠르게 파괴되어가고 이메일의 로깅은 고용자들에게는 좀더 멀리 퍼지게 되고 사원들이 시스템을 남용하는 것을 알 수 있다. 하지만 이런것들을 주의깊게 사용해야 한다: 이메일을 이용해서 이상적효과를 얻는이 아니고 생산성이 줄어드는 역효과가 날 수 있다.
기술은 사회적 변화에 따라서 중요한 요소가 되긴하지만 기술의 그것이 도입되기 전에 어떤 영향을 미칠수 있는지 측정되어야 한다. 

13.2.3 The invisible worker(보이지 않는 근로자)
거리가 떨어져 있는데서 같이 일을하고 협업을 하는 능력이 있다면 그것은 어떤 기술적 그룹을 각각 다른 장소에 배치할 수 있다는것을 의미한다. 이것은 복합 기능적 네이버후드 센터같은 형식을 가진다. 서로 다른 부서에 있는 사원들이 그들의 기능적인 동료에 전자적인 연락수단을 이용해서 그들의 일을 할 수 있다. 대신에 분배된 그룹웨어를 이용하면 진정한 의미의 홈베이스 재택 근무를 할 수 있다. 
이런 작업환경의 생태학 적 경영적인 장점은 이미 잘 정리가 되어있고 이와 같은 커뮤니케이션과 CSCW 기술이 이런 전통적인 장벽을 극복할 수 있을것 처럼 보인다. 
이런 작업에 대한 어떤 장애물, 장벽같은 것은 자세히 조사를 해본다면 그것이 기술적이 아니고 경영상의 문제라는것을 알 수 있다. 무엇보다도 경영(관리) 스타일은 원격근무를 전부 가능하게도 불가능하게도 할 수도 있다.  경영 스타일이 management by presence 즉 일하는 사람이 오피스에 있어야하는 그런 경영 방침이라면 원격에 있는 근로자가 신뢰를 받을 수 있는 방법따윈 없을것이다. 반면 management by objectives 목표달성경영의 경영방침이라면 부하직원이 그들의 임무를 완수하고 결과를 냄으로서 일하고 있다는 것을 알수 있다. 그렇다면 원격지에서 일하는것이 문제가 되지 않는다. 
원격지에서 일하는 것이 수락이 되어도 실제 물리적으로 존재하지 않는다는 것은 문제가 될수 있다. 승진이 다가올 때 근로자가 참석을 하는것이 더 가치있어 보인다. 어떤 목적의 기준이 아닌, 존재한다는 것은 어떤 가치를 인식하게 해줄 수 있다. 
우리는 또 사회적이고 경영적인 관계가 어떤 기술적인 도입의 하는데 대부분의 영향을 미치는것을 보았다. 많은 video-based groupware 시스템이 실제 일한다는 느낌을 만들어 내려고 하고 있다. 

13.2.4 Who benefits(누가 이익을 얻는가?)
어떤 information 시스템의 실패에 빈번하게 나타나는 원인으로 시스템에서 이득을 보는 사람이 직접적으로 일하는 사람이 아니라는 것이다. 하나의 예를 들어보면 우리가 19장에서 좀 더 상세하게 알아볼 구조화된 메시지 시스템(structured message system)에서 그 문제를 찾아 볼 수 있다. 이런 시스템에서는 발신자가 어떤 적절한 양식에 맞춰서 보낼 정보를 넣어야 하는 일을 해야한다. 하지만 이득을 보는 사람은 수신자이다. 공유 달력(shared calendar)의 예를 들어보자. 이 시스템의 수혜자는 미팅시간을 알아보는데 시스템을 이용하는 관리자가 된다. 하지만 실제로 달력을 최신의 상태로 계속 업데이트를 하는 사람은 관리자의 개인비서가 하는일이다. 하급자의 경우는 비서의 지원을 받을 수는 없고 자신이 직접 달력을 최신상태로 유지 해야한다. 물론 어떤 미팅이 자동을 배치가 되어 혼란이 발생한다면 하급자가 시스템에 기록되지 않는 약속같은 것을 처리해서 달력을 재정돈 해야할 것이다. 이와 같은 시스템은 관리자가 사용을 강제하거나 그렇지 않는 다면 시스템이 간단하게 사용되지 않을것이다. 많은 이와 같은 그룹웨어 시스템들이 그냥 잘 동작하는가? 하는 것을 보고 도입되는 경우가 많고 시스템이 잘 사용되지 않는 그런 사례가 발생하게 된다.  
이와 같은 현상에서 얻을 수 있는 교훈은 시스템이 어느정도의 균형을 맞춰야 한다는 것이다. 만약 당신이 시스템에 대해서 해야할 일이 있으면 시스템에서 이득을 볼수 있어야 한다. 공유 달력에 대해서 개인적인 유저 인터페이스를 개선한다면 계획을 종이에 적는 것보다 확실히 장점을 가질 수 있을 것이다. 게다가 어떤 사람이 전자 수첩(PDA 같은)을 이용한다면 시스템을 통해서 이들 정보를 통합할 수도 있을것이다.

13.2.5 Free rider problem(무임 승차 문제)
어떤 특별한 사람에 대해서 치우침이 존재하지 않다 하더라도 시스템의 기능은 균형이 잡혀있지 않을 것이다. 이런것이 문제가 될 수 있다. 특히 shared communication system이 그렇다. 한가지 이슈는 free-rider problem이다. 전자 회의 시스템을 생각을 해보자. 어떤 적절한 토픽에 대해서 많은 토의가 오갔고 그 토론에 대한 기고문을 읽게됨으로서 장점을 얻을 수 있을것이다. 하지만 기고문을 쓰는것을 생각해보자. 그것이 더 이득이 클것이다. 시스템의 총 이득은 각 유저의 코스트보다 크다, 하지만 어떤 틀별한 결정이 밸런스를 망가뜨릴 수 있다. 
서로 다른 상황에서 이런 현상을 보기 위해서 어떤 이상한 자선가를 생각해보자
그 이상한 자선가는 한방에 세명의 낮선사람들을 데리고 왔다 그들은 병의 중심에 돈을 던져 넣는 게임에 초대되고 그들이 그것을 완료했을 때 자선가는 병속에 있는 돈의 두배를 그들에게 주고 그들은 돈을 나눈다. 낮선사람은  "내가 3페니를 집어 넣는다면 6페니를 얻을 수 있고 그것을 나누면 나에게 돌아오는 이익은 2페니일거야' 라고 생각을 할 것이다. 
당연히 아무도 돈을 넣지 못하면 이익은 없을 것이다. 
어떤 회의 시스템에서 소수의 무임 승객은 아무 문제가 되지 않을 수도 있다, 오히려 너무 많은 활동이 위험요소가 될 수도 있다.  게다가 electronic conferences에서 활동과 침묵의 패턴은  전문적 기술같은 다른 팩터들 반영한다. 하지만 무임 승객이 점진적으로 늘어감에 따라서 시스템이 사용되지 않는 방향으로 간다는것은 불보듯 뻔한일이다. 동등하게 시스템을 사용하게 강제하는 것은 라운드 로빈(차례대로 기회를 주는 시스템) 같은 제한적인 모델을 제외하고는 매우 어려운 일이다. 
실세계에서 이런 문제들이 사회적인 압력을 가함으로서 해결이 될수 있다. 무임 승차자들은 어떤 집단 자체가 신임을 받지 못하는 상태가 되면 반응을 한다. 어떤 참가자들의 공헌도의 가시성이 증가함이 이런 사회적 메커니즘을 도와줄 수 있다. 예를 들어서 어떤 활동의 척도를 횟수로 표현을 하는 방법이 있을 수 있다. 

다음은 어떤 과제를 조별로 하는데에 있어서 Free-Rider 문제의 발생시에 해결방법을 제시하는 것이다. 

이번 조모임도 조별로 점수를 부여하는 방식은 예전과 같았지만 조원들간에 기여도 평가가 포함되었다. 즉, 조모임을 마친 후에 각 조원들이 다른 조원들에게 참여도 및 적극성 평가점수를 부여하게 된 것이다.

기여도 평가가 반영된 이후 놀라운 변화가 생겼다. 서로 안하려고 했던 발표를 서로 하려고 하고, 프레젠테이션 자료를 만드는 기술이라든지, 조원들이 조사해온 자료의 질적 수준이 이전에 비해 현저히 개선된 효과가 생긴 것이다. 조원들 사이에서도 예전에는 무임승차하면 더 이득이라는 생각이 지배적이었는데 기여도 평가의 도입이후에는 내가 기여한 부분만큼 평가를 받을 수 있다는 생각에 조모임에 더 열심히 참여하려는 유인(incentive)이 부여된 것처럼 보였다.

이런 인센티브는 우리사회 곳곳에 적용될 수 있는 것처럼 보였다. 사기업체에서는 이미 성과가 높게 나온 직원들에게 보너스를 제공하는 것으로서 기업의 성과를 높일 수 있었다. 이것은 공무원 사회에도 적용할 수 있을 것이다. 비록 정부의 업무영역이 이윤을 따르기 보다는 여러 업무가 복합적으로 융합된 경우가 많아 인센티브의 정확한 적용이 어렵다는 비판도 있다. 그러나 조모임같은 작은 일에서도 유인을 제공하자 훨씬 더 좋은 결과가 나온 것처럼 누구나 공감할 수 있는 인센티브 적용방법을 만들어서 적용한다면 우리사회, 특히 정부업무영역에서도 훨씬 효과적인 국민서비스가 가능할 것이다.


13.2.6 Critical mass

무임 승차자 문제에 관련된 또 다른 문제는 critical mass라는 것이 필요하다는 것이다. critical mass라는것은 바람직한 결과를 효과적으로 얻기 위해 필요한 어떤 양적인 measure이다. 전화기가 공공장소에만 있었을 때는 사람들과의 통신이 제한적으로 이루어졌었다. 하지만 일단 많은 수의 사람들이 전화기를 집에 들여 놓으면 전화기를 설치하는데 돈을 들이는것이 가치있는 일이라고 느끼게 해준다. 비용/이득이라는 측면에서 봤을 때 어떤 시스템에서 초기 사용자가 감수하게 되는 비용은 나중에 전체의 이익으로부터 자신에게 돌아오는 이익보다 클 것이다.  사용자의 수가 critical mass를 넘어서게 된다면  이득이 비용을 dominate, 즉 이득이 비용을 넘어서게 된다. 
회의 시스템이나 이메일 시스템에서 이런 현상이 유사하게 일어난다. 

전화기의 예제나 다른 성공적인 기술에서 얻을 수 있는 교훈이 있다. 전화기는 그것이 모두에게 유용하게 쓰이기 전에는 어떤 소집단(하위집단)에서 매우 유용했다. 비록 인구의 작은 부분의 사람들만이 개인적인 전화기를 가지고 있었지만 그들은 어떤 사회적 그룹에서 중요한 부분을 형성하고 있었다. 그러므로 이런 집단에서의 사용이 시간에 따라 점진적으로 증된 것이다. 
이메일에서도 이런 상황을 발견할 수 있다. 조직에서 2명이나 3명의 그룹만이 이메일 시스템을 효율적으로 이용을 했다. 만약 
조직이 subgroup들의 넓은 원의 형태로 연결이 되어있다고 한다면 비율은 중심에서 넓게 퍼져 나갈 것이다. 물론 널리 퍼지면서 이익이 증가하지만 소수의 그룹만이 이득이 비용을 초과할 것이라고 본다. 명확히 우리는 소수의 유저가 있을 때도 이득을 볼 수 있는 시스템을 설계해야 할 것이다. 

집합행동 및 협력에 있어 선두 주자격으로 참여하는 사람이 감수하게 되는 비용은 나중에 전체의 이익으로부터 자신에게 돌아오는 이익보다 클 것이기 때문에 참여에 망설이게 된다고 본다. 즉 집합행동을 저해하는 요인은 집합행동에 참여해도 그 비용에 비해 자신에게 돌아오는 이익이 적을 것이라고 보는 기대에 있다는 것이다. 처음에 참여하는데 드는 비용과 위험부담이 그만큼 크다는 것이다. 그러나 이미 일정한 조직체계를 갖춘 조직이 있어 집합행동에 참여하게 되는 결정적인 다수가 있다고 한다면 이후 성원들이 집합행동에 참여할 가능성은 높다고 주장하게 된다. 이와 같이 Oliver와 그 동료들은 결정적 다수가 있을 가능성이 높은 조직의 자원이나 체계가 이후 성원들의 참가여부를 결정하는 중요한 요인이 된다고 보고 있다. 그들은 조직이 체계적으로 조직화되어 있고 리더가 있으며 의사결정상에도 서열화되어 있는 관료적이고 공식적 조직이라면 그 조직성원들의 집합행동의 가능성은 매우 높다고 주장하고 있다. 또한 조직이나 집단이 거대하고 이질적 성원들로 구성될수록 집합행동의 가능성 또한 높다는 주장도 하게 된다. 조직이 크거나 구성원들이 이질적인 조직, 집단일수록 자원동원력이 높을 뿐만 아니라 그 조직을 이끌 리더가 나타날 가능성이 높고 결정적 다수가 있게 될 가능성은 높다고 보았기 때문이다. 이와 같이 자원동원론적 조직의 관점에서는 집합협력이 이루어지기 위해 조직의 목표가 구체화되어야 하고, 자원동원의 능력이 있어야 하며, 그 조직이 체계화, 관료화되어야 함을 강조한다. 또한 조직이 크고 이질적 성원으로 구성될수록 집합협력에의 가능성이 높음을 제시한다. 그러한 조직이 전제될 때 합리적 인간은 집합행동으로 인해 전체이외에도 자신의 이익이 있을 것이라 보기 때문에 집합협력에 참여한다는 것이다. 이와 같이 조직론적 시각에서는 집합협력이 선택적 동기화보다는 조직의 성격에 달려있음을 강조하고 있다. 한편 이와 관련하여 조직의 차원의 다른 시각에서는 조직의 체계화나 구조적 성격보다 구성원들의 신뢰감에 주목하는 논의가 있다. 이 입장에서도 사람들은 집합협력이 전체 이익을 가져오고 궁극적으로는 자신에게 이득을 가져올 것이라는 기대 때문에 협력에 참여하게 된다고 본다. 그리고 이는 다수 성원들의 참여가 있을 것이라는 기대하에 각 성원들은 집합협력에 참여하게 된다고도 주장한다. 다른 사람들이 협력하지 않을 것이라는 기대하에 성원들의 자발적 참여는 불가능할 것이라 보는 것이다. 그러나 집합협력이 조직의 구조적 체계에 의해 크게 결정된다고 보지는 않는다. 그 대신 집합협력의 결정요인으로 성원들간의 신뢰감을 강조한다. 다른 사람도 참여할 것이라는 신뢰가 없다면 자발적 참여가 불가능하겠지만 다른 사람도 참여할 것이라는 성원들간에 신뢰가 있다면 구성원들은 전체 이익과 자신의 이익을 위해 집합협력에 적극 참여한다는 것이다. 결국 이 입장에서는 조직성원들간의 상호 신뢰감이 집합협력을 결정하는 가장 중요한 요인이 됨을 강조하고 있다. 또한 보다 최근에는 조직내 성원들의 연결망이나 유대감에 주목하는 논의도 제기된다. 이는 성원간의 접촉빈도나 유대, 단결감, 소속감이 높을수록 성원들의 집합협력의 노력과 행동이 가능하다고 보는 것이다. 이 입장은 다른 자원보다도 성원들간의 연결망과 결속력이 집합행동에 중요한 자원이 됨을 강조한다. 성원들간의 연결망이 강할수록 집합협력의 성공으로 공동의 이익이 창출될 수 있다고 성원들은 믿기 때문에 집합협력에 참여한다는 것이다. 즉 조직유대나 연결망, 멤버십이 강할 경우 상호 신뢰감이 형성되며 신뢰감에 기반한 집합협력으로 무임승차의 문제를 해결할 수 있다고 본다.

13.2.8 Evaluating the benefit 
우리는 지금까지 어떤 정보 시스템과 조직적이고 사회적인 요소의 미스매치로 인해서 발생하는 여러 문제를 살펴 보았다. 우리가 어떤 시스템을 가지고 있다고 생각해 보자. 그리고 시스템은 어떤 경계로 떨어져 있지 않다 모두가 행복하고 어떤 억울함도 없다. 하지만 시스템을 사고 설치하는데 드는 비용이 많다고 하자. 이것이 과연 가치가 있는 일인가?
그 문제에 답하는 것은 거의 불가능하다. 어떤 협동적인 시스템으로 부터 얻을 수 있는 이득은 특히 조직 전반에 걸쳐서 이용이 될 수 있는 이메일, 전자 회의 시스템 같은 경우에는 작업만족도나 유동적인 정보의 흐름에서의 측면에서 볼 수 있다. video wall같은 몇몇 시스템은 조직내에서 사회적인 관계를 증진시키는데 이용이 될것이다. 작업에 대한 만족도를 어떤 설문지를 이용해서 조사하는것도 가능할 것이다. 하지만 경제적인 이득의 경우 매우 분산되어있는 형태이기 때문에 측정하기가 어렵다.
 
하지만 전반적인 컴퓨터 사용에서도 유사한 주장이 제기가 될 수 있다. 여기서 이득은 수량화 하기에 어렵지만 시간이 흐르면서 정보 기술의 경쟁력이 현대 시대에서 살아가는데 매우 중요한 요소가 되고 있는것은 명확하다. 아마 수년 내로 협동적인 시스템에 대해서 같은 이야기가 나올 것이다.


13.3 CAPTURING REQUIREMENTS
우리가 앞에서 봐왔듯이 어떤 시스템을 도입할 때 생기는 문제는 그것에 의해 영향을 받는 모든 사람들이 이해를 하지못하는 경우가 생길 때 발생한다. 하지만 어떻게 복잡한 조직 구조, 작업그룹, 잠재적으로 대립하는 stakeholder의 요구등을 이해하고지원을 더 잘할 수 있을까? 우리는 어떤 요구사항을 포착하고 분석할 것이다. 하지만 우리는 어떤 작업 상황안에서 이런 일이 가능할 것이고 여러가지 복합적인 서로 다른 스테이크 홀더들이나, 조직들, 작업 그룹에서 프로세스가 진행되면서의 여러가지 관심사들을 고려해야 할 것이다. 
이번 섹션에서 우리는 여러가지 접근 방법을 고려해볼것이다 : socio-technical modeling, soft system methodology, participatory design(참여 디자인), ethnograpghic method, contextual inquiry(맥락 연구) 들을 알아보자.

모든것이 작업 환경의 현실과 서로 다른 스테이크홀더의 관점(요구사항)을 이해하는데 도움을 주기위해서 만들어 졌다. 
이 모든 기법들은 사용환경에 대한 적절한 이해가 전제 되었을 때 기술이 절적하게 분배가 된다고 생각한다. 하지만 각 접근방법들은  대해 문제에 접근하는 방식이 약간 다를 수 있다. 물론 이들기술을 이해하기 위해서는 스테이크홀더가 무엇인지 알아야 한다.

13.3.1 Who are the stakeholders?(스테이크 홀더가 누구인가?)
스테이크 홀더를 이해하는것은 요구사항을 포착하는 여러 접근방법에 있어서 키가 된다. 그렇기 때문에 어떤 조직적인 환경에서 그들은 단순한 엔드유저가 아닌 새로운 기술의 도입에 영향을 받는다. 어떤 새로운 가스 충전소에서 새로운 결제 시스템을 도입했다고 하자. 이 새로운 지불시스템의 도입으로 영향을 받는 사람은 누구인가? 명백히 청구서를 만들고 보내는 사람일 것이다.- 그들은 시스템을 직접적으로 사용하는 사람이다. 그러나 어디서 청구서를 생산하는 정보를 얻을 수 있을 것인가? 그들이 청구서를 누구에게 보내는것인가? 누가 요금의 정도를 매기고 어떤 이유에서 그렇게 하는가? 총수입이 증가함에 따라 누가 이득을 보는가? 고객에 다른 더 좋은 서비스를 선택한다면 누가 타격을 받는가? 미터 검침원, 고객, 관리자, 단속 담당자, 주주,다른 경쟁사등 이모든 사람, 것들이 다 스테이크홀더가 된다. 우리는 그들 서로서로에게 상반되고 복잡한 그들의 관심사들을 포착하는 그런 접근방법이 필요하다. 

Primary stakeholder는 실제로 시스템을 사용하는 유저를 이야기한다 즉! end user이다.
Secondary stakeholder는 시스템을 직접적으로 사용하지는 않는다. 하지만 시스템으로의 산출물을 받거나, 혹은 시스템에 대한 input을 제공하는 형태의 스테이크홀더이다. (예를 들어서 시스템에 의해 생산되는 레포트를 받는 누군가)

Tertiary stakeholder는 시스템의 성공과 실패에 직접적으로 영향을 받는 사람들을 이야기 한다.(예를 들어서 어떤 시스템이 성공하느냐에 따라서 이득이 늘거나 줄거나하는 감독자 같은 사람들)

Facilitating stakeholder는 설계에 참여하는 사람들을 이야기한다. 주로 시스템에 개발과 유지를 담당한다.


비행기 예약 시스템에서 스테이크 홀더를 분류해 보도록하자.
오떤 항공사가 새로운 예약시스템의 도입을 고려하고 있다. 이 새로운 시스템은 여행사를 통해서 항공편을 예약할 수 있는 시스템이다. 스테이크홀더는 아래와 같이 분류될 수 있다. 

Primary stakeholder는 여행사 스태프, 공항 예약 스태프
Secondary stakeholder 고객, 공항 경영진
Tertiary stakeholders : 경쟁사, 민간항공국, 고객의 여행 동료들, 공항 주주 
Facilitating stakeholders : design team, IT department staff


위의 예에서 디자인팀의 목표는 가능한한 많이 스테이크홀더의 요구사항을 충족시키는것이다. 하지만 실제로 일반적인 스테이크홀더의 요구사항은 서로 대립된다. 때때로 이런 것들이 문제가 되지 않을 수 있다: 회사에서 새로운 시스템을 도입하게 되면서 자신의 이점을 유지하기 위한 경쟁사의 요구사항을 고려할 가능성이 별로 없다.(그들이 그들의 이점을 어떻게 유지시키는지에 대해서 확실하게 모니터할 필요성이 있다) 하지만 때때로 이것은 문제가 될 수도 있다. 위에 있는 예제에서 항공사 예약 시스템은 여행사 입장에는 매우 유용할 것이다. 하지만 고객이 적절한 티켓을 올바른 장소에서 찾을수 있도록 해야할 것이다. 고객이 올바른 장소에서 티켓을 받지 못해서 업무에 지장을 받게되면 전체 시스템이 실패한거와 마찬가지이다. 

일반적인 룰로 스테이크홀더의 우선순위를 지정할 수 있다.

primary stakeholder는 다른 스테이크홀더에 비해서 높은 우선순위를 가진다. 하지만 항상 그렇지는 않다. 일례로 병원의 생명유지장치의 컨트롤패널을 설계하는 것을 생각해보자. primary stakeholder는 환자의 상태를 모니터하는 병원 스태프가 될 것이다. 하지만 사실, 누가 이 시스템에 대해서 가장 주된 관심사는 누구인가? 물론 환자이다. 그의 생명은 이 생명유지 시스템의 성공여부에 달려있다. 이런 경우  tertiary stakeholder가 매우 중요할 것이다. 우선순위가 가장 높다는 이야기가 될 것이다.
모든 접근방법이 그들의 조직적인 상황내에서 스테크홀더를 이해하는것에 관심을 두고 있다.

13.3.2 Socio-technical models
20세기 초반에 근로(작업)에 대한 연구는 인간이 기술혁신에 어떻게 적응할것인가? 하는 것이 었다. 기술결정론은 사회적 변화는 주로 기술에 의해서 좌지우지가 된다고 보는 결정론이다. 그리고 일반적으로 인간과 사회적 팩터는 두번째 관심사가 된다. socio-technical system 관점은 이 기술중심적인 관점을 반박한다. 이것은 근로 시스템이 인간과 기계 이 두가지의 요소로 이루어져 있다는것을 강조하고 이들의 상호 관계(인간과 기계)가 중심이 되어야 한다고 주장한다.
상호작용 시스템을 위한 Socio-technical model은 기술적, 사회적, 조직적이고 설계의 인간적인 측면을 고려한다. 그들은 기술이 고립된채로 개발되지 않고 넓은 조직적 환경의 일부분이라는 사실을 인지한다. 사회적이고 기술적인 이슈들을 함께 고려해야한다는 것이 중요하고 그렇게 되므로 인간적인 이유가 기술적인 것에 의해서 무시되지 않을 것이다. 
socio-technical approach의 key focus는 어떤 특정 기술의 도입의 영향을 서술하고 문서화(기록)하는 것이다. 방법은 다양하지만다음과 같은 특정 요소들을 포착하는 시도를 한다.

- 문제에 대해서 논의 되어야 한다: 기술이 제안된 이유와 어떤 문제를 풀어야하는가에 대해서 이해해야할 필요가 있다.
- 영향을 받는 스테이크홀더들 -> primary, secondary, tertiary와 facilitating 스테이크홀더들을 그들의 목적, 목표, task와 함께 포착해야 한다.
- 조직내에 formal, informal한 워크그룹
- 지지되는 변화
- 제안된 기술과 어떻게 그것이 조직내에서 동작하는가?
- 외부 제약조건과 영향을 미치는 요소 그리고 성능측정 요소

정보는 인터뷰나, observation, focus groups, 문서 분석 등을 이용해서 모을 수 있다. 이들 이슈들을 이해하려고 시도하는것으로 socio-technical approach은 기술의 역활과 성공적으로 이용하는데 필요한 요구조건들을 상세하게 알 수 있다. 
우리는 2가지 접근방법을 알아볼 것이다.

CUSTOM methodology 
CUSTOM은 작은 조직단위에서 실용될 수 있도록 디자인 된 socio-technical methodology이다. 이것은 User Skills and Task Match(USTM)에 기반한 방법으로 디자인 팀이 유저의 요구사항을 이해하고 기록하게 한다. CUSTOM은 스테이크홀더의 요구사항을 밝히는데 초점을 맞춘다:엔드유저 뿐만아니라 모든 스테이크홀더가 고려된다. 
이 방법은 주로 제품기회를 알아냈을 때 설계 초기단계에 적용이 된다. 그러므로 주안점은 요구사항을 포착하는데 있다. 이 방법은 어떤 질문 셋을 제공하는 forms-based methodology이다. 다음은 CUSTOM analysis를 수행하는 6개의 key stage이다. 

1. 어떤 조직의 주된 목표와, 물리적인 특징, 정치적, 경제적 백그라운드를 포함한 조직적인 상황을 서술한다.

2. 스테이크홀더를 파악하고 서술한다. 모든 스테홀더에게 이름을 부여하고, 카테고리화 한다.(primary, secondary, tertiary or facilitating 같이) 그리고 개인적인 이슈와 조직내에서 막은 역활 그리고 그들에 임무와 관련해서 이야기를 한다. 예를 들어서 CUSTOM은 스테이크홀더의 조직내에서 의욕을 유발하거나 저하하는 요소(motivation and disincentive), 지식, 기술, 권력, 영향력, 매일하는 작업등등의 이슈들에 대해서 다룬다.

3. 작업그룹을 파악하고 서술한다. 작업그룹은 형식적으로 구성이 되어 있든 아니든, 어떤 한작업에 대해서 함께 일을하는 어떤 사람들의 그룹이 될것이다. 또한 작업그룹은 조직내에서의 그들의 역활과 그들의 특징에 대해서 이야기 될 것이다. 

4. task-object pair를 알아내고 서술한다. 수행되어야 하는 작업이 있고 그것을 수행하는데 연관되는(작업을 수행하는데에 이용 되거나 오브젝트에 적용이 되거나 하는) 어떤 오브젝트가 있을 것이다.  

5. 스테이크홀더의 필요사항을 파악해야 한다. 2~4는 현재 시스템의 측면과 제안된 시스템의 측면을 둘다 이야기해야 한다. 스테이크홀더의 요구사항은 이 두가지 사이의차이를 고려함으로서 알아낼 수 있다. 예를 한번 들어보면, 만약 스테이크홀더가 현재 특별한 기술이 부족하고 제안된 시스템에 이 기술이 필요하다고 파악이 되면 이것은 그 기술에 대한 훈련의 필요사항이 파악된 것이다. 

6. 스테이크홀더의 요수사항들을 통합하고 체크한다. 스테이크홀더의 필요사항 리스트가 먼저의 스테이지에서 결정된 기준에 의해서 체크가 된다. 

2~4단계는 현재 상황과 제안된 상황의 측면에서 이야기를 해야될 문제이다. 스테이크홀더의 현재 맡은바와 위치 뿐만 아니라 변화가 그들에게 가져올 앞으로으의 전망에 대해서도 정보를 얻어야 한다. 이런 방법으로 스테이크홀더의 관심사와 목표가 정립이 된다. 더해서 작업관행에 대한 기술의 영향이 고려될 수 있다.(3단계) 그리고 시스템이 상세화되면서 변화 지지될수 있다.(4단계) 
현재 위치에서 제안된 위치로의 변화는 시스템의 성공적인 사용(배치)를 위해서 논의되어져야할 필요성이 있는 이슈들을 나타낸다. 그리고 이들은 5~6스테이지에 명시가 되어 있다. 
CUSTOM은 스테이크홀더의 요구사항을 고려하는데 유용한 프레임워크를 제공한다. 그리고 이러한 형식과 질문을 이용하는것은 상대적으로 매우 직관적이다. 만약 일반적인 CUSTOM의 진행사항 시간이 많이 걸린다면  덜 복잡한 상황에서  아래와 같은 CUSTOM stakeholder analysis의 간소화 버젼 역시 이용 가능하다.  
이번에는 CUSTOM stakeholder analysis의 간소화 버젼을 한번 살펴보도록하자.
CUSTOM question들은 다음과 같이 다양한 스테이크홀더의 특징을 조사하는 것이다.

- 스테이크홀더가 성취해야할 것은 무엇이고 어떻게 성공의 척도를 판단할 것인가?
- 스테이크홀더의 작업만족도를 판단하는것은 무엇인가? 불만족과 스트레스는 어디에서 오는가?
- 스테이크홀더가 가진 지식과 기술은 무엇이 있는가?
- 작업과 컴퓨터 기술에 대한 스테이크홀더의 사고방식(자세)는 어떤가?
- 스테이크홀더가 생산품을 받아들이는데 영향을 미치는 작업 그룹 속성은 어떤것이 있을까?
- 빈도, 단편화, 행동의 선택적인 측면에서 스테이크홀더의 작업의 특성은 무엇이 있는가?
- 스테이크홀더가 작업하는데에 있어서 물리적조건에는 무엇이 있는가? 

Open System Task Analysis (OSTA)
OSTA는 socio-technical approach의 대안이 되는것이다. 이것은 조직적인 작업 환경에 기술적인 시스템이 도입 되었을때 어떤 일이 발생하는지에 대해서 서술하기를 시도하는 방법이다. CUSTOM과 같이 OSTA는 시스템의 사회적이고 기술적인 측면 둘다를 고려한다. 하지만 CUSTOM이 스테이크홀더의 관점에서 구성이 되어있다면 OSTA는 작업(task)에 초점을 맞추어서 진행을 한다. 

OSTA에는 총 8단계가 있습니다.

1. 기술이 지원해야만 하는 primary task가 파악되어야 한다. 이것은 유저의 목표의 측면에서 이루어 져야 한다.
2. 시스템에 입력이 되는 작업(task)가 파악되어야 한다. 이들은 서로다른 소스와 형태를 가지고 설계에 제약조건이 될 수 있다.
3. 물리적, 경제적, 정치적 측면에서 시스템이 도입 되는데에 외부 환경이 서술되어야 한다.
4. 시스템 내부에 대한 변화(탈바꿈)가 어떤 행동이 오브젝트에 대해서 수행되거나 오브젝트와 함께 수행되는 측면에서 설명이 되어야한다. 
5. 존재하는 작업그룹과 조직 내외부의 관계를 고려한 사회적 시스템이 분석되어야한다. 
6. 기술적인 시스템이 다른시스템과의 구성과 통합의 측면에서 이야기되어야 한다.
7. 성능 만족도의 기준이 시스템의 사회적이고 시스템의 사회적이고 기술적 요구사항을 나타낼 수 있도록 정립되어야 한다.
8. 새로운 기술적인 시스템이 구체화 되어야 한다. 

OSTA는 설계자에게 친숙한 데이터 플로우 다이아그램이라든지 textual description이라든지 하는 노테이션을 사용한다.

 
13.3.3 Soft system methodology
앞에서 봤던 socio-technical model들은 인간적이고 기술적인 측면에서의 요구사항을 다 고려하긴 했지만 그들은 어떤 기술적인 솔루션이 이미 제안된 상태라고 가정을 했다. Soft systems methodology(SSM)도 역시 전통적인 기법이긴 하나 어떤 기술과 사람들이 구성요소로 되어 있는 시스템으로서의 조직에 대한 관점을 가지고 있다. SSM솔루션에는 어떤 특정한 솔루션이 존재하지 않는다: 차라리 어떤 상황에 대해서 완전하게 이해하는것에 초점을 맞추고 있다. SSM은 Checkland라는 사람에 의해서 개발이 되었는데 고려중인 시스템 내부에 존재하는 기술개발의 상황과 영향력과 관심사을 설계자들에게 이해할 수 있게 도와주는 목적에서 만들어졌다. SSM은 아래 와 같이 7개의 Stage가 존재한다. real-world stage(1~2, 5~7)와 system stage(3~4) 사이의 차이가 존재한다. 

우리는 이 기법이 요구사항을 포착하는데 도움을 준다는 것에 초점을 맞출것이다. SSM의 첫번째 스테이지는 문제의 인식과 분석의 시작이다. 이것은 문제의 상황의 상세한 설명에 잇다를 것이다 : rich picture를 개발해야 한다. 이것은 모든 스테이크홀더를 포함할 것이다. 그들이 수행하는 작업(task) 그리고 그들이 일을하는 그룹, 조직적 구조와 그것의 프로세스(과정) 그리고 각 스테이크홀더간에 일어나는 이슈가 있을 것이다. 어떤 지식을 이끌어내는 기술은 정보를 얻는데에 이용되어 rich picture를 만들 수 있다. 정보를 얻는 방법으로는 observation(오디오, 비디오 레코딩), 인터뷰나 설문지, 롤플레이나 시뮬레이션 그리고 critical incident analysis같은 통합 워크샵을 통해서 할 수 있다. 일반적으로  덜 구조화된 접근 방법은 처음에 인위적으로 설명을 억제하는것을 피한다. rich picture는 어떤 스타일에서도 가능하다 - 어떤것이 맞다 틀리다의 대답이 없다 - 하지만 설계자에 있어서는 그것이 매우 명확하고 정보를 줄수 있어야 한다. 하지만 특정 형식이 넓게 이용되어다. 스피치 밸룬은 스테이크홀더의 이슈들을 나타내는데 이용하나; 교차된 칼은 시스템 내부에 대립되는것을 나타낸다; 눈표시는 외부의 영향(력)이나 관찰(감시, 주시)를 나타낸다. 13.3에는 이런 구성요소들을 이용해서 rich picture를 나타낸 것이다.
rich picture는 본래가 상황을 이해하는데 있어서 도움을 주는 유용한 툴이된다. rich picture는 형식이 업고 상대적으로 이해하기 쉬운 수단이다. 이것은 간결하게 여러 스테이크홀더의 대립되는 관심사와 설계 상황에서의 다른 영향력을 포착할 수 있다.
설계의 이해의 이해가능한 요약을 제공하고 이것은 스테이크홀더를 쉽게 체크할 수 있다. 그리고 rich picture는 어떤 협의 과정에서의 부분으로서 스테이크홀더들과 협력적으로 개발될 수 있다 

SSM의 다음 단계에서 우리는 real world로 부터 system world로 움직인다 그리고 시스템에 대해서 root definition을 생성하는것을 시도한다. 이 root definition은 시스템이 어떤것에 대한것인가에 대한 본질을 정의 한다. 예를 들어서 한 시스템에 서로 다른 스테이크홀더의 관점을 나타내는 여러 root definition이 존재할 것이다. Root definition은 어떤 특정 element의 측면에서 설명이 되어진다. 이 root definition을 표현하기 위해서 CATWOE라는 acronym(두문자어)를 이용한다. 

Clients - 시스템으로 부터 산출물이나 이익을 받는 이
Actors - 시스템 내에서 어떤 행동을 수행하는 이
Transformations - 시스템에 의해 영향을 받는 변화. 이것은 root definition에서 매우 중요한 부분을 차지한다. 다음단계에서 포함되는 어떤 행동들을 이끌게 된다. 어떤 변화된 인풋을 통해서 요구되는 아웃풋이 나올 것이다. 
Weltanschauung - 독일어로 세계관이라는 뜻이다. 어떤 특정 root definition에서 시스템을 인지하는 방법이다. what point of view makes this system meaningful(의미 있는 중요한) ? 즉 어떤 점이 이시스템을 의미있게 하는가? 
Owner - 시스템을 소유하는 이다. 시스템에 대해서 책을 저야하는 사람이며 시스템을 변화시킬 수 있는 권한을 가진 사람이다.
Environment - 시스템이 구동되는 어떤 환경이며 그런 환경에 의해 시스템은 영향을 받는다.

앞서서 예로 들었던 새로운 항공사 예약 시스템에 대한 root definition을 알아보자
알다시피 국제 항공사가 새로운 예약시스템을 도입하는것을 고려하는 중이고 이 새로운 시스템은 여행사와 협력해서 여행사가 바로 항권권을 살수있도록 하게 했다. 

다음은 시스템에 관련된 내용이다.

즉 시스템은 항공사 경영진이 소유하고 있는것이다;
시스템을 구동(operate)하는 사람은 협력 여행사 스태프들이고; 
시스템은 전세계적인 협력 여행사 사무실에서 동작한다;
International Civil Aviation authorities(국제 민간 항공 기구)와 national contract legislation(국제 계약 제정법) 의해서 제정된 규제내에서 시스템이 동작하고; 
시스템은 고객을 위해서 자리를 예약하고 항권권을 판다;
시스템은 회사를 위해서 이익을 창출한다. 

이를 바탕을 root definition을 지정해보자

Client : customer
Actor : travel agency staff
Transformation : 비행기 좌석 판매와 조직의 수익의 변형에 따른 고객의 여행에 대한 목적과 요구사항의 변화 
Weltanschauung(Worldwide) : 효육적인 판매방식에 의해서 얻는 수익이 좀 더 좋아진다. 
Owner : 항공사 경영진
Environment : International Civil Aviation authorities(국제 민간 항공 기구)와 national contract legislation(국제 계약 제정법) 의해서 제정된 규제

한번 root definition이 정의가 되면, 개념적인(conceptual) 모델이 고안이 된다. 개념적인 모델은 root definition에 따라 수행하기 위해서 시스템이 해야할 일을 정의한다. 그것은 시스템에서의 변형과 행동을 파악하고 그들중 무엇이 성취되고 어떻게 성취가 되었느냐의 측면에서 계층적으로 모델링된다. 이 과정이 반복적으로 진행되고 완벽하고 정확할때까지 몇번의 사이클이 걸릴것이다. 

다음에 우리는 시스템에 대한 디스크립션을 들고 다시 real world로 돌아가서 개념적인 모델과 실제 시스템을 비교한다, 차이점을 파악하고 그렇게 함으로써 필요한 변화라든지 잠재적인 문제들에 대해서 알아볼 수 있다. 예를 들어서 어떤 특별한 행동은 실세계에서 개념적모델보다 더많은 프로세스를 가질 수 있다. 그렇다면 비교의 과정을 통해서 그 특정 행동(activity)의 프로세스수를 줄이는것을 제안할 수 있다. 

마지막 스테이지에서 우리는 어떤 시스템 전체적으로 어떤 변화가 필요하며 또한 이득을 볼 수 있는가에 대해서 결정을 해야한다. -예를 들어서 변화는 구조적으로 이루어 질것이고, 절차적이나 사회적이다.- 이런 변화에 영향을 주는 행동들을 결정한다.

SSM은 유연한 접근 방법이다. 이것은 설계 상황에서 상세한 고려사항을 지원해준다. 하지만 이 방법을 유용하게 쓰기위해서는 연습이 필요하다. 맞는 답이 하나인 것이 없다.- SSM은 더 넓은 규모의 시스템의 이해를 돕는데 이용한다면 성공적으로 이용할 수 있다. 

succinctly 간단명료한, 간결한
in themselves 본래
intuitive 이해하기 쉬운, 직관력이 있는, 직감적인
consultation 협의, 상의, 회담, 상담, 진찰, 참고, 참조
weltanschauung 세계관
answerable 설명을 해야하는, 책임을 져야하는 
devise 창안하다, 고안하다 
discrepancy 차이점
thereby 그렇게 함으로써  

13.3.4 Participatory design(참여 설계)
Participatory design은 전체의 설계 사이클을 포함(망라하는, 아우르는) 철학이다. 이것은 작업현장에서의 설계이고 작업현장에서 사용자(유저)는 어떤 실험적 참가자나 필요할때 참고인이 될 수 있을 뿐만 아니라 디자인 팀의 멤버가 될 수 있다. 
유저는 그러므로 디자인 프로세스에서 설계자가 전적으로 시키는 대로만 하는 수동적인 실험참가자가 아닌 협력자로 행동을 하게 될것이다. 이 방법에서 주장하는것은 어떤 작업 상황에서 유저들이 전문가가 되고 그 작업상황에서의 설계는 이들 전문가들이 설계 프로세스에 적극적으로 기여하는것이 허락될 때만이 효율적으로 행해질 수 있다. 게다가 어떤 새로운 시스템의 도입은 작업 상황이나 조직적인 프로세스가 변하기 쉽다. 그리고 이런 변화가 유저들에게 받아들여져야지만이 새로운 시스템이 수락될 수 있는것이다. 그러므로 이 Participatory design은 유저가 설계 프로세스에 활발하게 참여를 해서 시스템의 요구사항을 반복적으로 개선해나가는데  목표를 둔다.
Participatory design은 3개의 구체적인 특징이 있다. 첫번째는 작업 환경과 설계의 시작에 따른 작업자체를 개선하기 위해서 노력한다. 이것이 설계를 만들고 어떤 시스템에 기반을 한것보다, 상황이나 작업에 기반을 두고 평가를 한다. 
두번째로 협동의 특징이다 : 유저가 설계팀에 포함이 되고 설계에 모든 단계에 기여를 한다. 
마지막특징은 이 접근방법은 반복적이라는 것이다:설계(design)는 각 단계에서 평가와 개선이 반복적으로 행해진다.
Participatory design 프로세스는 유저와 설계자 사이에 정보를 전달하기 위해서 여러가지 방법을 이용한다. 다음과 같다.

Brainstorming 
이것은 설계 정보를 모으는데서 모든 실험 참가자들을 홈함한다. 이것은 형식이 없고 상대적으로 덜 구조적이다. 브레인스토밍은 그들이 생각한 아이디어를 그때그때 이야기하는 형식으로 진행이 된다. 모든 정보는 어떤 판단기준이 없이 받아들여진다. 이런 진행과정에서 다양한 아이디어를 제공할 수 있고 다른 테크닉을 통해서 걸러질 수 있다.

Storyboarding 
스토리보드는 유저의 매일매일의 활동에 대해서 설명할 뿐만아니라 잠재적인 설계와 그들이 가지는 영향에 대해서 설명이 가능한 수단이 된다.

Workshop
워크샵은 유저와 설계자간의 누락된 지식을 채우고 좀 더 집중된 설계에 대한 관점을 제공한다. 워크샵은 설계자와 참여자 각각의 관점에서 디자인에 사황에 대한 이해하기 위해서 서로 문의를 하는 형식을 같는다. 설게자는 유저에게 작업환경에 대해 질문할 수 있다. 그리고 유저는 설계자에게 기술과 가용한 능력에 대해서 물어볼 수 있다. 이것은 유저와 설계자 사이에 공통되는 기반을 다지는것이 되고 앞으로 만들어질 시스템에 대한 설계의 토대를 마련하는 것이된다. 롤플레이를 하는 것은 유저와 설계자 사이에서 잠시 역활을 바꿔볼 수 있는 기회가 된다.

Pencil and paper exercises 
이것은 설계에서 어떤 자원에 관해서 이야기 하고 평가해볼 수 있게한다. 유저는 시스템 디자인의 종이 목업을 이용해서 일상적인 task에대해서 자세하게 알아볼수 있다. 이것은 유저의 요구사항과 제안된 실제 설계사이에 차이를 나타내려 하는것이다. 이런 활동은 어떤 모델을 평가하는데 있어서 매우 간단하고 저렴한 기술을 제공하는 것이다. 

mock up 실제크기의 모형을 만들다.
commitment 약속, 헌신, 책무, 투입
philosophy 철학
encompass 포함하다, 망라하다, 아우르다
consult 상담하다, 상의하다, 찾아보다, 참고하다 
passive 수동적인 
liable to do ~하기 쉬운
refine 정제하다, 개선하다 
convey 전달하다, 실어나르다 
on the fly 대충 그때 그때 봐가며 
enquiry 조사, 문의
commitment 약속, 전념, 헌신 
exclusively 베타적으로 

13.3.5 Ethnographic methods
지금까지 살펴봤던 모든 접근 방법은 스테이크홀더에 대해서 그들의 요구사항을 찾고 협의를 하는 몇몇 단계가 포함되었다. 하지만 이 Enthnographic은 스테이크홀더의 실제 업무같은 것이 아닌 관점에 대한 정보를 모으는데 초점을 둔다. Enthnographic은 업무를 이해하기 위해서는 어떤 작업 상황속에서 연구를 해야한다고 주장한다. 

사회학의 여러분야와 인류학은 오랜시간에 걸쳐서 어떤 사람의 사회적이고 문화적인 상황을 배제하고는 사람에 대해서 연구할 수 없다고 한다. 특히 ethnography가 영향력이 있기위해서는 그룹시스템 자체에 대한 연구를 해야한다. 

Ethnography는 사람과 사람과 환경사이에서 상호장용의 매우 상세한 기록을 기반으로 한다. 사회적관계에 특별히 초점을 맞추고 그 관계가 업무의 특성에 어떤 영향을 미치는지 알아본다. ethnography를 수행하는 사람은 어떤 상황에 활발하게 들어가지 않으며 어떤 특별한 사람의 관점을 보지 않습니다, 그러나 문화화가 되는 것이 목표고 그것의 문화적인 프레임워크로 부터의 상황을 이해해야 합니다. 여기에서 문화가 뜻하는것은 어떤 특별한 작업 그룹이나 조직에서의 문화를 이야기하는 것이다. 그것은 사회전체적인 문화가 아니다. Enthnographer들은 상황에 대해서 편견없고 제한을 두지 않은 시각을 가져야 한다. 그들은 있는 그대로 보고하되 추측을 해선 안된다. 그러므로 때떄로 새로운 시스템에 대해서 얼마나 이 접근 방법이 공헌을 했는가가 불명확할때가 있다.  

unbiased 선입견 없는 
nature of work 업무의 특성 
speculate 추측하다
Posted by 태씽
CSE(컴퓨터 공학)2010. 4. 14. 18:25
유저가 그룹단위일때 어떻게 할것인가?

지금까지 우리는 single-user system에서의 실험을 어떻게 하는가에 대해서 알아보았다. group system의 단위에서 실험을 evaluation 하기 위한 실험은 추가적인 문제를 야기시킨다. 인간 끼리의 의사소통과 group working의 복잡성이 주어졌을 때, single-user system보다 어렵고 복잡한 것은 놀라운 일이 아니다. 토론의 목적으로 실험 참가자들 사이에서 video connection을하는 application을 evaluate한다고 해보자. 그리고 몇몇 가지 문제들에 직면할 것이다.

The participant groups 
10번의 실험을 하는 single-user system은 10명의 실험 참가자가 필요하다. 3개의 그룹이 포함되는 실험에서는 30명의 참가자가 필요할 것이다. 게다가 group working 내에 실험은 single-user 실험보다 길다. 그 이유 중하나가 될 수 있는게 바로 settle-down이라는 것이 있는데, 이것의 실험의 결과가 안정되는것을 이야기 한다. 이 시간이 소요 되므로 길 수 있고  실험 참가자들에게 지장을 주고 이것이 비용이 더 많이 들게 하는 요소가 된다. 

참가자와 시스템간의 일정을 맞추는데에도 어려움이 생기게 된다. 실험에 사용 되는 워크스테이션이 동료의 개인적인 시스템이어서 우리는 적어도 6명의 사람을 포함 시킬려고 시도 했다. 실험자들에게 언급하지 않았다. 
많은 group working에 대한 report들이 3개 또는 4개의 그룹만을 포함한것은 놀라운일이 아니다 이것은 명백히 통계적인 측면으로 봤을때는 문제가 있지만 주된 장애가 되지는 않는다. 

The experimental task
알맞는 task을 선택하는것 역시 어렵다. 우리는 여러 종류의 task을 테스트하기를 원했다 : creative, structuredm information passing등등. 물론 task은 협력을 장려해야한다. 상호 합의가 필요한 task이거나 정보나 control이 실험 참가자들 사이에 분배가 되기 때문이다. 또한 명백하게 tassk는 groupware system의 속성에 의존한다 : 가능한 채널이 여러가지라면, 우리는 넓게(될 수 있으면 다 쓸 수 있게)장려받는다. 예를 들어서 가정한 video application의 경우에는 application을 사용하지 않고는 task의 수행이 불가능할 수 밖에 없다. 사용한다면 video conferencing에 대한 조사가 한결 수월 해 진다.
 
creative task는 '~에 대해짧은 레포트를 쓴다' 혹은 '~에 관한 연구 제안서를 작성한다'와 같을 수 있다. 때때로 이것이 매우 효과적인데, 예에서 실험 참가자들이 합의에 도달해야만하는 경우 공유 application을 이용한 final report를 쓰라고 요청할 수 있다.

Design task들 역시 사용된다. 어떤 디자인에 대해서 변경 요청같은것에 이용이 될 수 있다.
Decision game은 협동적인 활동을 테스트하고 훈련하기 위해서 만들어진것이다. Decision game은 개인의 활동이 아닌 그룹 협동에 성공이 좌지우지가 된다. 예를 들어서 사막 서바이벌 task에서, 참가자들이 사막에서 곤경에 처했다고 하자. 그들은 그들이 가진 아이템을 그들의 생존에 도움이 되는 순서대로 순위를 매길것이다: 칼, 플라스틱 시트 등등.. 참가자들은 이 아이템들 중에서 하나의 리스트를 만들어야한다, 참가자들이 혼자서 그일을 진행 할 순 없다. 

time-critical simulated process control task는 실험 참가자들이 모델의 다른 파트들을 제어함으로 더 높은 페이스의 상호작용을 가능하게 하는것이다. 


Data gathering 
single-user 실험에서도 우리는 여러대의 비디오 카메라에 application의 직접적인 로깅까지 이용을 할 수 있다. 그룹의 세팅의 경우에는 single-user의 경우를 각각의 실험 참가자들에게 그대로 적용하면 된다. 우리는 6개이상의 비디오 소스와 3개의 keystroke log를 동기화를 시킬려고 해봤다. 합성하는데에 문제는 각각 어떤 실험이나 장소에 따라 달라질 것이다. 기술적인 문제가 큰것은 당연하다. -> 4-into-1 비디오 레코딩은 가능하고 화면의 각 4분면에서 다른 이미지를 저장을 하지만 우리가 바라는 채널 수에서 부족했다. 

실험 참가자들의 개인적인것에 집중했을 때 녹화 각 참가자마다 이루어 지고 비디오 이미지나 사운드는 각 시스템의 부분으로 중계가되었다.(video connection이 있다고 가정을 했다.) 이들은 특별한 실험참가자들의 keystroke과 추가적인 video 탐색과 함께 동기화가 되었다. 그러므로 우리는 이런 상황을 재창조를 할수 있다. 

충분한 레코딩 장비가 주어졌으면 이것은 각 참가들에게 반복이 될수있다.  행복하게도 각 참가자들의 동기화의 레벨은 중요하지 않다. 중요한것은 각 개인의 동리화 레벨이 될것이다. 

=> 보니까 각각의 실험 참가자들 사이의 동기화는 걱정할 것이 안되고 각 개인의 동기화(비디오, 소리, log->keystroke등)이 매우 중요한 요소가 된다는것이 핵심이다.

Analysis 
실제 실험을 따라 우리는 실험 조건사이에서의 차이를 통계적으로 분석해보려고 한다. 우리는 이전에 single-user experimental에서는 개인적인 차이가 문제를 발생시킬 수 있다고 했는데 그룹 에서는 variation이 더욱 극단적이다. 무작위로 혼합된 그룹에서, 어떤 그룹은 민주적 성향이 나타나고; 다른 곳에서는 틀별한 pair가 토론을 지배할 수 있다; 세번째로 참가자들중 한명이 진행자가 되어서 다른 사람들의 의견을 정리할 수도 있다. variation의 정도는 어떤 컨디션 하에서는 매우 비극적일 정도로 실패고 다른 조건하에서는 기가 막히게 성공을 할수 있다. 그러므로 variation의 정도는 항상 통계적으로 중요한 의미를 이끌어내진 못한다. 
이것의 예로  우리가 output의 quality의 몇몇 양적인 measure가 있다고 하자. 우리는 거의 확실하게 non-parametric test들 하게 될 것이고 그러므로 우리가 어느 한 조건에서의 모든 그룹이 다른 조건의 그룹보다 점수가 높다고 가정해보자. 5%의 의미를 얻기 위해서는 적어도 각 조건에 4개는 필요하다.(아마도 measure가)
이제 하나의 조건만 고려하는 예제가 있고 여기서 최고의 결과를 가능해보자. 일반적으로 우리는 컨디션내에서 그룹사이의 spread(다양성)가 더 좋아지길 기대한다, 그리고 우리는 한먼에 더많은 조건을 테스트 하기를 원할것이다. 우리의 10 그룹은 어떤 통계적으로 의미가 있는 결과를 세우기 위해서 빠르게 증가를 할 것이다. 하지만 우리는 10개의 실험 그룹을 얻는것이 상당한 문제가 있다는것을 알아냈다.

이 문제를 해결하기 위해서는 세가지 가능한 솔루션이 있다. 먼저 하나는 within-group experiment를 이용하는것이다. 이것은 은 각 그룹이 여러컨디션 하게에서 실험이 진행이 된다. 두번째로 우리는 micro analysis같은 것을 통해서 발언(의견) 사이의 차이와 같은 특징을 볼 수도 있다. 이와 같은 measure들은 standard distribution에 좀더 적합하게 들어 맞을 수 있고 그러므로강력한 parametric test들을 해볼 수 있다. 게다가 그들은 그룹 사이에 큰스케일의 social difference(사회적 차이)에 더욱 확실하다.
세번째 솔루션은 좀 더 입증되지 않은 분석을 할 때 택할 수 있다. 뭔가 데이터 내에 critical한 사건을 찾는다- 예를 들어서, 흥미로운 이벤트나 고장같은 경우;;; 그룹 차이를 문제로서 간주하는데신에 그들이 분석에 포함 될 수 있다. 즉, 우리는 그들이 사용하는 통신 미디어와 어플리케이션과 상호작용하는 다른 그룹 구조를 찾는 체계적인 방법을 찾기를 시작할 수 있다.

물론 실험은 양적이고 질적인 방법을 둘다 이용해서 분석이 가능하다. 정말 구체화된 입증되지 않은 로그의 분석은 통계적인 분석을 하는데 있어서 생산적인 measure로 나타낼수 있다. 하지만 실험 그룹의 수가 제한 되면 제한된 실험을 시도하는것은 생산적이지 않을 수 있다. 그리고 낭비가 될 수가 있다. group-working 실험의 높은 비용이 주어졌다면, 흥미로운 결과를 낼 수 있는 조건을 선택해야할 것이다. 통계적이 분석이 불가능할 지라도 말이다.

Field studies with group
물론 그룹 실험을 할때 그들을 실험 환경에 집어넣기가 문제가 발생할 수 있다. group이 임의적으로 섞이면 우리는 그룹 편성의 프로세스를 일반적인 워킹그룹보다 효율적으로 조사한다. 심지어 먼저 존재했던 그룹이 이용되어도 그들의 일반적인 작업 환경으로부터 사람들을 제외하는것은 그들의 일하는 패턴을 바꿀 수 있다. 새로운 시스템을 위해서 일반적인(정상적이) workplace는 없을 수 있고 우리가 하는 모든것은 인공적인 환경을 조성하는 것이다. 하지만 이런 새로운 시스템이라도 우리는 좋은 실험이나 자연스러운 세팅을 선택할 수 있다. 전통적인 실험적 심리학은 이들 더 질적인 사회적 분석과 함께 이용될 수 있다. 
그룹실험 같은 경우에는 오직 컨텍스트 안에서만 연구될 수 있다고 주장할 수 있다. 실제 상황에서 벗어나는것은 실제 작업의 
본질을 바꾸는 것이 될것이다. enthnography라는 것은 사람들, 그들의 환경 그리고 서로서로 사이에 매우 상세한 상호작용의 기록을 하는것이다. 

Observational technique
시스템의 실제 사용에 대한 정보를 얻기 위해 사용하는 인기있는 방법은 유저가 시스템과 상호작용하는 것을 탐색을 하는것이다. 

Protocol analysis 
유저의 행동을 기록하는 여러가지 방법이 있다.
- 종이, 연필
- 오디오 레코딩
- 비디오 레코딩
- 컴퓨터 로깅

Automatic protocol analysis tools
프로토콜을 분석하면서 비디오, 오디오나 시스템 로그 둘중하나는 시간을 소비를 하거나 손으로 하게 되어서 지루해질 수 있다. 이것은 동기화해야하는 데잉터가 한개 이상일 때 매우 어려워 지게 되는데 이럴때는 automatic analysis tool을 이용하면 해결할 수가 있다. 이런 툴들은 상세한 분석을 위해서 수정과 비디오, 오디오 주석다는 작업이나 이것들을 동기화하는 그런 수단을 제공한다. 
EVA라고 그런 예가 하나 있는데 이것의 특징은 평가자가 tag버튼을 이용해서 흥미있는 일이 일어나면 그것에 대해서 따로 주석을 달아놓을 수 있다는것이다. 세션이 끝나고 리뷰를 하면서 태그를 달아놓으면 그것으로 검색 역시 가능하다. 
이와 같은 시스템은 비디오 분석에서의 부담은 완화를 시켜주지만 문제가 그것만은 아니다. 태깅하고 주석은 다는 행위는 그들 자신에게 일어나는 이벤트들에 대해서 집중하는것을 방지할 수 있다. 한마디로 이벤트를 놓치거나 나중에 대그가 될 수 있다는 이야기이다. 

Post-task walkthrough
때때로 데이터는 직접적인 탐색을 통해 해석이 결여된채로 획들되었다. 우리는 어떤 수행된 basic action을 가지고 있다. (왜 그런지에 관해 약간의 지식을 가지고) 참가자가 작을을 통해서 think aloud를 장려 을지라도  정보가 잘못될 수가 있다. 예를 들어서 참가자들은 "그리고 지금 내가 undo 메뉴를 선택하고 있어요" 라고 이야기할 수 있다. 하지만 우리에게 어떤 잘못이 undo메뉴를 필요한가는 이야기를 하지 않는다. 게다가 think aloud는  대안같은 정보를 가지고 있지 않다.
walkthrough의 시도는 이러한 문제들을 완화 시키기위한 시도이다, 이벤트 후에 참여자들의 액션을 다시 생각하게 하는것이다.  써졌거나 레코딩된 transcrip은 커멘트를 하러온 실험 참가자들에게 리플레이가 된다. 혹은 질문자들은 바로 질문을 받게 된다. 이것은 참가자가 행동을 하게 된 이유를 알게 된다면  매우 간단하게 해결이 되거나 간격 후에 사용자들의 일정 시간이 지난후의 해석까지 덭붙여서 대답을 받을 수 있다. 지연된 walkthrough의 장점이라고 한다면 분석가가 적합한 질문을 구성하고 어떤 명확한 사건에 초점을 맞춘다는데 있다. 단점이라면 freshness가 떨어지게된다. 시간이 좀 지나서 하는것이기 때문이다.  
실제 observation을 하는 동안 참가자들이 이야기하는것을 기대할 수 없을때는 몇몇 환경이 있다. 예를 들어서 critical task동안에 또는 task가 집중적(많이 모여)일 때 post-task walkthrough가 유저의 행동을 주관적인 관점에서 얻을 수 있는 유일한 방법이 될 수 있다. 가능한한 좋은 퍼포먼스를 얻기 위해서  direct observation동안에 task와 관련없는 이야기를 최소한으로 하는것이 더 선호되는 주장도 있다. 이것이 walkthrough를 필수로 여기게 한다.
Posted by 태씽