Accelerating Technology

Digital Disruption – Examples

UK Situation – 2015 Figures (Deloitte)

• “10 Million (35% of all) UK jobs are at risk of automation in the next 10 to 20 years”
• Last 15 years
–Technology has already contributed to the loss of 800,000 lower-skill, higher-risk jobs
–However, technology has already helped to create 3,500,000 new higher-skill, non-routine jobs
–And, on average, each new job is paid approximately an extra ₩16 million adding more than ₩ 221 Trillion to the UK economy


Accelerating Technology

자세히 보기

An Open Source Tool for Fault Tree Analysis

동영상 보러가기

본 프로젝트는 SAVI(System Architecture Virtual Integration) 프로젝트를 통해 시작되었고, SAVI는 AADL을 사용하여 다양한 작업을 수행하는 항공 전자 컨소시엄입니다. 항공 전자 공학의 안전에는 폴트 트리 분석이 필요한 분석 중 하나입니다. 

기본적으로 사람들은 스프레드 시트 나 문서를 사용하고 있기 때문에 Excel, Word에서 분석 결과를 쉽게 내보낼 수 있습니다. 하지만, 결함 트리는 도구가 없고, 있어도 이미 5~8년이 넘은 제품들입니다. 아키텍처에는 EMF, Eclipse Modeling Framework라는 모델링 프레임 워크가 있기는 합니다. 

우리는 결함 트리를 위한 새로운 모델을 구축해서 사용했고, 이 후에는 Obeo라는 프랑스 회사에서 개발한 Sirius라는 프레임 워크를 써서 그래픽 프리젠테이션을 만들었습니다. 정말 빨리 작업할 수 있었고, EMFTA라는 새로운 도구를 적용 했습니다. 이 도구는 Eclipse에 완전히 통합되어 있고, 결함 트리를 편집하고 설계 할 수 있습니다. 더구나 오픈 소스입니다. BSD 라이센스에 따라 배포되었고, 누구나 SEI Github 저장소에서 사용 할 수 있습니다. OSATE 내에 완전히 통합되어 최신 OSATE 버전을 다운로드하여 테스트 할 수도 있습니다. 

이것을 통해 결함 트리를 생성해서 최적화 할 수 있고, 결합 트리를 개선하거나 실패 확률을 계산할 수 있습니다. 결함이 있는 곳에 다른 노드가 있으면 최적화 할 수 있고, 리팩터링 제안도 할 수 있습니다. 또, 새로운 기능을 추가하기 쉽습니다. 

이 도구는 항공 전자 공학 계열 시스템 뿐만 아니라 자동차나 다른 운송에 사용될 수 있고, 금융이나 보험, 시스템에서 서로 다른 결함으로 인해 서로 다른 상호 작용이 발생 할 수 있는 방법을 찾고자 하는 응용 프로그램에서도 사용할 수 있습니다. 

[SEI의] GitHub 저장소에 기능, 결함 트리 설계 방법, 그래프 또는 테이블과 다른 표현 방법에 대한 전체 설명서가 있습니다. GitHub에서 소스를 다운받아 빌드하면 됩니다. 그리고, OSATE 내부에 통합 한 버전과 실행 파일이 있으니 다운로드 하십시오. 

올해 9 월에 큰 행사를 가졌으며, 10 월에 피츠버그에서 개최되는 ES Week Embedded System Week 행사가 있습니다. 이 결함 트리 분석 도구를 가지고 보안과 안전에 대해 얘기할 것입니다. 

Agile을 적용한 ALM 사례 – C사

Phase & Activity

THINK NEXT

자세히 보기

모바일 페이먼트에 필요한 기술 요소

최근 전세계 모바일 페이먼트(지급결제; Mobile Payment) 시장이 빠르게 확대되고 있고, 규제로 인해 다소 늦어진 감은 있으나 우리나라에서도 본격적인 모바일 페이먼트 시장 진출이 줄을 잇고 있다. 모바일 디바이스의 급속한 보급으로 인해 모바일 페이먼트 시장은 더 확대될 것으로 보여 글로벌 시장에 진출할 수 있는 경쟁력 있는 기술이 필요한 시점이다. 이번 회에서는 널리소프트 김학길 수석을 만나 모바일 페이먼트의 주요 기술에 대해 알아본다.

Q: 본격적인 이야기 전에 모바일 페이먼트에 대한 설명을 부탁 드립니다. 

모바일 페이먼트는 어렵지 않은 개념입니다. 지폐를 사용하다가 신용카드가 보급되면서 지금은 신용카드로 결제를 하는 시대이고, 이제 모바일 디바이스를 이용해 결제를 한다는 것이 모바일 페이먼트의 기본 개념입니다(그림1). 

 <그림1> 모바일 페이먼트의 개념 

 출처: AhnLab 

