http://www.mobilenuri.com

정의
- 차량이 요금소에서 멈추지 않고 정상주행 상태에서 첨단전자장비(무선통신)을 이용하여
   통행료를 지불하는 전자요금징수시스템(ETCS: Electoronic Toll Collection System, 하이패스의 정식명칭)

용어정리
- AVI(Automatic Vehicle Identification, 자동차량인식)

개념도

OTA(Over the Air) or  FOTA(Firmware Over the Air)
- 무선통신시스템에서 시스템 등록에 관한 정보를 송ㆍ수신하기 위해 제정한 표준..


휴대폰 업그레이드ㆍ버그수정, 대리점 방문않고 '원격' 지원
GSM 이용 유럽선 이미 상용화, 국내 3G서비스 이후 적용 시작, 사업성 검증 안돼 확산 '걸림돌'

홍길동씨는 얼마 전 무선인터넷에서 내려 받은 콘텐츠를 실행하려다 실패했습니다. 서비스 센터에 전화해보니, 휴대폰에 내장된 펌웨어(휴대폰 운영체제의 일부)가 옛 버전이라 대리점을 방문해 업그레이드해야만 실행할 수 있다는 설명을 들었습니다. 순간 홍씨는 이런 생각을 하게 됩니다. "휴대폰으로 다양한 데이터 통신이 가능한데, 대리점에 안가고도 무선으로 내 펌웨어를 업그레이드 할 수는 없을까. 아무 때나 하면 통화에 지장이 생길 수 있으니 새벽 시간을 이용해 하면 좋을 텐데…"

많은 이동통신 서비스 고객들이 한 번쯤은 홍씨와 같은 생각을 해봤을 겁니다. 홍씨의 생각은 단순한 상상이 아니며 실재하는 기술입니다. GSM을 이용하는 유럽의 이동통신 사업자들은 꽤 오래 전부터 이런 서비스를 상용화해 제공해 오고 있습니다.

바로 이런 기술을 `OTA'(over the air) 혹은 `FOTA'(firmware over the air)라고 부릅니다. OTA를 조금 전문적인 용어로 설명하면, 무선통신시스템에서 시스템 등록에 관한 정보를 송ㆍ수신하기 위해 제정한 표준입니다.

이를 이용하면 휴대폰에 원격으로 명령을 내리거나, 휴대폰의 사소한 고장(버그)을 수정할 수 있고, 기존의 프로그램을 업그레이드하거나 새로운 프로그램을 설치하는 일들이 가능해집니다. 휴대폰의 기능과 이통사들의 서비스가 복잡해지고 다양화되고 있으니 OTA에 대한 필요성도 더욱 커지고 있는 셈입니다.

우리 이통사들은 이런 OTA 기술을 사용하고 있을까요. 우리나라도 3세대(G) 서비스를 시작하면서 서서히 OTA기술을 적용하고 있습니다. 아직은 펌웨어와 같이 덩치가 제법 있는 프로그램의 업그레이드나 수정까지는 안되지만, WCDMA 개통이나 USIM 잠금장치 해제 등 간단한 일들은 이미 OTA 방식으로 이뤄지고 있답니다.

이보다 조금 진화된 OTA 기술 적용 사례도 있습니다. SK텔레콤과 KTF는 3G 휴대폰의 USIM(범용가입자인증모듈)에서 신용카드 기능을 이용할 수 있는 서비스를 상용화하면서, 신용카드 모듈을 OTA로 전송해주고 있습니다

이전에 이런 서비스를 이용하려면 대리점이나 신용카드 회사를 방문해 신용카드 정보가 담긴 칩을 구입해 장착해야했습니다. 하지만 OTA를 이용하면서 무선 인터넷을 통해 휴대폰 속의 집적회로(IC)칩에 신용카드 모듈을 직접 내려 받을 수 있게 된 것입니다.

OTA의 활용범위가 확대되면 사업자와 소비자들에게는 어떤 좋은 점이 있을까요. 우선 고객들은 대리점을 방문하는 일이 줄어드니 그만큼 시간을 절약할 수 있습니다. 사업자들 역시 고객들의 요구에 쉽고 빠르게 응할 수 있으니 일의 효율성이 그만큼 높아질 것입니다.

