2016년 11월 30일 수요일
DevOps 환경 을 위한 시스템 & 프랙티스
DevOps 는 무엇인가
DevOps를 위해 필요한것들
• 자동화(Automaiton)
• Provisioning, Deployment, Test Automation
• 문화(Culture)
• Cross functional team
• 개인
• 프로그래밍 능력
애자일과 전통적 개발방식의 조화
제품개발 패러다임의 변화
Project Management 목표
SW개발프로젝트사례
•프로젝트개요
–건축설계관련솔루션개발, 개발기간2년
•주요이슈및문제점
–업무회의는많으나팀원들간에실질적인의사소통이되지않음
–제품기획의불안정으로불명확한목표및일정관리
–불필요하다고느껴지는산출물이많음
–업무성과및품질불량으로관리자와팀원간의갈등발생
–수동적인팀원의자세
–팀원들간의소통및협력부재(자기업무에만집중
Project Management 목표
SW개발프로젝트사례
•프로젝트개요
–건축설계관련솔루션개발, 개발기간2년
•주요이슈및문제점
–업무회의는많으나팀원들간에실질적인의사소통이되지않음
–제품기획의불안정으로불명확한목표및일정관리
–불필요하다고느껴지는산출물이많음
–업무성과및품질불량으로관리자와팀원간의갈등발생
–수동적인팀원의자세
–팀원들간의소통및협력부재(자기업무에만집중
2016년 11월 29일 화요일
동영상 : An Open Source Tool for Fault Tree Analysis
참석자
Suzanne Miller - principal researcher at the SEI (the Carnegie Mellon University Software Engineering Institute)
Dr. Neil Ernst - a Fellow researcher who works in the SEI’s Architectural Practices Initiative
요약
기술 채무 (Technical Debt)
소프트웨어 개발 프로젝트를 진행할 때, 초기에 제대로 처리하지 않은 일이 반복 주기에서는 문제점으로 나타나고, 이러한 문제점이 다른 수정사항이나 또 다른 문제를 나타낼 수 있어 원금에 이자까지 지불해야 하는 상황이 온다는 개념
소프트웨어 개발 프로젝트를 진행할 때, 초기에 제대로 처리하지 않은 일이 반복 주기에서는 문제점으로 나타나고, 이러한 문제점이 다른 수정사항이나 또 다른 문제를 나타낼 수 있어 원금에 이자까지 지불해야 하는 상황이 온다는 개념
원격 개발센터의 장단점 분석
소프트웨어 개발을 시작한지 오래된 우리나라에서는 단순 개발이나 공통 개발이 필요한 분야를 한데 모아 효율적으로 관리하고자 노력하고 있다. 이에 대한 대안으로 원격 개발센터 모델이 제시되었는데 많은 투자와 노력에 비해 성공률이 높지는 않은 것이 현실이다. 이번 회에서는 원격 개발센터에 필요한 프로세스나 방법론을 정비하여 적용한 경험이 있는 ㈜Coocon의 한용만 박사와 단국대학교 소프트웨어공학센터 김규억 박사를 만나 원격 개발센터에 대한 이야기를 들어보도록 한다.
Q: 안녕하세요. 원격 개발센터를 위한 프로세스와 방법론을 아시아권에 일부 적용한 것으로 알고 있습니다. 원격 개발센터는 어떤 기업들이 고민하는 것인가요?
처음부터 개발자들을 분리하여 원격 개발센터를 만들 수는 없습니다. 같은 분야의 개발 업무를 오래도록 하다 보면, 단순 개발 업무가 나타나게 되는데 이런 업무를 인건비가 비싼 우리나라 개발자에게 계속 맡기면 비용 대비 효과가 많지 않습니다. 그래서, 인건비가 싼 중국이나 아시아권의 다른 지역에 개발 업무를 넘기는 것입니다. 그림1을 보면, 개발에 필요한 설계, 개발, 테스트를 원격 개발센터에 넘겨 업무를 수행하게 되는데, 경우에 따라 설계 업무는 넘기지 않는 경우도 많습니다.
<그림1> 원격 개발센터의 예
원격 개발센터를 운영하는 또 다른 중요한 이유는 다수의 사이트에서 공통으로 사용되는 부분을 원격 개발센터에서 담당하는 것입니다. SI를 예로 들면, 각 사이트마다 개발자들이 파견을 가게 되는데, 공통적으로 개발되는 부분은 한 곳에 모여서 개발하는 것이 훨씬 효율적이지요. 공통 개발을 위한 원격 개발센터는 기업의 본사에 위치해서 빠른 의사결정 하에 운영하는 경우가 많습니다.
UX 사례 연구 - 멀티 디바이스의 UX
1인 다(多) 디바이스의 시대가 도래했다. PC 위주였던 과거에서 스마트폰, 테블릿PC에 이어 TV나 스마트홈까지 장소나 크기에 제한 받지 않고 스마트 디바이스를 사용하는 시대인 것이다. 다수의 디바이스를 장소나 상황에 따라 동시에 사용할 수 있는 것을 멀티 디바이스라고 하는데 한 사람이 다수의 디바이스를 사용하지만 컨텐츠는 디바이스에 맞춰 보여줘야 하는 요구사항이 있다. 이번 회에서는 멀티 디바이스를 위한 UX에 대해 알아보기로 한다. 멀티 디바이스를 위한 UX를 이해하여 소프트웨어 사용성과 편리성을 높여주길 기대한다.
사례 연구 전 확인 사항
한 명의 사용자가 다수의 디바이스를 사용하지만 컨텐츠는 끊김 없이 보여줘야 하기 때문에 UX의 역할이 점점 더 중요해지고 있다. PC, 테블릿이나 스마트폰 단위로 따로 UX를 설계했던 과거와는 달리, 개인이 보유한 디바이스의 수도 늘어나고 IoT까지 발전하고 있어 멀티 디바이스의 요구가 점점 늘어나고 있다(그림1).
<그림1> 멀티 디바이스와 멀티 스크린의 개념
출처: Etri
그림1을 살펴보면, 멀티 디바이스는 하나의 컨텐츠를 다양한 디바이스에서 동시에 나타나도록 하는 것, 하나의 디바이스에서 사용된 정보는 모든 디바이스에서 사용된 것처럼 공유하고, 디바이스 간 정보 교환 등이 가능하도록 해주고 있다. 구글(Google)에서는 멀티 디바이스를 위한 UX 설계에 기본적인 사용자 경험을 여러 디바이스에 복제하는 일관성(Consistent), 한 디바이스에서 다른 디바이스로 사용자 경험을 전달하는 연속성(Continuous), 여러 디바이스가 합쳐지면서 새로운 사용자 경험을 만들어 내는 상호보완성(Complementary)을 고려 하도록 가이드하고 있다.
2016년 11월 28일 월요일
SI 프로젝트와 개발 문화
Q: 문화를 바꿔야 SI 프로젝트 수행이 쉬워진다는 것으로 정리하겠습니다. SI 프로젝트 수행이 어려운 두 번째 이유를 말씀해주시죠.
SI 프로젝트는 고객의 요구사항을 정확히 적용해야 하기 때문에 처음부터 모든 것을 새로 개발하는 경우가 많았습니다. 이렇게 되면, 가장 큰 문제가 검증입니다. 아무리 능력이 뛰어난 개발자가 개발해도 단 한번에 성공하는 시스템은 없습니다. 반복해서 테스트해야 하고 문제가 없는지 되돌아 봐야 하기 때문에, 반복되는 작업에 점점 지쳐가는 것이죠. 그나마도 이젠 끝이라고 확신을 가질 수도 없습니다.
저는 금융 프로젝트를 많이 했는데, 검증의 문제는 언제 어디서든 터질 수 있는 이슈사항이었지요. 이런 이유 때문에, 많은 SI 회사에서 품질이나 지원도구 같은 검증 도구를 많이 사용했지만, 우리가 인스펙션(Inspection), 워크스루(Walkthroghs), 통합 테스트 등을 하면서도 문제를 근본적으로 해결하기는 어려웠습니다(표1). 안타깝지만, 새로 만들었기 때문에 이러한 문제가 다소 발생하는 것을 인정해야 한다는 것입니다.
<표1> 워크스루와 인스펙션의 정의
Q: SI 프로젝트를 하면서 새로 개발하는 것은 어떻게 보면 당연한 일인데, 어떤 해결 방법이 있을까요?
그림2에서 보는 것처럼, 유사한 기능을 가진 완성된 것들을 활용하자는 겁니다. 어떻게 보면, SI 프로젝트는 무조건 새로 개발해야 한다는 것은 우리가 만든 규칙인지 모릅니다. 새로 만드는 소프트웨어의 개수에 따라 비용이 지불된다는 암묵적인 약속 때문이겠지요. 비용 산정을 위해 LOC(Line of Code)나 기능점수(Function Point), 코코모(CoCoMo)를 찾는 것도 SI 프로젝트는 코딩의 규모만 반영되었다는 단편적인 증거가 될 것입니다. SI 프로젝트는 고객이 시스템을 이용해 업무를 원활히 할 수 있도록 해주는 것입니다. 컨설팅과 개발을 함께 갖고 있다고 생각해야 합니다.
SI 프로젝트의 요구 사항과 필요 역량
Q: 시장과 사업 관점에서는 SI 프로젝트가 힘들 수 밖에 없다는 것을 인정해야 한다는 말씀으로 들립니다. 그렇다면, 프로젝트를 수행하면서 힘들 수 밖에 없는 근본적인 이유는 어디에 있을까요?
얼마 전에 이 문제에 대해 모 대학의 소프트웨어공학 연구소와 분석해 본적이 있습니다. 두 가지 이유로 요약을 해보면, 첫 번째는 SI 프로젝트의 고객들은 소프트웨어를 너무 모르는데 개발자들은 너무 많은 것을 알려달라고 한다는 것이었습니다. 그리고, 두 번째는 고객들이 요구하는 것을 무조건 새로 만든다는 것이었습니다.
Q: 고객들이 소프트웨어를 너무 모르는데 많은 것을 물어본다고요?
네, 그렇습니다. 요구사항을 고객한테 받게 되는데, 개발자들은 전문 용어를 섞어가면서 물어보는데 고객은 잘 모르는 상태에서 대답하는 경우가 많다는 것이지요. 사실, 프로젝트 초기에는 개발자도 업무를 모르게 때문에 양쪽 모두 서로 모르는 상태에서 제일 중요한 요구사항을 정리하는 것입니다.
Q: 이전 인사이드이슈에서도 다뤘던 것 같습니다. 요구사항을 고객의 용어로 정리해야 한다는 말씀이지요?
고객의 용어로 정리하는 것은 매우 중요한 포인트입니다. 시스템을 완성하고 확인을 해줘야 하는 사람이 고객이기 때문에 고객의 용어로 정리하라는 것입니다. 어떻게 보면, 당연한 이야기인데 그 동안의 SI 프로젝트에서는 고객이 자꾸 요구사항을 변경한다고 싫어했던 기억이 있습니다. 이러한 문제를 해결하기 위해, 애자일이나 사용자 스토리 워크샵 같은 활동이 최근에는 활발히 적용되고 있습니다. 개발자에게 개발 역량뿐만 아니라 고객(사용자)를 이해하는 능력도 필요하다는 얘기입니다(그림4).
<그림4> 소프트웨어 개발자의 필요 역량 변화
침체된 SI 시장과 극복 방안
Q: SI가 시장 관점이나 개발자 관점 모두 어려운 것이 현실이라면 SI 프로젝트를 왜 하는 것인가요?
이 것도 두 가지로 볼 수 있습니다. 먼저, 매출이 매우 크다는 점이지요. 단기간에 대형 시스템을 구축하려면, 많은 소프트웨어를 개발해야 하고 구동이 가능하도록 하드웨어도 설치해야 하지요. 이렇게 많은 매출을 발생시키기 때문에 회사의 규모를 키우기 위해서는 SI 프로젝트가 필요합니다. 하지만, 더 큰 이유가 두 번째인데요. SI 프로젝트는 소프트웨어 생명주기(Software Life Cycle)을 모두 포함하기 때문에 짧은 시간에 개발 역량을 성장시키는데 매우 적합합니다. 교육을 따로 시키지 않아도 실전으로 경험과 지식을 쌓을 수 있는 것이지요. 누가 뭐래도 IT 서비스 산업의 성장은 SI 프로젝트가 이끌었다는 것은 부정할 수 없을 겁니다.
하지만, SI 시장에 뛰어드는 업체가 점점 많아지고 있고, 진입 장벽은 높지 않다 보니 대형 SI 업체들은 해외로 눈을 돌리거나 다른 부문으로 전환을 하는 추세입니다(그림3).
<그림3> SI 업체의 사업부문 매출 현황
출처: CEO 스코어
2016년 11월 25일 금요일
UX 사례 연구 - 모바일 SW의 UX
UI(User Interface)와 UX(User eXperience)에 대한 관심이 높아지면서 다양한 PC 기반의 소프트웨어에 적용되고 있는 추세이고, 모바일 디바이스 사용의 증가는 UI/UX에 대한 또 다른 수요를 나타내고 있다. 특히, 웹 브라우저 위주의 PC 기반에 비해 다양한 디바이스의 크기, 환경과 특정할 수 없는 사용자의 특성이 너무나 다양하게 나타나고 있어 사용자 경험을 반영하는 UX에 대한 중요성이 더 커지는 추세다. 이번 회에서는 모바일 소프트웨어에 UX를 적용하는 방법에 대해 살펴보도록 한다. 적용 방법을 잘 이해하여 모바일 소프트웨어의 사용성을 높일 수 있기를 기대한다.
사례 연구 전 확인 사항
UX의 정의
UX에 대한 정의는 많은 사람들이 혼돈하기 쉽다. 사전적인 의미로는 “어떤 제품을 사용하면서 느끼고 생각하는 모든 경험”을 말한다. 제품 또는 소프트웨어를 통해 사용자가 겪게 되는 경험을 나타내는 것이고, 다양한 사용자의 이러한 경험들을 모아서 표준적인 UX를 만들게 되는 것이다.
UI와 비교하여 정의해보면, UI는 화면의 레이아웃이나 시각적인 디자인, 소프트웨어의 브랜드 등을 나타내는 것이고, 더 심화해서는 사용자의 네비게이션 정도를 보여준다. 따라서, UI는 디자이너 관점이 많이 적용되고, 시각적인 것에 치중하게 된다. 이에 반해 UX는 그 동안 사용하던 사용자의 경험을 반영하기 때문에 디자이너보다는 사용자 관점이 전적으로 반영되고, 특히 사용자와 소프트웨어 간 상호작용에 대한 디자인을 많이 고민하게 된다(그림1).
<그림1> UI와 UX의 비교
출처: https://www.devsaran.com
UX의 프로세스 UX를 디자인하기 위해서는 사용자의 경험을 찾아내어 정리하는 것이 매우 중요하다. 사용자를 조사하여 문제와 경험을 이해하여 인사이트(Insight)를 찾아내고, 비전 수립 후 스케치와 프로토타입을 반복하여 최적의 사용자 경험을 도출하고 검증한다. 만들어진 사용자 경험을 디자인 한다(그림2).
21th SW Quality Insight 컨퍼런스 강의영상 - 소프트웨어 테스팅 분야 품질 개선 사례
11월 29일 화요일! 22nd SW Quality Insight Conference가 코엑스에서 열립니다.
지난 21st SW Quality Insight Conference 강의 영상을 공개합니다.
ALM 환경 품질 개선을 중심으로 살펴본 Agile 방법론 적용 성공 사례 (4)
How? Deployment
Collaboration Center Map
User Guide : FAQ, Help, User Manual
Information : Notice, Software Magazine, Developer’s Sharing
Training Course : Basic User Practices, Advanced Workshop
Consulting & Assets : On-Site Support, Template, Checklist, Practices
How? Operation
User Support Process (Support Tracker)
Server/Storage/Software Operation Process (storage, software upgrade, etc.)
Reorganization Reflection Process (annual, Jan.)
Data Archiving Process (annual, every Feb.)
Backup/Restore Process (annual failure simulation training, occasional)
Failure Operation Process
Plugin Install/Upgrade Process
App. Install/Upgrade Process
How? Development
User / Group Management
•Active Directory based User Registration (User Register)
•User Group Management by Project Administrator (Project Group Manager)
•User Group Management by organization (Enterprise Group Manager)
•Display User Organization in Tracker
Customized Features
•Customized Header Service (Header Config)
•Customized Jira Gadget Plugins
•Large-scale XLM Data Export from Tracker/Collab (Data Service)
•Source Code – Issue Interface Service (Git Indexer)
•Source Code Status Dashboard(Repository-Dashboard/Collector)
Collaboration Center Map
User Guide : FAQ, Help, User Manual
Information : Notice, Software Magazine, Developer’s Sharing
Training Course : Basic User Practices, Advanced Workshop
Consulting & Assets : On-Site Support, Template, Checklist, Practices
How? Operation
User Support Process (Support Tracker)
Server/Storage/Software Operation Process (storage, software upgrade, etc.)
Reorganization Reflection Process (annual, Jan.)
Data Archiving Process (annual, every Feb.)
Backup/Restore Process (annual failure simulation training, occasional)
Failure Operation Process
Plugin Install/Upgrade Process
App. Install/Upgrade Process
How? Development
User / Group Management
•Active Directory based User Registration (User Register)
•User Group Management by Project Administrator (Project Group Manager)
•User Group Management by organization (Enterprise Group Manager)
•Display User Organization in Tracker
Customized Features
•Customized Header Service (Header Config)
•Customized Jira Gadget Plugins
•Large-scale XLM Data Export from Tracker/Collab (Data Service)
•Source Code – Issue Interface Service (Git Indexer)
•Source Code Status Dashboard(Repository-Dashboard/Collector)
2016년 11월 24일 목요일
침체된 SI 시장의 변화 방향
기업에서 시스템을 사용하기 위해서는 일반적으로 SI(System Integration) 프로젝트를 발주한다. 자신들의 업무에 맞는 통합 시스템을 만들기 위해서다. 2000년을 전후하여 SI 사업은 최고의 호황을 누렸지만 최근 들어 사업 규모나 인력 규모 면에서도 줄어드는 추세다. SI 프로젝트가 소프트웨어 산업을 이끌던 시대에서 성장률을 낮추는 요인이 되고 있다. 이번 회에서는 로만소프트 이영환 대표를 만나 SI 시장의 침체 원인과 변화 방향에 대해 알아본다.
Q: 안녕하세요. SI 프로젝트의 PM 경험이 많으신 것으로 압니다. SI 프로젝트의 어려움에 대해서는 많은 사람들이 오래 전부터 잘 알고 있지만 개선이 마음처럼 안 되는 것도 사실인 것 같습니다.
네 맞습니다. 대다수의 사람들이 소프트웨어 개발 회사하면 구글이나 애플, 마이크로소프트처럼 패키지성 소프트웨어를 상상하는데요. 실제로는 SI 프로젝트가 많은 것이 사실이지요. 자기네 회사에 근무하면서 개발하는 것에 비해 SI 프로젝트는 일하는 장소나 고객과 함께 있기 때문에 많은 제약 속에서 개발자가 있는 것이 사실입니다. 소프트웨어 개발자는 영원한 “을”이라는 말을 자주 하는데, 고객의 요구사항을 받아서 소프트웨어로 만드는 것이 기본이기 때문에 당연한 숙명 정도로 해석하고 있습니다. 그래도 예전보다는 환경이 많이 나아지는 상태입니다.
Q: SI 프로젝트가 침체되는 이유가 무엇일까요?
SI 시장은 2015년을 기점으로 성장세가 매우 주춤한다는 보고가 있습니다. 그림1에서 보는 것처럼 막대로 표시된 매출은 다소 상승하고 있지만, 꺾은 선으로 표시된 성장세는 계속 둔화되는 것을 볼 수 있습니다.
<그림1> 국내 SI 시장의 전망
출처: IDC
이렇게 성장세가 둔화되는 것은 여러 이유가 있겠지만, IT 산업의 주요 패러다임이 변하는 것으로 봐야 할 것입니다. 소프트웨어 규모가 점점 줄어들고 있고, PC보다는 모바일 중심의 소프트웨어가 발전되고 있습니다. 그만큼 대형 프로젝트가 줄어든다고 볼 수 있지요. 물론, SI는 대기업 중심의 대형 프로젝트가 많았는데, 공공 사업 제한 등으로 대기업 참여의 기회가 줄어든 것도 있겠지요. 하지만, 근본적인 이유는 방금 말씀 드린 패러다임의 변화가 큰 요인이라고 볼 수 있습니다. 모든 서비스가 모바일 위주로 옮겨가기 때문에 소프트웨어도 그에 맞춰 변해야 하고, 단독으로 사용하던 대형 시스템은 오픈 소스나 솔루션 도입 등으로 직접 개발하는 부분은 점차 소형화되는 것이지요. SI 프로젝트에서 소프트웨어가 오랫동안 만들어지다 보니 만들어지는 형태가 어느 정도 안정화되어 비슷하게 나오게 되어 표준화된 소프트웨어가 많이 알려지게 됩니다. 그림2와 같이 소프트웨어를 자산화하거나 프레임워크와 같이 개발자가 쉽게 접근할 수 있는 도구들이 나오는 것이지요. 이런 것들이 SI 프로젝트 규모를 조금씩 낮추는 역할을 하기도 합니다.
21th SW Quality Insight 컨퍼런스 강의영상 - 인공지능과 SW공학
11월 29일 화요일! 22nd SW Quality Insight Conference가 코엑스에서 열립니다.
지난 21st SW Quality Insight Conference 강의 영상을 공개합니다.
ALM 환경 품질 개선을 중심으로 살펴본 Agile 방법론 적용 성공 사례 (3)
Agile을 적용한 ALM 사례 – A사
Why? Problems
Strong needs of development & collaboration environment suitable for smart products
•Increase of software size (10 times bigger in every six year※)
•Increase of large scale projects with hundred of developers
Exposure of communication and productivity issues in the harsh development environment
•Global development with overseas R&D Lab.
•Collaboration with not only software teams but also non-software organizations
Lake of the importance and awareness for development & collaboration environment
•Lake of investment and support for software engineering tools
•No proper organization (role) to lead software engineering tools
Why? Considerations
Main Questions :
•Who are the main users?
•What services are needed?
•What solution is the best?
Main Scope :
•Tracker (JIRA): Req. Management, Change Request, WBS, Bug Tracking
•Collaboration (Confluence): Documentation, Project Management, Information
•Repos (Git/SVN): Version Control, Code Review, Code Browsing
Why? Problems
Strong needs of development & collaboration environment suitable for smart products
•Increase of software size (10 times bigger in every six year※)
•Increase of large scale projects with hundred of developers
Exposure of communication and productivity issues in the harsh development environment
•Global development with overseas R&D Lab.
•Collaboration with not only software teams but also non-software organizations
Lake of the importance and awareness for development & collaboration environment
•Lake of investment and support for software engineering tools
•No proper organization (role) to lead software engineering tools
Why? Considerations
Main Questions :
•Who are the main users?
•What services are needed?
•What solution is the best?
Main Scope :
•Tracker (JIRA): Req. Management, Change Request, WBS, Bug Tracking
•Collaboration (Confluence): Documentation, Project Management, Information
•Repos (Git/SVN): Version Control, Code Review, Code Browsing
2016년 11월 23일 수요일
모바일을 이용한 헬스케어 시장의 변화
질병이 생겨야 치료를 받던 시대에서 질병이 발생하기 전에 건강을 유지하도록 도와주는 헬스케어(Healthcare) 시장이 확대되고 있다. 건강검진 정도에 그쳤던 지난 시절에 비해 모바일의 발전은 헬스케어 서비스를 실시간으로 제공할 수 있게 되었고, 모바일을 통한 헬스 데이터 수집은 빅데이터를 통해 새로운 의료 분야로 발전을 거듭하는 중이다. 이번 회에서는 모바일 기반의 헬스케어 시장에 대해 살펴보기로 한다.
모바일 헬스케어의 산업 현황
2015년 미국이 의료기기와 연동 가능한 모바일 헬스케어 애플리케이션(앱; Application)을 공식 승인했다. 지난 2013년 모바일 헬스케어 앱 규제를 강화한 이후 2년 만이다. 미국 식품의약국(FDA)이 의료기기 전문 업체 덱스콤이 내놓은 모바일 헬스케어 시스템 ‘덱스콤 셰어 시스템’을 공식 승인한 것이다. 이미 유사한 서비스들이 있지만 FDA의 공식 승인을 받은 것은 지난 2013년 모바일 헬스케어 앱 규제 강화 이후 처음이었다.
2014년 세계 보건산업시장은 14조 달러 규모로 세계 GDP 대비 18.1%의 큰 시장이 형성되어 있으며, 17년까지 연간 5.3% 이상의 규모로 빠르게 성장할 것이라고 전망하고 하였다. 인구 고령화에 따른 진료비 부담에 대한 대안으로 ICT와 의료를 융합한 헬스케어로 의료비 절감이 가능해졌고, 의료 서비스는 사후 치료에서 사전 예방 및 건강관리로 전환되며 개인 맞춤형 서비스로 패러다임이 변화하고 있다.
<그림1> 세계 모바일 헬스기기 시장의 규모 전망
출처: 럭스연구소
모바일 스마트 디바이스와 센서의 대중화로, 헬스케어는 건강 관리 차원에서 이러한 변화를 주도할 서비스로 주목되고 있고, 2014년 세계 스마트폰 보급률은 24.5%로, PC 보급률 20%를 넘어선 상태이기 때문에 다양한 헬스케어 제품 시장 중에서 특히 모바일 헬스케어 관련 제품은 빠르게 확대될 전망이다. 15년 30억 달러에서 18년 80억 달러 규모로 성장할 것으로 기대되고 있다.
21th SW Quality Insight 컨퍼런스 강의영상 - 인공지능과 SW공학
11월 29일 화요일! 22nd SW Quality Insight Conference가 코엑스에서 열립니다.
지난 21st SW Quality Insight Conference 강의 영상을 공개합니다.
2016년 11월 22일 화요일
21th SW Quality Insight 컨퍼런스 강의영상 - 스마트디바이스 미래 융합미디어산업
11월 29일 화요일! 22nd SW Quality Insight Conference가 코엑스에서 열립니다.
지난 21st SW Quality Insight Conference 강의 영상을 공개합니다.
2016년 11월 21일 월요일
애플(Apple)의 HIG(Human Interface Guidelines)
출처: NHN - iOS Human Interface Guidelines 애플에는 iOS 기반으로 앱(Application)을 만들 때 몇 가지 원칙을 제공하고 있다. 미적 조화(Aesthetic Integrity), 일관성(Consistency), 조작성(Direct Manipulation), 반응성(Feedback), 은유성(Metaphors), 통제성(User Control) 등 6가지이다. 6가지를 종합해보면, 사용자가 바라보는 관점이고, 쉽게 이해가 되고, 쉽게 조작할 수 있게 만들도록 되어 있다.
<참고사이트>
애플의 HIG를 기준으로 앱을 설계할 때, UI, UX를 디자인하는 방법은 앞에서 살펴보았던 모바일 소프트웨어 UX 프로세스와 유사하다. 사용자가 필요로 하는 기능을 확인하고, UX 비전을 수립한 후, UX를 디자인하고, 앱의 기능을 확인하여 이상이 없을 경우 출시하게 된다(그림6). 아래는 HIG에서 제시하는 적용 사례를 말하고 있다.
<그림6> HIG 기준 UI, UX 디자인 방법
모바일 소프트웨어의 UX
모바일 소프트웨어에서 UX가 더 강조되는 이유는 작은 화면으로 소프트웨어를 사용해야 하고 항상 휴대를 하고 있기 때문에 원하는 정보만 직관적으로 신속하게 보여주고 반응해야 한다. 또, 더 많이 구매되고 설치되기 때문에 불특정 다수의 경험을 표준화하여 반영해야 한다.
모바일 디바이스의 성장으로 인해 UX는 “Mobile First” 디자인이 늘어나는 추세다. PC 기반에서의 대표적인 변화는 “Touch”일 것이다. 단순한 버튼 클릭의 명령이 아닌 손가락을 통한 다양한 명령들이 입력되는 것이 모바일 UX의 대표적인 변화다. 또 다른 변화는 “Simple Text”와 “Powerful Image”다. 최대한 간결한 문자나 문장을 사용해서 많은 의미를 전달해야 하고, 효과적인 이미지를 통해 강력한 의미를 함축적으로 전달해야 하는 것이 모바일 소프트웨어 UX의 큰 변화 방향이다. 이 방향을 기준으로 모바일 소프트웨어 UX를 디자인하기 위해 필요한 원칙과 방법이 그림4와 그림5에 나타나 있다.
<그림4> 모바일 소프트웨어 UX 디자인 원칙
그림4를 살펴보면, 사용자 관점에서 보고 싶은 것이 잘 보이게 배치가 되어야 하고, 사용자의 행동과 상황, 반응을 예측해서 쉽고 빠르고 직관적으로 대응되어야 한다. 그리고, 사용자가 비정상적인 행동으로 오류를 발생시켜도 소프트웨어는 정상 작동되도록 해야 한다. 이 모든 것을 개발 중에도 지속적으로 사용자 의견을 받아 반영하는 것이 좋다.
UX 디자인에서 고려해야 할 사항
시각적인 것을 중요시하는 UI와는 달리, 사용자의 사용성을 중요시 하는 UX를 디자인 하는데 고려해야 할 것으로 세가지를 들 수 있다. 사용자가 경험에 대해 일반적인 사람은 어떤 반응을 보이는지, 업무적인 측면을 고려하면 어떤 형태로 정리될 수 있는지, 상호작용을 하는 주체는 누구인지를 종합적으로 바라보면서 정리해야 한다(그림3).
<그림3> UX에서 고려해야 하는 사항
출처: nectardesign.com
먼저, 일반적인 사람의 반응을 고려하는 것은, 사용자 경험에 대한 사람들의 감정(feeling), 태도(Attitude), 행동(Behavior)을 살펴봐야 한다는 것이다. 여기서 말하는 일반적인 사람은 특정 사용자가 아닌, 해당 소프트웨어를 사용하게 되는 보편적인 사람을 말한다.
다음으로, 업무적인 측면을 고려하는 것은, 사용자의 판단에 의한 경험도 필요하지만 정형화된 틀에 맞춰야 하는 것이 있는지 살펴보는 것이다. 특히, 기업에서 사용되는 그룹웨어 같은 업무에 필요한 소프트웨어나 사용자가 반드시 지켜야 하는 규칙을 가지고 있는 소프트웨어에서는 심도 있게 고민되어야 한다.
마지막으로 상호작용에 대해 고려해야 하는 것은, 사용자가 명령을 내리고 소프트웨어는 명령을 수행하는 단순한 인터페이스가 아니라 사용자가 소프트웨어에 대해 충분히 경험할 수 있도록 상호작용의 범위를 확대해야 한다.
2016년 11월 18일 금요일
21th SW Quality Insight 컨퍼런스 강의영상 특별강연
11월 29일 화요일! 22nd SW Quality Insight Conference가 코엑스에서 열립니다.
지난 21st SW Quality Insight Conference 강의 영상을 공개합니다.
4th Industrial Revolution - User Expectations
A Communications Revolution? 24 hr two-way communication
4th Industrial Revolution - User Expectations…
Following the same old path…
4th Industrial Revolution - User Expectations…
Following the same old path…
2016년 11월 17일 목요일
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
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 행사가 있습니다. 이 결함 트리 분석 도구를 가지고 보안과 안전에 대해 얘기할 것입니다.
2016년 11월 16일 수요일
모바일 페이먼트에 필요한 기술 요소
최근 전세계 모바일 페이먼트(지급결제; 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 기술 개념
피드 구독하기:
글
(
Atom
)