그림1에서 보는 것처럼, 신용카드를 사용하는 오프라인에서는 VAN(Value Added Network)이라는 결제 방법을 통해 지불 정보를 주고 받는 것이 일반적이었습니다. 모바일 페이먼트는 중간에 모바일 디바이스를 이용한 결제 방법을 추가한 것입니다. 최근에 많이 사용되는 카드사들의 앱카드, 카카오페이, 전자지갑 등이 그것이고, 삼성페이나 T페이 등도 모바일 디바이스에 카드 정보를 심어 두어 활용합니다.   

Q: 핀테크의 일종이라고 봐야겠지요? 모바일 페이먼트가 늘어나는 이유는 무엇으로 봐야 할까요? 

네, 맞습니다. 핀테크의 일종이고, 모바일 페이먼트가 늘어나는 가장 큰 이유는 스마트폰 확산이 가장 큰 이유라고 봐야지요. 그렇다고 무조건 스마트폰이라고 하기보다는 NFC(근거리 무선통신; Near Field Communication)와 같이 가까운 거리에서 결제 장비와 통신을 가능하도록 해주는 장치들이 스마트폰에 탑재되어 있기 때문입니다. 최근에는 비(Beacon)도 그 역할을 해주고 있고, 카카오페이나 앱카드의 경우는 웹 환경과 유사한 온라인 상에서 결제가 처리되도록 해주고 있습니다. 삼성페이의 경우는 MST(Magnetic Secure Transmission)라는 기술을 이용하는데, 마그네틱(Magnetic)을 이용한 전송 기술로 주목을 받았습니다(그림2). 

 <그림2> 삼성페이의 MST 기술 개념 

 출처: 삼성페이

자세히 보기

Agile을 적용한 ALM 사례 - B사

개발 문화의 변화 전략




지향하는 개발문화를 위한 점진적 접근

자세히 보기

4th Industrial Revolution – Not just robots

The Salary Spectrum

 “Average is over!”




4th Industrial Revolution – Not just robots

자세히 보기

UX 사례 연구 - 스토리텔링

인문학 감성에 대한 필요성이 높아지면서 스토리텔링에 대한 관심이 점점 높아지고 있다. 소프트웨어 개발에서도 애자일이 도입되면서 사용자 스토리 (User Story)를 정확히 만들기 위한 노력이 높아지고 있고, 사용자의 요구사항을 더 알아보기 쉽고 명확하게 하기 위해 스토리텔링 기법도 동원되고 있다. 이번 회에서는 UX의 한 기법인 사용자 스토리를 만드는 방법에 대해 살펴보도록 한다. 기술적 성향이 매우 높은 개발자들이 사용자가 이해하기 쉬운 형태로 사용자 스토리를 만들 수 있기를 기대한다.

사례 연구 전 확인 사항

사용자 스토리 (User Story)의 정의

지금까지도 사용자 (고객 )의 요구사항을 정리할 때 , 사용자보다는 개발자 입장에서 작성하게 된다. 그림 1은 사용자의 요구사항을 정리한 문서이다. 개발 프로젝트의 개발자는 사용자와 회의를 하면서 정리하고, 입출력 데이터 등을 정리하여 사용자에게 확인을 받는다.

<그림 1> 요구사항정의서의 예

출처 : http://fixframe.tistory.com/category/웹기획 /분석

그림 1을 가지고 사용자에게 확인을 받으면 사용자는 자신의 요구사항이 얼마나 반영되었는지 알기가 어렵다. 더구나, 사용자는 자신들의 업무나 하는 일에 대해 개발자가 제대로 이해했는지도 알 수가 없다. SI(System Integration) 프로젝트에서 가장 어려운 부분 중 하나가 프로젝트가 다 끝나가는데 요구사항이 변경되는 것이다. 추가적인 요구사항이라면 협상의 여지가 있지만, 요구사항을 잘 못 이해하고 만든 것이라면 분석, 설계부터 개발까지 회귀 결함을 포함해서 재개발해야 하는 문제도 생긴다. 지금까지 개발자들이 가장 놓쳤던 부분이 “사용자는 시스템이나 개발 프로세스를 잘 모른다”는 것이고, 반대로 “개발자들은 사용자가 하는 일을 잘 모른다”는 것이다.이와 같이, 개발 프로젝트 초기에는 과도한 요구사항 수집과 문서화는 프로젝트를 망칠 수 있는 요인일 수 있다.

이러한 문제를 개선하고자 사용자가 하는 일을 사용자나 개발자 모두가 쉽게 이해할 수 있도록 스토리 형태로 정리하는 것이 사용자 스토리이다. 애자일에서 사용자 스토리는 사용되는 소프트웨어의 기능이나 요구사항을 의미하고, 한 두 문장으로 짧게 표현하고, 명세보다는 의사소통을 위한 목적으로 활용된다고 하고 있다.

자세히 보기