지난 2006년에 한국을 방문했던 OTA 전문업체 비트폰의 진왕 CEO는 OTA 도입 효과에 대해 이런 말을 했습니다. "전 세계 이동통신사와 휴대폰 제조업체가 서비스센터 등에서 수동으로 휴대폰 소프트웨어를 수정, 업그레이드하는데 연간 80억달러(2005년기준)의 비용을 지출하고 있다. OAT 솔루션을 도입하면 이런 비용을 3분의 1로 줄일 수 있다"

`비즈니스맨'의 과장이 섞여 있을 수 있으니, OTA 도입에 따른 계량화된 효과를 수치로 장담하긴 어렵습니다. 하지만 비용절감 효과는 이통사 관계자들 역시 인정하는 부분입니다.

이런 비용절감 효과와 고객서비스 증대 등을 이유로 이통사들은 OTA 기술을 확대 적용하는 방안을 고려하고 있으나, 한 가지 고민도 있다고 합니다. 바로 사업성입니다.

한 이통사 관계자는 "고객 서비스가 좋아지고 장기적으로 관련 비용을 줄일 수 있다고는 하나, 엄연히 OTA는 투자가 들어가는 일이라 비즈니스적으로 효과가 있는지 아직은 판단이 서지 않는다"고 하더군요.

아무쪼록 사업자들이 OTA의 적절한 비즈니스 모델을 찾아내 소비자들이 대리점을 방문하는 일을 더욱 줄여줬으면 하는 바람입니다.

 출처: 디지털타임즈 http://www.dt.co.kr/contents.html?article_no=2008041602011831618005

1. BVT란?
     - Build Verification Testing의 약자로, Smoke Test라고도 함.

 2. BVT의 목적 및 의도
     - BVT는 특정 빌드에 대해서 수행한다. 
     - BVT는 빌드 마다 각각 수행될 수 있다. (매 빌드마다 수행하는 것이 좋다는 의미는 아님.) 
     - BVT는 해당 빌드가 더 이상 리소스를 투입해서 테스트를 진행할 가치가 있는 빌드인지 판단하고 
       개발팀에 피드백을 주기 위한 목적.

       QA는 더 이상의 의미없는 테스팅 리소스를 투입하지 않을 수 있고, 개발팀은 테스팅이 더 진행되어서 
       문제의 원인 파악이 어려울 수 있는 전 단계에서 오류 여부를 확인할 수 있게됨.

 3. BVT 준비 단계 
     - TCL(Test Case List) 테스팅을 위해 마련된 TCL은 먼저 준비되어 있어야 한다. 
     - TCL은 한 가지 품질 속성 및 기능 군으로 작성하지 말고, 다수의 기능 군 영역, 품질 속성 영역으로 나누어 
       작성되어 있어야 한다.
     - 준비된 TCL이 커버하는 기능 군에서 중요하고 먼저 확인되어야 하는 선행 기능을 몇 개 추린다. 
       (가능한 한 케이스 간의 의존성이 없게 한다.)
     - 각 기능 군마다 1-4 정도의 케이스를 추려서 이를 하나의 양식으로 정리하면 BVT 수행을 위한 
       테스트 케이스가 완성된다. 
     - BVT 요소 선정의 또 다른 기준은 BVT에 오랜 시간이 걸려서는 안된다는 점이다. 
       따라서, 프로젝트의 상황을 보아 BVT에 투입할 수 있는 시간(예를 들면, 1시간 또는 2시간)에 따라서, 
       BVT의 수를 가감한다.
      (예를 들면, BVT는 1시간 이내로 수행 완료 하고 그 결과를 개발팀과 리뷰할 수 있도록 정한다 등의 규칙)

 4. BVT가 완료된 이후의 업무 처리 단계 
     - BVT 내용에 대해서 Peer Review(동료 검토)를 수행해서 피드백을 반영한다. 
       (반드시 수행하는 것이 좋다. 최적의 경우 2회 정도의 리뷰를 거쳐서 더 이상 QA 레벨에서는 
       수정 사항이 없다고 리뷰어 들과 합의가 되는 수준까지 진행한다.) 
     - QA 레벨에서 합의된 BVT 내용에 대해서 개발 선임 및 PM과 협의한다.

 5. 협의시 주의 사항 
     - BVT의 내용에 대해서는 하나의 항목이라도 Fail 또는 Block 인 경우 더 이상의 테스트를 진행하지 않는다. 
       이유는 더 이상의 테스팅 리소스를 투입할 가치가 없는 빌드라고 볼 수 있기 때문이다. 
     - BVT의 Expected Result 및 케이스에 수정 사항이 없는지 검토를 요청한다. 
     - BVT에 추가할 요소가 없는지 검토를 요청한다.

 6. 협의가 완료되면 
     - 이제 확정이 되었으므로 개발팀 전체를 대상으로 공표하고 BVT가 필요하다고 QA에서 판단되거나, 
       개발팀의 요청이 있는 경우 빌드를 선정해 BVT를 수행하고 그 결과를 분석, 개발팀에 통보한다.

 7. BVT를 기준으로 삼는 이슈들(반드시 PM 및 개발 선임과 사전 협의 필요) 
     - 모모 프로젝트에서 BVT를 이하는 방법은 다음과 같다.

     1) 모든 테스트의 시작에는 BVT가 반드시 있어야 한다. 
     2) TCL 테스트를 시작하려면 먼저 BVT가 통과된 빌드가 있어야 한다.
         (BVT를 통과해야만 TCL 테스트가 가능하다.) 
     3) 버그 추적 시스템에 올라온 이슈의 재 확인(Re-Testing)은 반드시 BVT를 통과한 빌드에 한정한다.
         (개발팀에서 수정이 반영되었을 것이라고 얘기하는 특정 빌드가 아니다.
          반드시 BVT가 통과된 수정 사항이 반영된 이후의 빌드를 선정해 Re-Testing을 수행한다.
          이때, BVT가 통과되지 않아 Re-Testing의 지연이 발생할 수 있으나, 이는 QA에서 통제할 수 있는 상황이
          아니다. 만일 Re-Testing이 빨리 처리되기를 희망한다면 - 버그 처리 시스템의 이슈가 Closed 되기를
         바란다면 - 최선의 방법은 개발팀이 BVT를 통과하는 빌드를 만들어 내는 것이라는 점을 개발팀에 설명하라.)

 8. 남은 문제들 
      1) BVT 내용에 대해서 트집을 잡는 경우를 주의하라.
          다시 강조하지만 BVT 요소에 대해서 개발팀 및 PM과 협의를 거쳐야 한다.
          BVT 정책을 수행한다는 내용과 함께 BVT 내용에 대해서도 Confirm을 받아 둔다.

      2) BVT에 대해서 가급적 테스트 하는 사람에 따라서 결과가 달라질 수 있는 요소는 배제하라.
          보는 사람에 따라(테스팅 하는 사람에 따라) BVT Pass / Fail이 달라지는 요소는 차후에 더 큰 이슈를
          불러 온다.

      3) 어느 수준에 이른 빌드는 이미 BVT는 가볍게 통과할 수 있다.
          이때는 BVT 요소의 변경 / 추가 / 삭제를 고려해 보라. (물론 개발팀은 힘들게 달성한 BVT통과 수준이기 때문에 거부할 지도 모른다.)

------------------------------------------------------------------------------------------------------------------------

Further Reading
아래에 BVT에 관해 언급하고 있는 참고 도서를 곁들여 보시면 더욱 좋습니다.

The Art of Project Management (마음을 움직이는 프로젝트관리) by 스콧 버쿤 pp. 419
일일 빌드를 수행할 경우, 체크인한 코드가 다른 부분에 피해를 입히면 프로그래머가 (그리고 전체 팀이) 이 사실을 즉각 알게 됩니다. 따라서 체크인 코드 품질이 높아집니다. 당일 빌드에 포함될 코드는 특정 시각까지 제출하게 하십시오. 그런 다음, 코드 기반을 안정화한 후 테스트를 수행하여 빌드 품질을 확인합니다. (흔히 이와 같은 일일 테스트를 동작 테스트_smoke test라고도 합니다. 전자 부품을 테스트하는 기법으로, 회로에 전기를 흘려서 글자 그대로 연기가 나는 부분이 있는지 확인합니다) 정해진 시간 이후에 체크인하는 코드는 다음 빌드에 포함됩니다.

빌드를 할 때마다 빌드 품질을 평가하는 테스트 집합이 있어야 합니다. 평가 기준은 합격 (모든 테스트 통과), 보류 (일부 테스트만 통과), 불합격 (몇몇 테스트만 통과 또는 모든 테스트 실패)이라는 세 단계 정도면 충분합니다. 테스트 실패 원인으로 파악된 버그는 빌드 정보에 기록하고 우선 순위를 높게 매겨야 합니다.

(중략)

Lessons Learned in Software Testing (소프트웨어 테스팅 법칙 293가지) by Cem Kaner외 2인 pp. 226
법칙 173. 때로는 빌드에 대한 테스트를 거부해야 한다.
때때로 빌드를 거절하고, 빌드에 대한 테스트를 거부해야 한다. 이와 같이 하는 것의 합리적, 기술적인 이유는 다음과 같다.

* 이번 빌드에서는 중요한 기능이 추가되었는데, 이 빌드에 존재하지 않는 기능이 있다는 것을 알아채거나 실행하자마자 오류가 발생하였다면 더 이상 테스트를 진행하는 것은 시간 낭비이다.

(중략)

법칙 174. 빌드를 평가하기 위하여 연기 테스트를 사용하라.
연기 테스트(일명 온전성 확인 또는 테스트 수락)는 빌드의 기본적인 기능성을 점검하기 위한 테스트 스위트이다. 만약 빌드가 이 테스트에 실패한다면 해당 빌드는 불안정하여 테스트할 가치가 없다고 말할 수 있다.

(중략)

Systematic Software Testing by Rick D. Craig and Stefan P. Jaskiel
스모크 테스트(Smoke Test)
스모크 테스트는 시스템이 안정적인가, 모든 주요 기능들이 존재하며 "일반적인" 상황에서 제대로 작동하는가를 입증하기 위한 테스트 케이스들의 집합입니다. 스모크 테스트의 목적은 소프트웨어의 모든 버그를 찾는 것이 아닙니다. 시스템을 테스트하는 팀에게 어디에서부터 테스트를 시작 해야 하는지 알게 해 주는 것입니다. 이 테스트는 개발자들에게 목표을 제공하며, 언제 개발자들이 '안정성을 보유한 단계'를 달성하게 되는 지를 알려줍니다.

중요 요점: Smoke test는 시스템이 안정적인가와 모든 주요 기능들이 존재하며, "일반적인" 상황에서 제대로 작동하는가를 입증하기 위한 테스트 케이스들의 집합입니다.

(중략)

Sustainable Software Development: An Agile Perspective by Kevin Tate
Practice 5. Nightly Builds
당신의 팀이 소프트웨어가 동작한다고 확신하기 위해서는 하루에도 몇 번씩 원소스로부터 완전하게 빌드가 생성되어야 한다. 그 빌드에는 통합의 문제를 일찍 발견해 내기 위해 가능한 한 많은 수의 자동화된 테스트를 담고 있어야 한다. 그리고 빌드의 결과는 설치 가능한 제품 이미지이어야 한다. 밤시간은 이러한 작업을 하기에 적당한 시간인데, 아무도 코딩을 하고 있지 않고, 놀고 있는 컴퓨터가 매우 많기 때문이다. 그럼에도 불구하고 가능한 한 낮에 많은 수의 제품을 빌드하는 것에 매우 많은 장점들이 있다. 만일 빌드나 테스트가 실패한 경우, 아침에 가장 먼저 할 일은 문제를 수정하는 것이다. 빌드가 다시 성공할 때까지는 아무도 자신의 추가 작업을 통합하지 못하게 하라. 그렇지 않으면, 잘못된 변경 사항이 누적되어 제품에 품질을 위태롭게 할 위험성이 있다.

(중략)

소프트웨어 프로젝트 생존전략 (Software Project Survival Guide) by 스티브 맥코넬 pp. 277
일별 빌드와 스모크 테스트 절차에서는 전체 프로그램이 날마다 빌드 된다. 즉 프로그램의 모든 소스 파일이 날마다 컴파일, 링크되어 실행 파일로 생성된다는 것이다. 그후 소프트웨어는 ‘스모크 테스트’를 거치는데, 이는 실행 중에 소프트웨어에서 ‘연기가 나거나’ 깨지지는 않는지 확인하는 비교적 간단한 테스트를 말한다. 스모크 테스트라는 용어는 전기 공학에서 나온 것인데, 글자 그대로 전기 장치를 켰을 때 연기가 나는지 검사하는 것이다.

날마다 일별 빌드와 스모크 테스트를 실시하면서, 빌드되지 않는 데에 책임 있는 개발자를 추적하고 그 원인을 수정하게 하려면 어느 정도 노력이 필요하다. 작은 규모의 프로젝트에서는 품질 담당자가 자신의 다른 업무를 병행하면서 일별 빌드를 수행한다. 좀더 큰 규모의 프로젝트에서는 전담 인원이나 전담 팀이 일별 빌드를 수행할 수도 있다.

스모크 테스트는 소프트웨어 개발에 보조를 맞추기 위해 프로젝트 전반에 걸쳐 업데이트해야 한다. 또한 날마다 실시해야 하기 때문에 대부분이 자동화하여 실행한다. 스모트 테스트는 모든 것을 철저하게 확인해야 하는 테스트는 아니지만, 그날의 빌드가 테스트할 수 있을 만큼의 안정성을 지닌 소프트웨어 기능인지 확인해야 한다. 소프트웨어가 테스트할 수 없을 만큼 불안정하다면, 그 소프트웨어는 스모크 테스트를 하지 말아야 한다.

(중략)

Game Testing All In One by Charles P. Schultz 외 2인
Entry Criteria

어떤 형태의 테스팅을 수행하더라도 사전에 테스트에 적합한지에 대한 어떤 통과 기준에 코드 릴리즈가 적합한지 확인하는 것이 권장된다. 이것은 우주 여행사나 파일럿이 비행 전에 항공 시스템이 운행에 적합한지 점검하는 체크리스트와 유사하다. 테스팅을 위해 제출된 빌드가 기본적인 진입 기준에 미달하는 경우 테스터와 프로그래머 둘 모두의 시간을 낭비하게 될 가능성이 많다. 테스팅의 카운트다운은 테스트 "발사" 통과 조건을 충분히 만족할 때까지 중단되어야 한다.

아래의 진입 기준으로 사용할 수 있는 제안들을 나열해 두었다. 반드시 개발팀의 인원들에게는 이 내용을 비밀로 하지 마라. 그 팀이 이것의 목적을 인식하고 (시간 낭비를 방지하기 위해) 전체 팀이 공감할 수 있는 통과 기준의 집합을 그들과 함께 만들도록 하라.

(중략)

1. 격렬한 화약 같은 말

‘당신은 늘 그래!’ ‘똑바로 좀 들어!’ ‘이제는 당신 좀 변해!’

이런 식으로 불 같이 말해서 문제를 확대시킵니다.

자신의 말이 어떤 문제를 일으키는 줄을 항상 본인이 알면서도 그 말을 멈추지 않습니다.

이런 말을 자주 하는 사람과는 대화를 하고 싶지 안게 됩니다.

2. 침묵

침묵은 의심, 혼동, 추측, 경멸, 무관심, 냉정함을 상대방에게 전합니다.

침묵 속으로 빠지지 말고, 험한 말로 남을 침묵 속으로 빠뜨리지 마십시오.

3. 실망시키는 말

‘어린애도 너보다는 낫겠다.’

상대방의 잘못을 인식시키겠다는 의도로 이런 말을 하지만 이런 말은 태도 변화를 이끄는데 가장 부적합한 말입니다.

처음에는 약간의 효과가 있어 보이나 나중에는 그 말을 아예 귀담아 듣지 않습니다.

그래서 정작 중요한 말을 할 때도 ‘녹음기 틀어놓은 말’로 무시해 버립니다.

4. 빗대어 하는 말

자신의 생각을 말하면서도 남의 이야기인 것처럼 남을 끌어들여 말합니다.

선한 예기는 그렇게 해도 좋지만 나쁜 예기는 그렇게 하면 않됩니다.

5. 방어적인 말

불편한 말을 들었다고 대뜸 맞대응해서 짜증 섞인 말을 하는 사람이 있습니다.

이 사람은 상대방의 필요에 대한 민감성이 부족한 사람입니다.

6. 감정 섞인 말

큰 소리, 화난 소리, 격렬한 소리, 극적인 소리도 좋지 않습니다.

그것은 감정의 솔직한 반영이라기보다는 대화의 주도권을 잡으려는 나쁜 획책입니다.

7. 너무 말을 많이 함.

사람들이 말을 많이 하는 이유는 다름 사람을 지배하고 분위기를 장악하려고 하거나 자신의 분노와 좌절을 그런식으로 표현하기 때문입니다.

그 외에도 이중적 의미를 지닌 말, 미덥지 못한 눈빛, 가로채는 말, 분별없는 말, 경청하지 못하는 태도 등

내가 혹시 이중에 해당하지 않을까?