2015년 8월 29일 토요일

[소프트웨어 프로세스 품질인증]

품질인증 기준 및 심사준비 가이드


1. 품질인증 기준

2. 심사 준비 가이드
   I. 소프트웨어프로세스 품질인증 제도
  II. 소프트웨어프로세스 품질인증 기준
 III. 소프트웨어프로세스 품질인증 심사
 IV. 소프트웨어프로세스 품질인증 획득

Summary
소프트웨어프로세스 품질인증 제도(이하 ‘프로세스 인증제도’라 한다.)는 소프트웨어 기업 및 개발조직의 소프트웨어프로세스(프로젝트 관리, 개 발, 지원, 조직 관리, 프로세스 개선) 품질역량 수준을 심사하여 등급을 판정하는 제도입니다.

프로세스 인증제도는 소프트웨어 및 정보시스템을 개발 관리하는 국내 소프트웨어 기업 및 개발조직의 소프트웨어프로세스 품질 향상과 신뢰성 확보를 목적으로 제정되었습니다. 소프트웨어프로세스 품질인증 제도는 소프트웨어프로세스 품질인증 기관(인증기관), 소프트웨어프로세스 품질인증 기준(인증기준), 소프트웨어 프로세스 품질인증 지침(인증지침)의 3가지 구성요소로 운영됩니다.


성공적인 유저 인터페이스 디자인을 위한 8가지 기본원칙

애플리케이션을 개발하고, 출시한 뒤에 시장 반응에 의해 실망해 본 경험은 누구나 있을 것 입니다. 마케팅에 시간과 돈을 많이 투자한다고 해서 볼품없고 헷갈리며 불친절한 유저 인터페이스가 극복되는 것은 아닙니다. 즉, 유저 인터페이스가 애플리케이션의 성패를 좌우합니다. 예를 들어, 모두가 애플과 같이 될 수는 없으나 가장 친절하고 매력적이며 눈길을 끌고 간단한 유저 인터페이스를 지향할 수는 있습니다. 유저 인터페이스의 성공적인 원칙은 다음과 같습니다.

유저 (User) 를 이해하라
만약 사용자를 설득하기 원한다면, 유저의 마음을 이해하는 것이 필요함. 즉,‘ 사용자는 누구인가’에서 시작해서‘유저는 무엇이 필요한지’를 생각한다면 거기에서부터 작업은 향상됨.

단순한 것이 아름답다
유저 인터페이스를 디자인할 때 단순함은 핵심임에 따라 유저 인터페이스에 화려함을 덧붙이기 전에‘ 이것이 필수적인가’또는‘이것이 인터페이스에 실질적으로 어떤 것을 덧붙여주는가’를 스스로에게 질문해야 함. 가장 좋은 유저 인터페이스 디자인은 가장 단순한 것임.

색 (Color) 을 현명하게 사용하라
색은 특히‘행동의 촉구’가 되도록 제작된 특별한 요소들로 관심을 이끄는 분명한 방법임. 빨간색이 좋은 예로, 빨간색은 행동의 색으로‘지금 다운로드’, ‘지금 플레이’, ‘여기를 클릭’에 주목할 것을 요구하나 빨간색은 또한 위험의 의미와 연관되어 있기 때문에 빨간색을 남용하면 안 됨.

일관성을 유지하라
당신의 유저를 안심시킬 수 있기 때문에 일관성은 필수적인 것임 . 폰트와 레이아웃에서부터 언어와 주제에 이르기까지 일관성은 모든 곳에서 요구됨.

처음 사용하는 유저를 도와줘라
처음 사용하는 유저를 사용안내 비디오테이프에 맡기거나 , 유저가 거의 방문하지 않는 헬프 데스크로 보내는 대신 , 유저를 안내할 수 있는 “ 온디멘드 (on demand)” 설명서를 첨부하는 것이 좋음 . 이러한 설명서는 GPS 나 관광가이드와 같은 역할을 하는 것으로써 , 앱의 핵심적인 특징들 사이로 유저를 호위하거나 유저가 임무를 완수하도록 도와줌.

유저의 성과를 인정하라
유저가 숙달되는 순간 , 인터페이스는 유저에게 보상하고 유저의 성과를 인정해야 함 . 더 이상 복잡한 과제에 실패하게 하지 말고 , 유저는 비교적 빨리 키보드를 손쉽게 사용하고 인터페이스의 복잡한 측면을 사용하는 것에 익숙해지도록 해야 함.

시험하고 반복하라
계속적으로 변하는 유저 인터페이스 때문에 유저를 멀어지게 만드는 것은 결코 바람직한 것이 아니지만 , 5 년 동안 똑같은 유저 인터페이스를 유지하는 것 역시 바람직하지 않기 때문에 경쟁자들이 앞서게 될 것임 . 모든 사람이 웹사이트의 특별한 디자인에 애착을 가질 수 있으나 , 그것들은 때때로 수정되고 업데이트되고 손질될 필요가 있음.

포기하지 말라 
유저 인터페이스 디자인은 예술이자 과학임 . 최고의 유저 인터페이스를 디자인하고자 할 때 모든 가변성과 더불어 문제들에 직면할 것임 . 첫 번째 , 두 번째 , 세 번째 그리고 아마 네 번째 장애물조차 걸려 넘어진다고 해서 , 이것이 프로젝트를 계속해서는 안 된다는 것을 의미하는 것은 아님.

Predicting Software Quality: SW 품질 예측 방법

품질은 SW 개발에 있어 탁월한 설계 , 사용용이성 , 속도 , 안정성 , 보안 , 정확성 등을 생각나게 하는 긍정적인 단어입니다 . 이러한 속성들 중 몇 가지는 측정가능하고 , 몇 가지는 주관적이라 할 수 있습니다 . 우리는 이러한 요소들을 통틀어 품질이라고 부릅니다 . 보편적인 이 관점에서 결함이 적을수록 높은 품질을 의미합니다 . 결함 /KLOC(kilo lines of code), 평균고장수명 (Mean time to failure) 과 같은 척도 (measure) 는 이러한 개념을 가지고 있습니다 . 유용한 척도의 결과 값이 좋으면 소프트웨어에 문제가 없다는 것을 나타내고 , 품질이 좋다고 이해합니다 .

용인되는 수준의 품질은 부수적인 결함들이 많다는 것을 의미하진 않습니다 . 중요한 것은 소프트웨어 패키지가 특색이 많고 , 많이 사용되어지고 , 적당한 가격을 가지는 것입니다 . 이것들로 판매자는 이익을 내고 시장 지배력을 가집니다 . 패키지를 사용하면서 사용자들이 부딪히는 문제들이 패키지를 사용하지 않는 것보다 낮은 수준일 때 , 제품의 품질을 용인되는 ( 받아들일 만한 ) 수준이라고 합니다 .

2015년 8월 28일 금요일

사용자경험 분석 시 범하기 쉬운 5가지 흔한 실수

애자일 소프트웨어 개발 방법론을 사용할 때, User Story를 사용해서 대부분의 요구사항을 수집합니다. User Story는 "의사소통 대상과 대상별 요구사항“의 간결한 형태와 수락기준으로 구성됩니다. User Story는 간결하지만 잘 작성하는 것이 무척 어려운 작업입니다. User Story 작성 시 흔히 범하는 5가지를 실수를 검토해봄으로써 올바른 User Story 작성법을 살펴보도록 합니다.

[5 가지 흔한 실수들]

1. 단일 사용자를 위한 User Story
  • 예 : “ 사용자로써 나는 광고를 관리할 수 있기 원한다 . 왜냐하면 기한이 만료되고 실수가 있는 광고를 제거할 수 있기 때문이다 .”
  • 언뜻 보면 모든 요소가 있어서 User Story 로 별 문제가 없어 보임
  • 특색에 맞게 사용자를 살펴보면 광고관리를 이해하고 수행하는 사용자는 광고 조정을 하는 포탈 관리자나 모든 광고 목록을 가지고 상황에 따라 광고들을 교체하는 광고주들을 뜻함
  • 페르소나나 역할을 놓치고 있음
2. 제품 소유자를 위한 User Story
  • 예 : “ 제품의 소유자로써 나는 광고를 지울 수 있는 시스템을 원한다 . 왜나하면 사용자들이 광고를 지울 수 있기 때문이다 .”
  • 모든 요소들이 있지만 뭔가 어색함
  • ‘ 당신이 무엇을 원한다 . 당신은 그것을 가지고 있다 ’ 는 형식으로 User Story 를 쓰는 사람이 단지 하고 싶은 행위에 초점을 두고 있으며 , 사용자 기대에 대한 단서를 주는 역할이나 페르소나가 없음
3. 개발자를 위한 User Story
  • 예 : “ 개발자로써 나는 폴더 위젯을 재배치하기를 원한다 . 왜냐하면 나는 폴더 위젯을 유지하고 싶기 때문이다 .”
  • 기술적인 백로그 (Technical backlog) 나 기술적인 요구사항의 대표하는 예임
  • 이와 같은 User Story 는 기술적 채무 (Technical Debt) 으로도 불리며 , 기술적 채무는 소프트웨어 업데이트 , 리팩토링 (Refactoring), 프레임웍의 교체와 같은 유지보수 관련 필수적인 일을 포함함
  • 고객을 위한 가치를 대변하지는 않고 , 애자일 관점에서 매 주기의 마지막에 비즈니스적 가치를 수반해함
  • 역할에 페르소나를 붙여 사용자관점에서 기술하는 예로 ‘ 상업적인 사용자로서 나는 동시에 여러 검색을 할 수 있는 시스템을 원한다 . 왜냐하면 나는 일을 좀 더 빨리 하고 싶기 때문이다 .’ 를 둘 수 있음
  • 수락기준들은 향상을 측정 가능하고 테스트 가능하도록 정의해야 함
  • 예 : ‘ 한 사용자가 동시에 5 가지 검색을 할 수 있음 ’
4. 고객을 위한 비즈니스 가치나 혜택이 없음
  • 예 : “ 상업 광고주로써 나는 필터링 옵션을 원한다 ”
  • 역할도 있고 니즈도 있지만 이유와 비즈니스 가치가 없음
5. 수락기준이나 만족조건이 없음
  • 수락기준이 없는 것은 개발업무를 잘못 정의하거나 잘못된 평가로 시작해서 전체를 오류덩어리로 만들 수 있음
  • 이해부족으로 Story 가 테스트를 통과하지 못할 수도 있고 Test Case 가 다른 기준들을 적용할 수도 있음
  • 수락기준은 요구사항을 명확하게 이해하고 주기별 결과물을 받아들일지는 결정하는 중요한 역할을 함
  • 수락기준을 만드는 좋은 방법은 '~ 한다면 어떻게 될까 ?(What if ... ?)', ' 어디서 (Where) ...?', ' 언제 (When) ... ?', ' 어떻게 (How) ... ?' 와 같은 질문을 해보는 것임
  • 예제들을 사용해서 가정들을 제거해서 간결하게 만들어보면 Story 가 세련되어지고 재구성되고 좀 더 작은 Story 로 나뉘어질 것임 

애자일 프로젝트 매니저가 갖춰야 할 3가지 필요기술

애자일 프로세스의 도입은 SW공학과 IT 프로젝트 측면에서 폭발적으로 늘고 있습니다. 애자일 프로젝트 매니저는 팀을 성공적으로 이끌기 위해서 애자일 기법들에 제대로 이해하고 사용해야 합니다. 사용자 경험 분석 등 요구사항분석을 통해 업무를 정의하고, Burn-down, Burn-up 차트 등을 이용하여 일의 진행사항을 체크하고, 용어의 통일이나 클라우드 컴퓨팅 등을 활용하여 팀 전체간의 의사소통을 원활하게 등 애자일 기법과 툴을 잘 활용해야 합니다.

*애자일 기본사항 (Agile fundamentals)
애자일 ALM 에서 프로젝트 매니저는 개발팀이 사용하고 있는 개발 프레임웍 (Scrum, XP, Kanban or 애자일 기법 조합 ) 에 대해 잘 이해하고 있어야 함.

추적 (Tracking) 과 척도 (Metric)
애자일 ALM 에서 프로젝트 매니저 훈련의 중요한 부분은 일의 진행사항을 추적하는데 사용되는 척도를 명확하게 이해하는 것임.

협업 (Collaboration)
애자일 기법들을 제대로 이해하고 진행상황을 올바로 측정하고 추적하는 것과 더불어 애자일 ALM 환경 상에서 프로젝트 매니저는 협업의 중요성을 잘 이해해야 함.

성공적인 요구사항관리를 위한 3가지 커뮤니케이션(협업) 유형

협업은 요구사항을 관리하는데 매우 중요한 요소입니다. 협업은 SW 개발자와 최종 사용자간의 협업, 고객 그룹들 사이의 협업, 회사 내부적인 협업의 3가지 형태가 있습니다. 이 3가지 형태의 협업을 잘 활용하여 요구사항을 효과적으로 관리하는 것은 경쟁력 있는 SW를 개발하는 데 도움이 됩니다.

◆ 세 가지 형태의 협업유형
  • 첫 번째 형태는 SW 개발자와 최종 사용자간의 대화임.
  • 두 번째 형태는 고객 그룹 사이에 활발하게 나타나는 의사소통임.
  • 세 번째 형태는 회사 내부적으로 발생하는 의사소통임.

2015년 8월 27일 목요일

소프트웨어 모델링

모델 존재의 이유
<문제와 답 사이의 디딤돌>
  • 문제와 연결성
  • 답과의 연결성
  • 모델 자체의 완전성 및 정확성



자세히 보기 →

사물인터넷(IOT) 주요 요소 기술

한 통신사가 ‘IoT’라는 용어를 TV광고전면에 내세우면서, 이제는 일반인에게도 ‘뭔지 잘 몰라도, 한번쯤은 들어 본’ IT전문 용어가 되었습니다. 사물인터넷-IoT는 ‘Internet of Things’의 약자로, 생활 속 사물들을 유무선 네트워크로 연결해 정보를 공유하는 환경을 말합니다. 쉽게 말하자면, 냉장고의 센서가 음식의 바코드를 읽어 유통기한을 알려주고, 집안의 보일러나 조명의 On-off 기능을 집밖에서도 스마트폰으로 컨트롤 할 수 있는 기술입니다. 쇼핑몰에 들어서는 순간 쇼핑정보가 제시되고, 관심 있는 상품 앞에 서면 상품의 상세 정보가 보이는 것도 가능합니다. 미국 벤처기업 코벤티스가 개발한 심장박동 모니터링 기계, 구글의 구글 글라스 등도 이 기술을 기반으로 만들어졌는데, 전자기기뿐만 아니라 헬스케어, 원격검침, 스마트홈, 스마트카 등 다양한 분야에서 사용됩니다. 현재, IT 변화의 주역은 IoT라고 해도 과언이 아닐 정도로 특히 가전업계에서 ‘미래 먹거리’로 주목 받고 있습니다. 스마트가전 시장이 올해부터 향후 5년간 연평균 134%의 높은 성장률을 기록할 것이라는 시장조사기관 IHS의 발표가 이를 뒷받침하고 있습니다. 임베디드 시스템 프로그래머로 활동하고 있는 장성균 개발자로부터 IoT 기술에 대해 깊은 이야기를 들을 수 있었습니다.

핀테크 서비스를 위한 소프트웨어 품질관리 포인트

정보기술(IT)을 금융에 접목한 핀테크(FinTech; Financial Technique)는 모바일 송금/결제, 온라인 간편결제, 전자화폐, 인터넷은행, 크라우드 펀딩 등과 같은 금융서비스를 말하고 있으며 최근에는 그 중에서도 모바일 결제에 관심이 높아지고 있습니다. 미국의 페이팔과 애플페이, 중국의 알리페이 등이 선두주자로 앞서나가고 있으며, 우리나라에서는 3개 통신사의 스마트월렛, 모카월렛과 카카오페이 등이 서비스 중이며, 삼성페이가 출시를 앞두고 있습니다. 핀테크는 여러 가지의 금융서비스를 미리 등록한 핀테크 서비스로 통합하여 사용하는 것을 기본으로 하고 있습니다. 이러한 이유로 핀테크는 다양한 금융서비스를 연결하는 정보기술과 이에 따른 높은 품질의 아키텍처, 보안 등도 함께 요구하고 있습니다. 이러한 기술들 중에 이번 회에서는 핀테크 시장에서 요구하는 품질을 확보하기 위해 아키텍처와 보안 관점의 품질확보 방안에는 어떠한 것이 있는지 살펴보기로 합니다.

FinTech Architecture

먼저 비즈니스 아키텍처 관점에서 살펴보겠다. 핀테크는 새롭게 만들어진 서비스가 아니라 기존의 금융서비스에 정보기술을 접목한 금융서비스의 변형된 형태라고 할 수 있다. 따라서 비즈니스 아키텍처를 수립할 때, 기존 금융서비스에 대한 이해가 절대적으로 필요하다. <그림1>은 인터넷 전문은행의 비즈니스 아키텍처를 수립하기 전에 기존 서비스가 어떠한 형태로 변화가 생길지 살펴본 것이다.

자료: SK C&C의 인터넷 전문은행 설명회



2015년 8월 26일 수요일

소프트웨어 품질과 소프트웨어의 경제적 가치

SW 품질향상에 따른 소프트웨어의 총 소유비용 (TCO, total cost of ownership) 절감

대규모 소프트웨어 프로젝트는 위험요소가 많은 사업입니다 . 10,000 개 이상의 기능요소 (function point, 대략 1,000,000 line 정도의 코드 ) 을 포함하는 소프트웨어 프로젝트의 절반가량은 중단되거나 예정보다 1 년 이상 지연되기도 합니다 . 문제점들이 있은 소프트웨어 프로젝트를 살펴보면 , 프로젝트의 중단이나 연기는 주로 심각한 결함들 때문에 발생합니다 . 역설적으로 성공적인 대규모 소프트웨어 프로젝트의 특징은 우수한 결함 예방과 결함 제거라 할 수 있습니다 . 최상의 소프트웨어 품질관리는 소프트웨어 프로세스 개선에 가장 중요한 목표입니다 .

대규모 소프트웨어 시스템 개발은 IT 시대에 가장 위험천만한 비즈니스 활동 중의 하나로 오랫동안 인식되어 왔습니다 . 수많은 대규모 소프트웨어 프로젝트들은 중단되거나 예정보다 1 년 이상 지연되고 예산을 100% 나 초과해 진행되기도 했습니다 . 
Software Productivity Research 의 저자와 그 동료들은 1983 년부터 2009 년에 진행된 약 13,000 개의 소프트웨어 프로젝트를 조사하였습니다 . 표 1> 에서는 프로젝트 규모 순으로 6 개로 나누어 조기 , 적기 , 연기 , 중단의 비율을 정리하였습니다 . 

Twitter, Google, Facebook 등에서 활용되는 Top5 오픈소스 웹

웹 애플리케이션 일을 하는 모든 사람들은 호스팅사이트의 레이아웃을 개발하기 위해 많은 시간을 할애하고 있습니다. 새로운 애플리케이션을 호스팅하기 위해 초기부터 사이트를 구축해야 하는 어려움이 있습니다. 이런 점을 해소하기 위해 Twitter, Google, Facebook등에서 활용하고 있는 Top5 오픈소스 기반의 웹 프론트엔드 개발도구를 소개합니다.

Twitter 의 Bootstrap
  • 웹 애플리케이션 개발에 가장 많은 시간이 걸리는 부분은 코딩이 아니라 HTML 와 CSS 그리고 웹 앱이라고 불리는 호스팅할 사이트의 실제 프레젠테이션 레이아웃을 개발하는 것임
  • Twitter 는 이러한 문제를 해결하기 위해 Bootstrap 부트스트랩 (= 홈페이지 제작을 도와주는 오픈소스 기반의 프레임워크 ) 즉 많은 보일러플레이트 (= 재사용 가능한 템플릿 ) 웹 코드를 가진 무료 웹디자인 프레임워크를 구축함

Facebook 의 Codemod
  • Codemod 는 Facebook 이 개발하고 릴리스 하고 있는 오픈 소스 프로젝트들 중 하나로 Facebook 이 수행하는 대부분의 프로젝트들과 마찬가지로 대규모 데이터 유지보수 측면의 생산성을 지원하는 측면에서 데이터와 웹콘텐츠 등을 매우 높은 수준의 레벨로 스케일링하는 것들과 관련이 깊음 이와 같은 이유로 Facebook 이 OS 가 아닌 하드웨어 측면에서의 처리속도를 올리기 위해 PHP 를 C 로 컴파일러하는 HipHop 을 개발하기도 했음
  • Codemod 는 툴이자 라이브러리로서 최대 장점은 리팩토링스 (refactoring=SW 기능을 유지 보수하여 생산성을 향상시키는 기능 / 기법 ) 라고 말할 수 있음
Google 의 ZXing
  • 일명 흑백줄무늬 횡단보도 (=Zebra Crossing) 로 알려져 있는 ZXing(= 안드로이드 바코드 스캐너 ) 은 오픈소스이자 자바로 코딩된 멀티 포맷 1D 와 2D 바코드 이미지 프로세싱 라이브러리임
  • Google 과 ZXing 의 컨트리뷰터들은 프로젝트 C#, C++, Ruby 그리고 아이폰 클라이언트와 객체 -C 라이브러리에 대한 지원을 요구함에 따라 , 여러 언어들을 수용할 수 있는 포트들이 개발됨

Yelp 의 KegMate
  • Yelp 의 엔지니어들은 기호식품으로 맥주를 선택하여 맥주와 아이패드를 결합하는 방법을 찾아내 Yelp KegMate 를 개발하였고 , 이는 일종의 하드웨어와 하드웨어를 제어하는 프로그래밍 기술 그리고 애플리케이션이 결합된 실험적 프로젝트임
  • 이는 하드웨어 , 아두이노 (Arduino, 프로그래밍 가능한 오픈소스 회로기판 ), 플로우 모니터 , 아이패드 또는 안드로이드 타블렛 등을 활용한 새로운 애플리케이션을 개발할 수 있는 단초를 제공함 좀 더 많은 정보를 얻기 원한다면 www.kegbot.org 사이트를 방문

FaceBook 의 Three20
  • CodeMod 를 통해 이미 FaceBook 의 오픈소스 툴을 언급했지만 Three20 라이브러리는 상용화된 아이폰 애플리케이션 개발을 매우 손쉽게 해주는 라이브러리로 앱 개발자들에게 매우 필요하고 볼 수 있음
  •  Three20 은 Facebook, Posterous, Pulse, Meetup.com, SCVNGR 케쥬얼 게임 등을 포함한 앱스토에서 유명한 애플리케이션에서 활용하는 오픈소스 객체지향 프로그래밍 언어인 Objective-C 의 라이브러리임


임베디드 SW 개발 방법론 part 2 : 품질확보를 위한 임베디드 SW 개발 방법

임베디드 Software 개발 방법론 각 Phase 별 상세 Activity 를 살펴보고 , 기존의 Software 개발 프로세스와 비교 분석을 합니다 . 
마지막으로는 품질 확보 측면에서 임베디드 Software 개발 방법론을 분석해 보도록 하겠습니다 .

▣ 임베디드 Software 개발 방법론 Activities

그림 1 은 임베디드 Software 개발 방법론의 프로세스입니다 . 크게 3 개 Phase 로 구분되어 되어 있습니다 . Requirement Analysis, Architecture/Design Phase 는 요구사항 분석 , 아키텍처를 중심으로 하는 Inception Phase 이고 , 코드 구현이 중심이 되는Implementation Phase, 마지막으로 Hardware 와 통합된 후 코드를 최적화하는 Optimization Phase 입니다 . 각 Phase 별로 Activity 들을 살펴보도록 하겠습니다.












▣ Plan-driven 방법론 , Agile 방법론과 임베디드 Software 개발 방법론과의 비교
▣ 임베디드 Software 개발 방법론에서의 품질 검증

2015년 8월 25일 화요일

애플리케이션 모의 해킹(침투 시험), 언제, 어떻게 실행할 것인가

보안을 위해 네트워크뿐만 아니라 애플리케이션 테스트를 강화해야할 필요성이 지속적으로 제기되고 있습니다. 모의 해킹(침투시험: Penetration Testing)은 애플리케이션의 보안상 취약점을 파악하는 조사 방법으로, 애플리케이션 기능, 리소스 가용성 등을 고려하여 애플리케이션 테스트를 적시에 수행해야 합니다.

  • 보안은 기밀성 (Confidentiality), 가용성 (Availability), 안정성 ( Integrity) 으로 요약할 수 있음
  • 모의 해킹 (Penetration Testing) 은 악성사용자가 애플리케이션의 보안을 위협할 수 있는 취약점을 조사하는 테스팅 방법임
  • 애플리케이션 모의 해킹의 최고 방법론으로 OWASP Top Ten 이 있음
  • 팀의 생애주기 , 애플리케이션 기능 , 리소스 가용성 등을 고려하여 테스트를 수행하는 적기는 개발 팀마다 다름

애자일 방법론 vs. 폭포수(Waterfall) 방법론, 10가지 주요 차이점

폭포수(Waterfall) 방법론은 요구사항을 완벽하게 취합하여 계획을 잘 세우고 그 계획대로 진행하는 방법론이며 애자일(Agile)은 요구사항을 초기에 완벽하게 취합하는 것이 불가능하기 때문에 개발 주기를 반복하고 고객과 소통하면서 소프트웨어의 품질을 발전시키는 방법론으로 이 두 가지 방법론의 차이점을 바탕으로 개발 조직에게 적합한 방법론을 적용하는 것이 중요합니다.

  • 폭포수 방법론은 1970 년에 창안된 첫 번째 소프트웨어 개발 방법론이며 애자일 방법론은 폭포수 방법론의 과도한 문서업무 때문에 내재하는 낭비를 줄이고자 1990 년대에 고안된 방법론임
  • 폭포수와 애자일 방법론의 개발전략의 10 가지 기본적인 차이점을 통해 프로젝트에 최적화된 방법론을 적용할 수 있도록 살펴보도록 함

  1. 폭포수 : 미리 정의된 요구사항 vs. 애자일 : 프로젝트 과정에 걸쳐 진화하는 요구사항
  2. 폭포수 : 빅뱅 (Big Band) 릴리즈 vs. 애자일 : 빠른 릴리즈
  3. 폭포수 : 계획 중심 vs. 애자일 : 학습 중심
  4. 폭포수 : 고객과의 드문 의사소통 vs. 애자일 : 고객과의 지속적인 의사소통
  5. 폭포수 : 단계별 중간물 전달 vs. 애자일 : 진행하고 있는 작업본을 지속적으로 전달
  6. 폭포수 : 수평적인 단계별로 개발 vs. 애자일 : 기능별 수직 개발
  7. 폭포수 : 프로그래밍은 단순히 공사와 같음 vs. 애자일 : 프로그래밍은 디자인의 확장임
  8. 폭포수 : 마지막에 통합 vs. 애자일 : 초기와 이후 잦은 통합
  9. 폭포수 : 마지막 단계 테스트 vs. 애자일 : 초기와 이후 잦은 테스트
  10. 폭포수 : 문서화된 진행 사항 진단 vs. 애자일 : 개발하고 있는 소프트웨어로 진행 사항 진단

개발방법론이 개발직무의 동기유발성에 미치는 영향에 대한 분석

애자일방법론은 소프트웨어 개발의 새로운 트렌드입니다 . 오늘날 기업은 빠르게 사용자의 요구변화에 효과적으로 대처하기 위한 노력으로 애자일 방법론을 채택하고 있으며 , 대부분의 경우 , 소프트웨어 개발에 많은 향상이 발생하였습니다 . 일부 연구에서는 , 소프트웨어 개발자의 동기부여가 향상에 기여하는 요인이라고 언급하였습니다 . 그러나 애자일 방법론의 어떤 측면으로 인해 그들이 동기부여가 되지는 아직 알 수 없었습니다 . 본 연구의 목적은 전통적 개발방법론과 애자일 방법론 소프트웨어 개발자의 직무특성 간 잠재적인 동기에 대해 조사 비교하는데 있습니다 . 경험적 분석을 위한 연구 자료는 국내 4 곳의 IT 기업의 77 명의 개발자에 의해 수집되었으며 , 방법론에 따라 개발자의 잠재적인 동기부여에 큰 차이가 있다고 분석되어졌습니다 . 애자일 개발자는 타 방법론 개발자에 비해 더 동기부여가 될 수 있으며 , 개발자의 직무특성이 방법론에 따라 차이가 있는 것을 자세히 보여주었습니다 .

2015년 8월 22일 토요일

제 15차 SP인증을 중심으로 한 SW프로세스 교육


본 교육은 국내 중소 SW기업과 개발 조직의 SW프로세스 품질 향상과 신뢰성 확보에 목적이 있습니다.
SW개발자, 품질 담당자, 테스트 담당자 등을 대상으로 SW프로세스 개념과 SP인증 기준 이해를 바탕으로 실제 업무에 필요한 SW 프로세스 교육을 진행합니다.

미래창조과학부가 주최하고 SW공학센터가 주관하는 금번 교육은 수강생의 경험과 SP인증기준과의 비교 분석을 통해 스스로 SW프로세스 개선점을 체득할 수 있는 실습 기회를 제공합니다.

애자일과 아웃소싱의 효과적 결합을 위한 가이드

애자일 방법론 적용에 있어 그 자체만으로 많은 z문제점과 과제가 있지만 아웃소싱과 결합될 경우에는 공간, 시간, 언어 등의 상이성으로 이러한 문제점들이 배가되고 새로운 문제점들이 나타납니다. 그러나 하이브리드 애자일 모델의 적용, 업무 영역별 업무와 인력 조직 등 다양한 BEST PRACTICE들을 잘 활용함으로써 이러한 문제점을 적절하게 대처한다면 프로젝트를 성공적으로 이끌 것으로 기대됩니다.


  • 하이브리드 애자일 모델을 활용한 선행 리스크 축소
  • 요구사항 영역별로 (requirement areas or features) 아웃소싱을 위한 업무와 인력을 조직화
  • 고객 친화적으로 애자일 방법론을 변형
  • 변경 지시에 의해 놓치는 영역 (runaway scope) 과 요구사항에 대한 관리
  • 교차배치형 (interleaved) 품질 보증 (QA: Quality Assurance)

임베디드 SW 개발 방법론 part 1 : 임베디드 SW 개발 프로세스

애플 , 인텔 등 선진외국기업 적용방법론을 중심으로

90 년대 말 시작된 agile 개발 방법론은 2000 년대 들어와서 다양한 모습으로 개발자들에게 확산되었습니다 . 한편 70 년대 Water 모델로 시작된 Plan-driven 개발 방법론 은 지금도 대규모 프로젝트나 대기업에서 사용하는 주요 개발모델입니다 . 소규모의 프로젝트나 , 개발자들이 한 곳에 모여서 잦은 커뮤니케이션을 통하여 개발하는 경우는 Agile 을 선호하지만 , Agile 특성상 초보개발자들이 많은 경우는 적용하는 것이 나쁜 결과를 가져오는 경우가 있습니다 . 대규모 프로젝트는 Plan-driven 방법론을 선호하지만 , 프로젝트는 소규모로 나누어 Agile 을 적용한 성공 사례 역시 있습니다 . 임베디드 SW 개발은 타 개발과는 다른 몇 가지 특성이 존재합니다 . Hardware 관계성 , 양산 개념 , Software 와 Hardware 통합 아키텍처 등의 요인들로 인하여 , 타 SW 개발과는 다른 도메인 특성을 보입니다 . 그렇다면 , 임베디드 SW 개발은 Agile 와 Plan-Driven 중 어느 개발 방법론이 적합할까 ? 본 원고에서는 임베디드 개발 도메인의 특성을 살펴보고 , 그에 따라 어떤 방법론이 더 적합한 것인지 살펴보고자 합니다 .

  • Agile vs. Plan-driven 개발 방법론
  • 임베디드 SW 개발 방법론

2015년 8월 21일 금요일

클라우드 애플리케이션 퍼포먼스 관리를 위한 10가지 핵심 요소

대부분의 경우 프라이빗 클라우드 서비스에 필요한 애플리케이션이 우선적으로 등장하고, 이후 수요가 점차 증가됨에 따라 퍼블릭 클라우드 서비스와 이를 관리하기 위한 애플리케이션이 등장하게 됩니다. 점차적으로 자체개발이나 아웃소싱한 클라우드 애플리케이션이 늘어나면서 그 퍼포먼스를 모니터링하기 위한 필요성이 나타게 되는데, 클라우드 애플리케이션 퍼포먼스 관리(CAPM : Cloud Application Performance Management)는 사용자 경험을 관리하기 위한 퍼포먼스를 모니터링하고 분석합니다. 2세대 CAPM툴은 모니터링 에이전트를 활용해 근본 원인 분석하고 CAPM의 주요 요소들을 활용함으로써 클라우드 기반 애플리케이션들의 퍼포먼스 향상을 도모할 수 있는 것으로 기대됩니다.

  1. 리소스 vs. 애플리케이션 퍼포먼스 모니터링
  2. 프라이빗과 퍼블릭 인스턴스 (instance)
  3. 토폴러지 ( 네트워크 접속망 ) 탐지 (Topology discovery)
  4. 1 세대 CAPM 툴과 문제점
  5. 2 세대 CAPM 툴과 장점들
  6. 클라우드 애플리케이션 퍼포먼스 컴포넌트
  7. 에이전트와 애플리케이션
  8. 인프라스트럭쳐의 한 부분으로써의 인터넷
  9. Hosted SaaS CAPM 장점
  10. 근본 원인 분석 과제들

RIA를 위한 미디어 지원 기능 비교 : JavaFX 2 대 HTML5

현재 다양한 미디어파일 포맷들을 모두 결합하는 것은 거의 불가능합니다. 그래서 보통 개발자들은 어떤 기술이 어떤 인코딩 테크닉을 지원하는가에 대한 관심보다는 그들의 애플리케이션들이 잘 작동하기만을 원합니다. 맞춤형 미디어 플레이어를 만드는데 유리한 JavaFX와 코덱과 브라우저 지원에 한계가 있지만 미디어스트리밍에 더 나은 유저환경을 만들 수 있는 HTML5는 이러한 문제들을 해결할 기회를 갖는 기술입니다.

소프트웨어 프로세스 개선의 평가 및 측정 - 체계적인 문헌 리뷰

소프트웨어 프로세스 개선 (SPI: Software Process Improvement) 은 소프트웨어 개발 조직의 효율성과 효과를 증대하고 , 소프트웨어 제품을 향상시킬 수 있는 체계적인 접근방법입니다 . 본 논문은 서로 다른 SPI 활동에 사용되는 평가 전략 및 측정법을 식별하고 특성화를 목표로 , 1991 년부터 2008 년 사이에 발표된 148 편의 논문을 분석하였습니다 . 논문들의 체계적인 문헌 리뷰를 통하여 , SPI 활동 , 응용 평가 전략 및 측정 관점에 따라 분류하고 7 가지의 차별화된 평가 전략을 확인하였습니다 .

Ⅰ . 서론
소프트웨어 프로세스 개선 (SPI) 은 제품의 품질을 높이는 것뿐만 아니라 시장 출시 시간과 생산 비용을 줄이는 것을 목적으로 한다 [28]. SPI 관련 기술로는 Capability Maturity Model (CMM)[76], Capability Maturity Model Integration (CMMI)[2], [113], [114], ISO/IEC 15504(SPICE)[35], [111], Quality Improvement Paradigm(QIP)/Experience Factory[7],[8] 등이 있다 . 본 연구와 유사 연구는 다음과 같다 . Gorschek 와 Davis[167] 은 요구사항단계 (requirements process) 에서 변화의 영향은 서로 다른 수준에서 관찰되고 측정할 수 있다는 아이디어를 가지고 프로세스 변화의 영향을 평가하기 위한 개념적 프레임 워크를 제시하였다 . Gomez 등 [48] 은 “ 무엇을 , 어떻게 , 언제 측정하는가 ” 라는 세 가지 질문을 가지고 소프트웨어공학에서 SLR(Systematic Literature Review) 측정을 실시하였다 . Bellini 등 [10] 은 문헌연구를 통해 측정 이론 , 소프트웨어 메트릭스 , 메트릭스의 개발과 식별 , 측정 수집 , 측정의 평가와 분석 등 5 가지 주요 측정항목을 도출하였다 . Kitchenham 과 Charters[60] 는 소프트웨어 메트릭스 연구에서 최근 동향을 설명하기 위해 체계적인 매핑 연구를 실시하였다 . 본 연구에서는 SPI 활동의 측정에 좀 더 중점을 두었으며 프로세스 개선을 평가하고 분석하는데 어떤 측정법이 사용되는지를 조사하였다 .

2015년 8월 20일 목요일

자동화된 클라우드 컴퓨팅 서비스 기획 시 고려해야할 8가지 주요이슈

클라우드 컴퓨팅은 편리성과 비용절감 효과 때문에 최근 몇 년간 기업들의 컴퓨팅 리소스 활용의 주요 화두임. 클라우드 리소스의 효율적인 활용을 위해 자동화 요구가 높아지고 있음. 효과적인 클라우드 자동화를 위한 주요 요건은 
△ 다이나믹 스케일링 자동화, 
△ 동일한 수준의 보안레벨 확보, 
△ 다양한 플랫폼과 외부 클라우드에 대한 서비스 지원,
△ 사용 편의성 등이 있음

클라우드 서비스의 구성 , 실행 및 지속적인 관리에 대한 자동화에 있어 과제는 다음과 같습니다.

1. 다이나믹 스케일링 (Dynamic Scaling) 
- 대부분의 기업들이 빠르게 오프라인 판매 모델에서 온라인 판매로 이동하고 있음에 따라 , 시즌 세일 때는 추가로 웹과 데이터베이스 서버가 필요함 . 트래픽 증가가 일어날 때 빠르고 자동적으로 이를 대응할 수 있는 것이 다이나믹 스케일링의 하나임
- 하이브리드 클라우드는 거의 일반적인 수요 시에 자체 서버를 이용하고 추가적인 컴퓨팅 파워가 필요할 때 퍼블릭 클라우드 서버를 이용하게 구성되어 있음

2. 환경 재구축 (Rebuilds of environments) 
- 만약 대학에서 학생들에게 다양한 강좌를 제공하기 위한 SW 애플리케이션 등을 포함한 컴퓨팅 자원을 제공하기 위해서는 각 학생별로 적합한 교육환경을 재구축해야 할 필요가 있음
- 클라우드 매니지먼트 툴은 마스터 템플릿을 기반으로 쉽고 빠르게 버추얼 컴퓨팅 환경의 실행 및 재구축을 지원함

3. 지속적인 모니터링 및 가용성 관리 (Ongoing monitoring and availability management) 
- 서버의 지속적인 모니터링 및 관리는 자동적으로 작동하지 않는 서버 및 서비스를 제거하고 이를 새로운 자원으로 확보하여 운영할 수 있도록 하는 것이 중요함

4. 보안 (Security)
- 프라이빗 클라우드의 보안 레벨을 퍼블릭 및 하이브리드 클라우드까지 확장시켜야함 . 클라우드 인프라 자동화 관리 툴은 퍼블릭 , 프라이빗 클라우드 서비스 모두에서 위반사항이나 의심스러운 활동을 모니터링하고 이를 보고하는 기능이 있어야 함

5. 다중역할 (Multi-tenancy)
- Multi-tenancy 는 클라우드 인프라 자동화 툴에서 지원해야 하는 사항임 . IT 조직은 많은 외부 기관 또는 동일한 조직 내의 여러 내부 부서에 컴퓨팅 서비스를 제공하는 경우 다양한 사용자를 만족시키는 서비스를 제공하기 위한 다중역할 (Multi-tenancy) 기능이 필요함

6. 단순화 (Simplicity) 
- 클라우드 인프라 자동화 툴은 다양한 종류의 서버와 데이터베이스 관리 툴 , 애플리케이션 소프트웨어 등에서 구동하기 위해서는 구성 및 이용이 단순해야 함

7. 언어 지원 (Language support)
- 많은 클라우드 기반 서비스들은 자바 , MS 의 C++, C# technologies, PERL, Python 과 다양한 언어를 지원해야 함

8. 모바일 백엔드의 신속한 개발 (Rapid development of mobile back ends) 
- 모바일 애플리케이션 , 특히 기업용 애플리케이션은 결국 빠르게 구성되고 실행되는 모바일 백엔드 서버가 필요함 . 클라우드 인프라 자동화 툴은 점점 더 새로운 요구 사항 (Requirement) 들을 지원할 수 있어야 함

클라우드 컴퓨팅을 위한 Java 애플리케이션 데이터 보안

클라우드 컴퓨팅 플랫폼과 서비스는 단 몇 년 만에 Java™ 애플리케이션 개발 환경에 지각변동을 일으켰습니다 . 시스템 유지보수 및 구성과 연관된 장벽을 낮추었고 , 소프트웨어 출시 비용을 절감하는 동시에 시간을 단축하는 뛰어난 성과를 거두었기 때문입니다 . 개념적으로 , 클라우드 컴퓨팅이 충분히 합리적인 건 맞습니다 . 비즈니스 관리자는 ROI 달성을 원하고 , 개발자는 인프라 코드로부터의 자유를 얻기 때문입니다 . 그러나 수많은 개발사에서는 여전히 클라우드 플랫폼으로 이전할지 여부를 두고 고심에 고심을 거듭하고 있습니다 .

데이터 보안은 소프트웨어를 클라우드 인프라로 마이그레이션하는 방안을 고려 중인 조직에게는 주요 관심사 중 하나입니다 . 중요한 데이터일수록 보안을 염려할 이유가 더욱 뚜렷한 법입니다 . 우리는 소프트웨어 개발자로서 , 클라우드 컴퓨팅의 실제 보안 위험과 최소한 이런 문제 중 몇 가지라도 해결하기 위한 현실적 접근법을 모두 이해하는 것이 중요합니다 .

Java development 2.0 시리즈의 이번 회에서는 클라우드에 데이터를 저장하는 것이 중앙 컴퓨터에 저장하는 것과 어떤 점에서 다른지 설명하겠습니다 . 그런 다음 , Java 플랫폼의 기본 제공 개인 키 암호화 표준 및 유틸리티를 사용하여 데이터가 분산형 클라우드 데이터 저장소에 저장되어 있더라도 데이터를 합리적인 수준에서 안전하게 보호하는 방법을 설명하겠습니다 . 마지막으로 , 데이터 암호화 여부에 대한 기준선으로서 쿼리의 조건을 사용하는 전략적 암호화 접근법을 예시와 함께 보여주겠습니다 .

IoT로 살펴보는 소프트웨어 개발 트렌드의 변화

최근에 많은 관심을 받고 있는 IoT(Internet of Things)는 다양한 형태로 해석하고 적용하는 경우가 많지만, IoT의 핵심 내용은 네트워크에 접속한 사물이 스스로 데이터를 수집하고 전달한다는 것입니다. 
이러한 이유로 IoT는 원하는 정보를 언제 어디서나 간편하게 주고받는 환경을 제공합니다. 물론 어떤 종류의 데이터를 어떻게 전달할지는 설계자가 설계를 하게 됩니다. IMS리서치에 따르면 기업들이 사용하는 사물의 약 85% 정도가 네트워크에 연결되지 않은 상태라고 합니다. 아직도 이렇게 많은 사물들을 IoT의 세계로 끌어들이기 위해서는 다양한 사물들을 연결하고 분석한 후 원하는 데이터를 수집할 수 있는 체계적인 기술이 필요합니다. 이러한 기술들 중에 이번 회에서는 IoT 시장에서 추가적으로 필요로 하는 소프트웨어 기술에는 어떠한 것이 있는지 살펴보기로 합니다.

IoT Architecture
<그림1>의 좌측 그림과 같이 IoT의 시초는 각 산업 또는 서비스에서 일부 필요한 데이터만을 수집하여 전달하는 형태였습니다. 따라서 수집 되는 데이터도 매우 적은 양이었고 사용되는 소프트웨어도 단순한 형태가 많았습니다.

<그림1> IoT 모델의 변화














2015년 8월 19일 수요일

동영상 스트리밍 기술 동향(Video Streaming Technology Trends)

2014년 3분기까지 재생된 온라인 동영상 1,770억건을 분석한 결과, 온라인 동영상 소비의 29%는 모바일 기기에서 이뤄진 것으로 나타났습니다. 거의 3분의 1수준입니다. 스마트폰에서는 동영상 재생이 전년 대비 56% 증가했고, 태블릿에서는 27% 증가했습니다(자료: '디지털 비디오 벤치마크' 보고서, 어도비, 2015-01).

 모바일에서 동영상 소비는 광고와 직결됩니다. 미국 인터넷광고협회(IAB)가 지난달 23일 발표한 보고서에 따르면 미국의 지난해 모바일광고 매출은 전년보다 76% 성장한 125억달러(약 13조원)로 집계됐습니다. 


페이스북의 2014년 4분기 광고수익은 약 33억달러였고 이 중 모바일에서 수익은 73%에 달했습니다. 뉴스피드에 올라오는 동영상은 월 평균 1억개를 넘고 있으며 한국에서는 매월 1,000만명 이상이 모바일 페이스북에서 동영상을 시청하고 있습니다.

페이스북은 이미 2014 년 6 월 , 모바일 동영상 시청률을 높이기 위해 
동영상 게시물이 우선순위를 갖도록 뉴스피드 알고리즘을 수정했다 .

 한편, 한국의 트위터 사용자 74%가 트위터로 동영상을 시청한다고 합니다. 특히 이 중 90%는 모바일 기기로 시청한 것으로 조사됐습니다. 그리고, 감상한 동영상 대부분은 영화, 음악, TV, 스포츠 등 엔터테인먼트 트윗에 대한 것이었습니다. 트위터는 최근에 동영상 스트리밍 기업 페리스코프(Periscope)를 1억달러에 인수하면서 본격적인 모바일 동영상 시장공략에 나섰습니다.

최근의 동영상 스트리밍 요구조건: 
  •  IP상에서 영상이 스트리밍되어야 한다 .
  • 영상은 실시간으로 보거나 주문해서 이용할 수 있어야 한다 .
  • 주문형 비디오 (Videoondemand)는 검색 , 플레이 , 멈춤이 가능해야 한다 .
  • 선택적이지만 , 실시간 영상도 짧은 시간 정도는 되감기 , 멈춤이 가능하고 영상 레코딩이 될 수 있어야 한다 .

글로벌 기업의 QA사례 (Google,Facebook, Atlassian)

우리 현실에 맞는 QA와 테스팅은 어떤 모습이어야할까? 이런 고민은 QA/테스팅 부서가 있는 회사면 꼭 한번은 하게되는 질문입니다. 이 고민에 대한 실마리를 다른 회사는 어떻게 QA를 하고 있는지를 살펴보면서, 스스로에게 질문을 하는 것에서 찾을 수도 있습니다. 여기에서는 글로벌 기업인 Google, Facebook, Atlassian의 사례를 찾아 간략하게 정리해봅니다.

1. Google

Google의 Tester
구글의 고참 디렉터이며, 테스팅 계열의 최상급자인 Patric Copeland는 책의 서문에서 이렇게 말하고 있습니다.

"구글은 전산학과 코딩 기술을 존중한다. 
테스터가 그 클럽에 동참하려면 훌륭한 전산 지식과 절묘한 코딩 기술을 갖추어야 한다."

우리나라에서 테스터로 업무를 시작한 사람들에게  Patric이 말한  훌륭한 전산 지식과 절묘한 코딩지식 을 갖추라는 조언은 이해는 가지만, 이를 달성해내기는 쉽지 않습니다. 대부분의 테스팅 업무란, 사용자에게 최상의 경험을 주기위해 앞서 경험을 해주는 대리자의 입장이 많았기 때문인 것 같습니다. 단지 경험을 미리 해주는 테스터에게는 엄청난 전산 지식도, 절묘한 코딩 스킬이 필요한 것은 아니기 때문인가? 라는 생각이 듭니다.
중간 생략....


2. Facebook


Facebook의 QA에 대한 내용은 facebook을 재직했던 엔지니어가 Quora에 등록한 답변을 토대로 정리했습니다. 2~3년 전의 내용이며, 현재 Facebook의 QA 상황과 차이가 있을 수도 있지만 충분히 참고할 만 한 것 같습니다.

Facebook의 QA

 별도로 독립된 QA Team이 없다. ‘Test engineering team’이 있었으나 이 팀은 Test infrastructure를 구축하고 유지보수 하는 업무입니다. 앞서 살펴본 회사들과 마찬가지로  개발자들이 직접 테스트를 작성하고 실행 및 유지보수 를 합니다. 개인 또는 팀이 하는 테스트보다 도그푸딩(dog-fooding)을 합니다. 출시 전에 일주일 정도는 임직원들이 미리 변경을 경험하고 버그를 올릴 수 있으며, 수동 테스트 보다 자동화 테스트를 합니다. 또한 릴리즈 24시간 전에 beta facebook에 미리 반영하여, 이에 대한 버그도 리포트 받고 있으며, 페이스북 베타테스터 프로그램도 운영하고 있습니다. 실제로, Facebook 채용 사이트를 살펴봐도 Google과는 달리 Test 및 QA 엔지니어가 별도로 나와있지 않은 것을 보면, 현재도 QA나 테스팅 엔지니어로 구분된 역할은 Facebook에 없는 것 같습니다.
중간생략...

3. Atlassian


Atlassian 블로그의 QA 시리즈 포스트를 요약하여 정리합니다. 

Atlassian의 QA
Atlassian의 테스팅 및 QA의 목표는 “높은 품질의 소프트웨어를 빠르게 배포하는 것”입니다. 인력구성은 다음과 같습니다. 
  • 개발 및 Team Lead (78)
  • 제품 관리자 (Product Manager) (10)
  • UX(UI) 디자이너 (6)
  • Tech writer(3)
  • QA 엔지니어 (6)


QA는 역할은 테스터가 아니며, 실제 수동테스트를 포함한 모든 테스트는 개발자가 수행합니다. Atlassian의 대표 제품인 JIRA에 대한 QA 프로세스는 아래와 같습니다.

중간생략...


2015년 8월 18일 화요일

애자일을 활용한 모바일 개발 프로젝트 개선방법

Ⅰ . 모바일 앱 시장의 성장과 현실

전 세계적으로 모바일 사용이 확산되면서 모바일 어플리케이션 ( 이하 앱 ) 시장의 규모도 급격하게 증가하고 있습니다 . 시장조사기관인 가트너에 따르면 모바일 앱 시장 규모가 지난해 52 억 달러에서 2014 년 580 억 달러로 10 배 이상 성장할 것으로 예상하고 있습니다 . 이는 애플 , 구글 , MS 와 같은 기존 모바일 플랫폼 사업자들의 오픈마켓뿐만 아니라 아마존과 페이스 같은 콘텐츠 및 서비스 기업들도 새로운 시장을 만들어나감에 따라 더욱 다양한 모바일 서비스가 가능해지고 이를 이용하는 사용자도 같이 확대되어 갈 것이기 때문입니다 .

모바일 앱 시장이 급격하게 성장하고 있지만 워낙 많은 앱들이 시장에서 치열하게 경쟁하다보니 사용자에게 주목 받기란 매우 어려운 일입니다 . 모바일 앱 마켓에서 상위에 링크된 경우 높은 인기를 누리지만 나머지는 거의 미미한 이용률을 보이고 있습니다 . 애플 앱스토어의 경우 , 상위 5 위에 등록된 앱은 절반 이상의 사용자가 이용하는 반면에 나머지는 2% 정도의 사용자만을 갖는다고 합니다 . 따라서 모바일 앱 시장은 소위 “ 부익부 빈익빈 ” 현상이 매우 극명한 곳이라고 할 수 있습니다 . 한국콘텐츠진흥원에서 발표한 “ 모바일 애플리케이션 비즈니스 현황과 전망 ”, 이라는 보고서에 따르면 , 국내에서 모바일 앱을 등록한 업체의 70% 정도가 20 명 이하의 중소기업이며 종업원 1 인당 연간 매출액은 1,200 만원에 (2011 년 기준 ) 불과하다고 합니다 . 특출난 1 인 개발자나 대규모 온라인 및 게임사를 제외하고는 생존하는 것조차 쉬운 일이 아닙니다 .

Ⅱ . 모바일 앱 개발의 특성과 이슈들

Ⅲ . 모바일 개발환경에 적합한 개발방법

자세히 보기 →

모바일앱 자동화 테스팅의 성공적 적용을 위한 8가지 문제점 극복방안과 자동화툴 소개

현재 애플 앱스토어에는 50만개 이상의 앱이 등록되어 있으며, 안드로이드 마켓에는 30만개의 앱이 등록되어 있습니다. RIM의 Playbook, MS Windows Phone, Window Mobile에 등록된 애플리케이션 숫자까지 합친다면 그 수는 엄청나며, 이에 모바일 애플리케이션의 자동화 테스팅은 필수적인 코스로 떠오르고 있습니다. 현 수준에서 모바일 앱 자동화 테스팅의 한계와 상용화 및 오픈 소스로 공개되어 주목받고 있는 자동화 테스팅 툴을 소개하려 합니다.

자세히 보기 →

소프트웨어 역공학의 성과와 도전

소프트웨어 생애주기 비용은 상당부분 유지보수와 지원업무 때문에 발생합니다 . 이들이 소프트웨어 전체 비용의 50% 이상을 차지한다는 것이 소프트웨어 산업의 전반적 인식입니다 .
소프트웨어를 수정을 하기 위해선 소프트웨어를 이해하여야 하며 소프트웨어에 대한 이해는 개발자가 분석 , 추측 , 가설의 공식화에 의해 업무를 성공적으로 달성할 수 있도록 소프트웨어 인공물 혹은 전체시스템에 대한 충분한 지식을 획득해야 하는 인간 집약적 프로세스입니다 .

대부분의 경우에 소프트웨어에 대한 이해는 가장 최신버전의 소프트웨어 문서 부족 때문에 도전을 받게 됩니다 . 종종 이는 개발이 진행되는 동안 자원부족 , 시간적 제약 혹은 제한된 역량으로 인해 어려움을 겪습니다 .
소프트웨어 역공학 (reverse engineering) 은 기존 소프트웨어 인공물로부터 그에 대한 정보와 지식을 도출하기 위한 방법과 도구를 포함하는 광범위한 용어로서 소프트웨어 공학 프로세스에 영향을 줍니다 .
이 article 에선 역공학 분야에서 광범위한 중요성을 찾아내고 해결되지 않은 문제점들을 강조하며 , 미래의 방향성을 제시할 것입니다 .

Ⅰ . 역공학의 개념
Ⅱ . 소프트웨어 분석
Ⅲ . 소프트웨어 뷰의 구축
Ⅳ . 미래 동향
Ⅴ . 결론

자세히 보기 →

4개 지역(대경권·동남권·충청권·호남권) SW품질역량센터와 SW공학센터 MOU 체결

열악한 지역 SW 기업의 ‘SW 개발품질관리 선진화와 역량강화 ’기틀 다진다 .

지역 SW 품질역량센터 인력의 전문성과 지역 SW 기업의 역량강화 지원 등을 통한 “SW 개발품질관리 선진화 ” 기틀 마련에 나섰습니다.

SW공학·품질전문기관인 SW공학센터(소장 이상은)  는 11일(화) 상암동 누리꿈스퀘어에서 4개 지역(대경권·동남권·충청권·호남권) SW품질역량센터와  지역SW기업의 ‘SW개발품질관리 선진화 및 역량강화’를 위한 협력관계 확대 및 공동사업 추진 등을 위한 업무협력 양해각서(MOU)를 체결  했다고 밝혔습니다.  

2015년 8월 14일 금요일

ALM의 성공을 위한 8가지 SW품질척도

소프트웨어 품질 척도(Software Quality Metric)는 요구 사항(Requirement), 설계(Design), 개발(Development), 테스트(Testing), 릴리즈 관리(Release management), 애플리케이션 유지 보수(Application maintenance)에 이르는 ALM(application life cycle management, 애플리케이션 생명주기관리)의 모든 단계에 유용하게 쓰입니다. CIO 및 고위 관리자들은 적합한 소프트웨어 품질 척도 툴을 선택해 소프트웨어 개발 단계를 효율적으로 운영하는 것이 필요합니다.

  • CIO 및 고위 관리자들은 각 단계마다 다양한 품질 척도를 적용하고 있음 . 그러나 너무 많은 척도들을 수집 , 분석 , 실행하는 것은 시간낭비이자 실행 불가능한 일
  • 요구사항 및 설계 (Requirements and design) 단계의 품질 척도
  • 개발 (Development) 단계의 품질 척도
  • 테스팅 및 릴리즈 관리 (Testing and release management) 단계의 품질 척도
  • 유지보수 (Maintenance) 단계의 품질 척도

안전필수시스템 ( 무인비행체 OFP) SW 품질개선 사례

무인비행체 (UAV: Unmanned Aerial Vehicle) 는 최근 다양한 분야에서의 활용이 기대되는 실시간 임베디드 시스템입니다 . 이미 군사적 목적으로는 다양한 UAV 가 실전배치 되어 있으며 , 방송 중계 및 실시간 방재 용으로도 다양하게 개발되고 있습니다 . 정보통신부 ITRC (IT Research Center) 인 UAV & SW Fusion Research Center ( 과제책임자 : 건국대 김두현 교수 ) 는 “ 무인헬기를 이용한 IT 기반 실시간 방재 및 IT 서비스 실현 “ 을 목표로 2012.02 성공적으로 종료되었습니다 . 본 투고에서는 무인헬기의 제어 SW (OFP: Operational Flight Program) 의 품질을 향상 및 보장하기 위하여 적용한 다양한 SW 공학 및 V&V (Verification & Validation) 기법들을 소개합니다 .

Ⅰ . 무인비행체 OFP 개요
OFP 는 무인비행체의 실시간 임베디드 제어 소프트웨어로서 무인비행체에 내장된 하드웨어 / 센서 및 지상 제어기와의 통신을 제어하는 중요한 소프트웨어입니다 . 다음의 <그림 1> 은 OFP 의 구성 및 주된 데이터 흐름을 보여줍니다 .
<그림 1>


Ⅱ . OFP V&V 계획

  • 정형 모델링 및 검증
  • 역공학
  • SW 테스팅


Ⅲ . OFP V&V 수행 결과

  • 정형 모델링 및 검증
  • 역공학
  • SW 테스팅


오픈소스 소프트웨어 활용을 통한 소프트웨어 개발 프로세스 변화

소스코드를 무료로 공개, 배포하는 오픈소스 소프트웨어(OSS; Open Source Software)는 단순히 미리 만들어진 소프트웨어를 사용한다는 개념으로 해석할 수 있지만 최근에는 OSS로 인해 소프트웨어를 개발하는 모습 자체가 변하고 있습니다. 옵션으로 생각되던 OSS가 반드시 살펴봐야 하는 필수요소로 자리잡고 있습니다. 

 OSS는 무조건 공짜라고 알고 있는 사람들도 많습니다. 하지만 OSS는 무료 소프트웨어인 프리웨어(Freeware)와는 다릅니다. 사용자가 소스에 접근하고 사용, 수정, 재배포가 자유스럽다는 것이 OSS의 특징입니다. 최근에는 기술지원을 포함하는 상업용 OSS도 늘어나고 있어, 커뮤니티 등을 활용하여 특정 OSS를 유지 관리하는 사용자와 개발자 그룹이 존재하기도 합니다.

 프로젝트 초기 단계의 개발 트랜드 변화

 지금도 소프트웨어를 개발할 때 가장 중요한 요소를 꼽으라고 한다면 대부분은 우수한 역량의 개발자를 꼽을 것입니다. 완벽한 소프트웨어를 만들기 위해서는 개발자의 역량이 무엇보다 중요하기 때문입니다. <그림1>에서 절차 ①을 보면, 개발자는 요구사항을 접수해서 소프트웨어를 설계하고 개발합니다. 이 프로세스가 소프트웨어를 개발하는 일반적인 프로세스입니다. 이러한 프로세스는 소프트웨어가 완성될 때까지 개발자에게 대부분의 권한을 위임합니다.

 개발자들은 개발 초기에 불명확한 요구사항 때문에 매우 많은 시간을 소비하고, 소프트웨어의 틀을 잡기 위해서 초기 코딩 시간도 매우 긴 편입니다. 프로젝트의 모든 것을 살피고 개발도 잘하는 슈퍼맨이 필요하다는 것도 이 때문이라고 할 수 있습니다. ②를 살펴보면, 개발하기 전에 OSS를 검토하는 것으로 되어있습니다. 소프트웨어는 항상 새로운 것을 개발해야 할 것 같지만, 매우 특이한 기능도 미리 개발된 경우가 많습니다. 왜냐하면 많은 사람들이 동일한 방법으로 쉽게 사용하도록 만든 것이 바로 소프트웨어이기 때문입니다. 따라서 원하는 기능을 OSS에서 찾는 경우가 많다고 OSS 경험자들은 얘기하고 있습니다.

<그림1> 오픈소스 활용 시점











이제 OSS는 피해갈 수 없을 만큼 양도 많아지고 사용 횟수가 많아지면서 질도 갈수록 높아지고 있습니다. 현재는 개발 후에 OSS에 문제가 없는지 검증만 해보고 있지만, 개발 전에 OSS를 검토하고 개발에 활용한다면 개발자의 초기 부담이 현저히 줄어들 것입니다. 또한 검증된 OSS를 활용함으로써 오류가 줄어들어 소프트웨어의 신뢰도는 매우 높아질 것입니다. 소프트웨어 개발자에게 OSS 활용 역량을 강조해야 하는 이유입니다.

<그림2> 독점 소프트웨어와 OSS 개발방법론



















2015년 8월 13일 목요일

헬스케어 서비스를 위한 빅데이터 설계 포인트

대부분의 서비스에서는 소프트웨어를 편의성이나 기능 증대에 활용하는 경우가 대부분이라 서비스 자체의 변화는 크지 않습니다. 하지만 질병의 치료와 예방을 함께 생각하는 헬스케어 서비스의 경우 소프트웨어가 차지하는 비중은 매우 높습니다. 질병의 발생 여부에 따라 환자의 치료나 상태 관리를 위해 병원을 방문해야 하는 것이 일반적이지만, ICT를 접목 시키면 직접적인 치료는 아니더라도 환자의 상태는 항시 관리할 수 있기 때문입니다.

헬스케어 서비스는 기존 의료 서비스에 ICT 서비스를 접목한 서비스입니다. 그림1은 헬스케어 서비스의 개념을 나타낸 것입니다. 기존의 의료 서비스는 환자가 발생하면 병원과 약국에서 대면 의료를 통한 서비스를 하는 것이 일반적이었습니다. 하지만 헬스케어 서비스로 넘어오면서 환자는 물론이고 질병이 발생하지 않은 일반인 대상으로 다양한 서비스를 제공하고 있습니다. 더구나 ICT 기기의 발달로 인해 원격 진료라는 새로운 서비스도 나타났습니다.

기존 의료 서비스는 반드시 의료 기관을 통해 서비스를 받을 수 있었지만, 헬스케어 서비스는 헬스케어 기기, PC, 모바일 기기, 운동시설 등 다양한 기기의 정보를 통해 추가적인 서비스를 받을 수 있습니다. 병원에서 전달하는 정보는 전자의무기록(EMR, Electronic Medical Record), 처방전달시스템(OCS; Order Communication System), 의료영상저장전송시스템(Picture Archiving Communication System) 등이 있으며, 다양한 기기들이 전달하는 정보는 국제표준 전자건강기록(EHR; Electronic Health Record)가 있습니다. 전송된 정보들은 각각의 표준화된 규격에 맞춰 빅데이터로 관리되며, 중요 의료, 건강 정보를 분석하여 헬스케어 서비스를 제공하고 있습니다.

헬스케어 서비스는 발전하는 IoT(Internet of Things) 개념을 적용하는 서비스 중에서 빅데이터 분석에 의해 개인의 특성을 파악하고 맞춤 서비스를 할 수 있는 대표적인 서비스라고 할 수 있습니다.

그림1. 헬스케어 서비스의 개념도













제56회 SW공학 Technical 세미나(동영상 자료)

“TCAM관점에서 SW Testing의 현위치”
- SW 공학센터 윤형진 수석


 제56회 SW공학 Technical 세미나 - SW 공학센터 윤형진 수석

제56회 SW공학 Technical 세미나(동영상 자료)

“해외선진사례를 통해 본 국내 핀테크 발전방향”
- 최수진 서강대학교 교수

 제56회 SW공학 Technical 세미나 - 최수진 서강대학교 교수



2015년 8월 12일 수요일

중소기업의 SW품질개선을 위한 프로세스 개선

아이들이 성장할 때 한 번씩 크게 아픈 것을 ‘성장통’ 이라고 합니다. 고통스럽기는 하지만 이런 성장통을 겪으면 눈에 띄게 자랍니다. 성장하려면 아픔을 이겨내는 것은 필수 과제입니다.
이것은 비단, 사람만의 이야기는 아닙니다. 많은 우수 벤처기업들도 성장과정에서 이러한 ‘성장통’을 겪습니다. 하지만 사람과 다른 점이라고 한다면, 그 고비를 이겨내지 못할 경우 강소기업 혹은 중견기업으로의 진입 문턱 앞에서 좌절해 버린다는 점일 것입니다. 

 지난 20여 년 간 수많은 벤처기업들이 흥망성쇠를 거듭했습니다. 그 중 지속적인 성장을 이룬 기업은 극소수에 지나지 않습니다. 대부분 매출이 급성장하는 과정에서 효율성과 경영 성과가 저하되는 경험을 합니다. 누가 무슨 일을 하고 있는지, 프로젝트의 진행 상황은 어떤지, 제때 납품은 가능한 지 조차 알 수 없는 상황이 빈번하게 발생합니다. 인원이 늘고, 규모가 커져 가지만 그에 비해 내부 운영 수준은 사업 초창기 수준에서 맴도는 경우가 많기 때문으로 분석됩니다. 따라서 성장 수준에 걸맞은 내부 프로세스를 체계화하지 못하면 혼란은 극대화 되고, 결국 도태될 수 밖에 없습니다.

여기, 프로세스 개선을 통해 창업 15년 만에 연643억 매출을 일구어 낸 회사가 있습니다.
2000년 7월에 창업하여, 2015년 현재 210명의 임직원을 둔 중견 기업으로 성장한 ㈜ 엔텔스의 권종욱 이사에게서 ‘중소기업의 SW품질 향상을 위한 프로세스 개선방법’에 대한 조언을 들어보았습니다. 






















일반인이 참여하는 '소프트웨어 프로슈머 공식 출범'

소프트웨어 관심 있는 국민 누구나 스타트업 성공 돕는다
-  일반인이 참여하는 제 1 기 소프트웨어 (SW)  프로슈머 공식 출범 -

미래부 ,  스타트업이 개발한 소프트웨어 (SW) 를 사용자들이 미리 평 가해 주 는  ‘SW 프로슈머 평가 ’  본사업 착수 및 1 기 발대식을 개최 하였습니다. (8.4)
전방위 지원을 통해 SW 품질개선 및 시장 성공률 제고에 기여하였습니다.


테스트 실행과 결함의 추적관리


  1. 테스팅 프로세스
  2. 롤 도입 전의 테스트 관리
  3. 롤 도입 후의 테스트 관리
  4. 오픈소스 테스트 관리 툴(OTM)소개
  5. OTM 활용 사례
  6. 커뮤니티

2015년 8월 11일 화요일

Android, 새로운 두 가지 설계 툴에 주목

Android 기반 애플리케이션 설계 툴인 Xamarian의 Designer와 Anywhere Software의 Designer4android가 주목을 받고 있습니다. 이 두 설계 툴은 Java에 익숙하지 않은 개발자들이 손쉽게 안드로이드 기반 애플리케이션을 설계할 수 있는 기능을 지원하고 있습니다.


  • 안드로이드 개발을 위한 두 가지 설계 툴이 시장에 출시되어 주목을 끌고 있음 . 이 설계 툴은 Java 에 익숙하지 않은 웹디자이너들도 쉽게 배울 수 있게 드래그 드롭 기능과 단순한 스크립트로 구성되어 있음.
  • Xmarin Designer 는 웹디자이너들이 안드로이드 지원 애플리케이션을 제작할 수 있도록 지원.
  • Designer4Android 는 Java 개발자들이 안드로이드 기반 기기에서 애플리케이션을 개발하고 테스트할 수 있는 기능을 제공.

높은 동기 커버리지 레벨을 위한 동시성 프로그램 테스팅

본 연구에서는 동시성 프로그램 테스팅 기법의 한계를 극복하기 위해 보다 높은 커버리지 달성을 목표로 하는 새로운 동시 실행 순서 조정 기법을 개발했습니다 . 순차적 프로그램에서 높은 커버리지를 가지는 테스트 케이스들이 오류를 효과적으로 찾아내 듯이 , 동시성 프로그램에서도 적절한 커버리지를 많이 달성하는 테스트 케이스들이 오류를 더욱 효과적으로 찾을 수 있으리라 기대합니다 .

동시구문쌍 (Synchronization-pair) 커버리지를 대상으로 , 커버리지 요구사항을 예측하는 예측 단계와 예측된 요구사항을 토대로 더 높은 커버리지 레벨 달성을 위해 동적으로 대상 프로그램의 동시 실행 순서를 조정하는 테스트 단계를 수행합니다 .  본 연구에서는 총 13 개의 Java 프로그램을 대상으로 제안한 기법이 랜덤기반 기법보다 우수함을 실험을 통해 입증했습니다 .

1. 시각화의 필요성 (1000 피트의 관점)


테스팅은 소프트웨어의 오류를 찾아 품질을 높이는 일련의 과정입니다 . 때문에 좋은 소프트웨어를 위해서는 좋은 테스팅이 필요합니다 . 순차적 프로그램 (Sequential Program) 테스팅에서 테스팅의 품질을 평가하기 위해 커버리지 기법이 사용되어 왔습니다 . 높은 커버리지 레벨을 달성하는 테스트 인풋은 오류를 찾는 능력이 좋다는 사실이 여러 연구 사례에서 보여졌습니다 . 동시성 프로그램의 테스팅 품질을 측정하기 위해서도 동기화구문쌍 , 구문쌍 커버리지 등 여러 가지 커버리지 기법이 소개되었습니다 .

2. 동시성 실행 순서 조정 기법
3. 실험 및 결과
4. 결론 및 추후 연구과제

자세히 보기 →

SW프로젝트 요구사항 수집을 위한 맥락조사 기법

소프트웨어에 대한 요구사항 수집( Gathering Requirement)은 소프트웨어 개발자가 직면한 가장 큰 어려움 중에 하나입니다. 이를 해결하기 위한 방법 가운데 하나인 맥락조사(Contextual Inquiry) 기술은 애플리케이션이 실행된 과정을 관찰, 추적해 사용자의 요구사항을 수집하는 것입니다. 우리는 이 기술을 통해 요구사항 수집으로 인해 발생되는 전형적인 문제들을 극복할 수 있습니다.


  • 1980 년대 중반 시작된 맥락조사 (Contextual Inquiry) 기법은 사용자의 업무를 파악하고 , 이에 대한 요구사항을 수집하고 보강하는 데 이용되는 방법임
  • 요구사항 정보 수집에 있어 나타나는 전형적인 문제점
  • 맥락조사 과정은 다음의 세 단계로 진행됨
  • 요구사항 수집 기법으로서 맥락조사의 장점
  • 맥락조사는 단지 사용자 기능상의 제한된 요구로부터 발생할 수 있는 오류를 방지하고 , 사용자 프로세스 기반의 전반적인 요구사항을 이끌어 냄에 따라 수준 높은 SW 품질을 이끌어내는 기반이 됨

2015년 8월 8일 토요일

NoSQL 데이터베이스로서 MySQL

최근 NoSQL 이 데이터베이스 영역에 한 축으로 자리잡고 있지만 , 기존 관계형 데이터베이스 (RDB) 사용자들에게 NoSQL 은 아직 낯설기만 합니다 . 이런 상황을 반영해 데이터 정합성이 중시되는 서비스에서 RDB 의 장점을 활용하면서 NoSQL 특징을 결합하려는 시도들이 이어지고 있습니다 . NoSQL 의 특징들을 추가하면서 RDB 기능을 보완하는 방법과 이왕 NoSQL 을 사용하려면 제대로 한번 해보는 차원에서 모델링까지 살펴보기로 했습니다 .

첫 번째 연재에서는 'MySQL as a NoSQL' 이라는 제목으로 MySQL 의 장점에 HandlerSocket Plugin 이나 Memcached Plugin 을 활용해 NoSQL 의 특성을 가미하는 방법과 성능에 대해 알아봅니다 . 2 회차 연재에서는 'MySQL 의 스케일 아웃 (Scale Out)' 에 대해 알아봅니다 . MySQL 의 Scale Out 기능의 약점을 보완하는 차원에서 대안적 스케일 아웃 방법들에 대해 살펴볼 계획입니다 . 3 회에서는 'NoSQL 데이터 모델일 ' 이라는 주제로 MySQL 을 본격적인 NoSQL 로 DB 로 사용하기 위한 모델링 방법 대해 소개할 계획입니다 .

데이터베이스 분야는 최근 클라우드 컴퓨팅과 소셜 네트워크 서비스의 등장 , 스마트 기기의 확산 등 컴퓨팅 환경 변화에 대처하고 내부적으로 데이터의 폭증과 원활한 서비스 지원을 위해 다음과 같은 과제를 해결해야 하는 환경에 놓여있습니다 .

Architecture Visualization(아키텍쳐 시각화) Part 2

지표란 직접 경험을 하지 않아도 현재의 상황을 알 수 있는 도구를 말합니다 . 옛날 제주도에서는 물이 귀해 빗물을 식수로 사용을 했습니다 . 빗물의 오염도를 파악하기 위한 지표로 , 개구리 ( 수놈끼리만 넣거나 , 암놈끼리만 넣거나 ) 를 사용했습니다 . 개구리들이 벌레들을 잡아먹어 물이 항상 청결한 상태를 유지할 수 있었으며 , 또한 개구리의 생존 여부로 물 오염도를 파악 할 수 있었습니다 .

이러한 지표의 한 예로 , Dependency Structure Matrix (DSM) 을 지난 호에 소개했습니다 . 이번 호는 또 다른 지표로써 , Clean Code 의 저자이자 객체 지향의 SOLID 원칙으로 유명하신 Robert C. Martin( 줄여서 Uncle. Bob) 님이 만드신 Instability/Abstractness Graph 를 설명하겠습니다 .


  • Instability
  • Abstractness
  • Main Sequence 와 Distance
  • STAN4J 와 그 외의 지표들

MS社, 윈도우10 출시 관련 주요 이슈 보고

MS 社 의 신규 운영체제인 윈도우 10 이 올해 7.29 일 ( 수 ) 출시 * 예정 인 바 , 이에 따른 국내 S/W 및 인터넷 이용환경 변화에 대한 이슈 분석

1. 새로운 브라우저 (‘Edge’) 출시 관련 이슈
윈도우 10 에서는 기존의 ‘ 익스플로러 11 ’ 과 신규 웹브라우저 인 ‘ 엣지 (Edge) ’ 를 동시 탑재하여 출시하나 엣지의 경우 ActiveX 등 플러그인 기술을 지원하지 않아 * 웹사이트 이용시 정상 동작이 되지 않을 수 있음

- 다만 , 동시 탑재된 익스플로러 11 의 경우 종전과 같이 ActiveX 를 지원 하므로 브라우저 설정 변경 ** 을 통하여 큰 문제 없이 웹사이트 이용 가능
* 엣지의 ActiveX 미지원 정책은 여러 차례 이슈화되어 대부분의 국내 개발자 및 이용자들은 인지

2. 운영체제 ( 윈도우 10) S/W 설치 관련 이슈
o 윈도우 10 OS 의 커널구조 * 가 변경 되어 HW 를 활용하는 일부 SW** 의 경우 수정개발이 필요하나 윈도우 10 출시 이후에나 개발 작업 완료 예정
* 커널 (kernel) : OS 를 구성하는 주요 뼈대로 하드웨어 관련 입  ·  출력과 명령어 처리를 담당
** 동영상 · 음성 편집프로그램 , 채팅 · 메신저 프로그램 , 스캐너 · USB 제어 프로그램 등

2015년 8월 7일 금요일

분산된 애자일 팀 간의 명확히 공유된 이해 제공

대부분의 애자일 개발관련 참고서적들은 동일 장소에 배치된(co-located) 팀들과 대면(face-to-face) 의사소통의 장점에 대해 말합니다. 기본적으로 동일 장소에 배치된 팀들은 의사소통이 더 쉽고 강한 유대관계를 형성하는 장점을 가집니다. 그러나 기술과 SW개발/관리도구(tool)들의 발전과 더불어 분산된 애자일 팀들(distributed Agile teams)이 많아짐에 따라 애자일 방법론상의 대면활동에 대한 강조는 SW개발 조직운영에 있어 부작용이 발생시킬 여지가 있습니다. 현재 SW개발/관리 툴들은 더 많은 유연성과 이동성을 보장함에 따라, 문서화를 통한 효과적인 의사소통 체계를 구축하는 것이 필요합니다.

  • SW 개발 프로젝트에 있어 문서화는 개발팀간의 오해가 없는 명확히 공유된 이해를 제공한다.
  • 문서화는 대면 의사소통에 비해 공유하기 쉬우며 분산된 개발팀의 기본적인 의사소통 수단으로 활용하는 것이 바람직하다.
  • 그럼에도 불구하고 대면 의사소통은 여전히 중요하다.

대량 스트림 데이터 처리 솔루션인 Oracle Complex Event Proces

오늘날 다양한 IT 환경에서 수많은 데이터가 쏟아지고 있습니다 . RFID 리더 , 바코드 스캐너 , 기계 장치의 센서는 물론 최근에는 중요 자원의 위치를 알려주는 GPS(Global Positioning Systems) 정보까지 다양한 데이터가 끊임없이 쏟아지고 있습니다 . 이렇듯 지속적으로 데이터를 발생시키는 시스템들이 많아지고 , 발생하는 데이터량 또한 점점 늘어가고 있는 상황에서 중요한 것은 어떻게 이 많은 양의 데이터 중에서 비즈니스적으로 의미 있는 데이터를 신속하게 추출하고 처리하느냐입니다 . 이러한 상황에서 복잡한 데이터를 처리하는 솔루션인 CEP(Complex Event Processing) 에 대해 설명하고자 합니다 .

Complex Event Processing 는 여러 이벤트 소스로부터 발생한 이벤트를 대상으로 실시간으로 의미 있는 데이 터를 추출하여 대응되는 액션을 수행하는 것을 말합니다 . 이때 이벤트 데이터는 스트림 데이터로써 대량으로 지 속적으로 입력되는 데이터 , 시간 순서가 중요한 데이 터 , 끝이 없는 데이터입니다 . 이러한 스트림 데이터는 전 통적인 관계형 데이터 베이스에서는 실시간 처리 및 분 석이 불가능합니다 . CEP 는 바로 이런 스트림 데이터를 실시간으로 분석하는 이벤트 데이터 처리 솔루션입니다 .  

Architecture Visualization(아키텍쳐 시각화) Part 1

변화의 충격을 감지해라 - Dependency Structure Matrix

소프트웨어는 사용자에게 유용해야 된다는 명백한 외부적인 관점도 있지만 , 품질이라는 내부적인 관점도 존재합니다 . 즉 소프트웨어가 잘 개발되고 있는지 품질을 파악할 수 있는 지표가 필요합니다 . 이번 연구에서는 소프트웨어의 품질을 평가할 수 있는 몇몇 시각화 기법을 전달합니다 .  

시각화의 필요성 (1000 피트의 관점 )

아키텍처의 품질을 평가하기 위해 , UML 로 그려진 아키텍처 다이어그램을 볼 수 있습니다 . 하지만 아키텍처 다이어그램의 작은 상자들은 전체 시스템을 나타내며 상자 간의 선은 시스템 간의 의존성 , 데이터 흐름 , 버스와 같은 공유자원인지 파악할 수 없습니다 . 이것은 비행기 밖 풍경과 같이 과도하게 추상화되어 있는 30,000 피트의 뷰 입니다 .

반면에 소스코드를 보며 품질을 평가 할 수 있는데 , 이것은 0 피트와 같은 바닥 레벨의 뷰로 비유할 수 있습니다 . 소스 레벨에서는 연관성 있는 몇 개의 객체의 구조도 보지 못할 만큼 많은 정보를 제공합니다 .

이 두 뷰는 소프트웨어 품질에 대한 올바른 정보를 제공하지 못하므로 , 0 피트와 30,000 사이인 , 1000 피트의 뷰를 보아야 합니다 . 1000 피트의 뷰는 메서드 개수 , 클래스 팬 아웃 , 순환 의존도와 같은 다양한 지표와 많은 양의 데이터를 접할 수 있습니다 .

의존성 분석 도구 DSM(Dependency Structure Matrix)

  • DSM 으로 보는 계층화
  • Change Propagator 를 주의해라
  • 의존성을 끊는 방법
  • 실 사례로 보는 DSM


자세히 보기 →

2015년 8월 6일 목요일

헬스케어 서비스를 위한 빅데이터 설계 포인트

헬스케어 서비스의 개념

 대부분의 서비스에서는 소프트웨어를 편의성이나 기능 증대에 활용하는 경우가 대부분이라 서비스 자체의 변화는 크지 않습니다. 하지만 질병의 치료와 예방을 함께 생각하는 헬스케어 서비스의 경우 소프트웨어가 차지하는 비중은 매우 높습니다. 질병의 발생 여부에 따라 환자의 치료나 상태 관리를 위해 병원을 방문해야 하는 것이 일반적이지만, ICT를 접목 시키면 직접적인 치료는 아니더라도 환자의 상태는 항시 관리할 수 있기 때문입니다.

 헬스케어 서비스는 기존 의료 서비스에 ICT 서비스를 접목한 서비스입니다. 그림1은 헬스케어 서비스의 개념을 나타낸 것입니다. 기존의 의료 서비스는 환자가 발생하면 병원과 약국에서 대면 의료를 통한 서비스를 하는 것이 일반적이었습니다. 하지만 헬스케어 서비스로 넘어오면서 환자는 물론이고 질병이 발생하지 않은 일반인 대상으로 다양한 서비스를 제공하고 있습니다. 더구나 ICT 기기의 발달로 인해 원격 진료라는 새로운 서비스도 나타났습니다.

기존 의료 서비스는 반드시 의료 기관을 통해 서비스를 받을 수 있었지만, 헬스케어 서비스는 헬스케어 기기, PC, 모바일 기기, 운동시설 등 다양한 기기의 정보를 통해 추가적인 서비스를 받을 수 있습니다. 병원에서 전달하는 정보는 전자의무기록(EMR, Electronic Medical Record), 처방전달시스템(OCS; Order Communication System), 의료영상저장전송시스템(Picture Archiving Communication System) 등이 있으며, 다양한 기기들이 전달하는 정보는 국제표준 전자건강기록(EHR; Electronic Health Record)가 있다. 전송된 정보들은 각각의 표준화된 규격에 맞춰 빅데이터로 관리되며, 중요 의료, 건강 정보를 분석하여 헬스케어 서비스를 제공하고 있습니다.

 헬스케어 서비스는 발전하는 IoT(Internet of Things) 개념을 적용하는 서비스 중에서 빅데이터 분석에 의해 개인의 특성을 파악하고 맞춤 서비스를 할 수 있는 대표적인 서비스라고 할 수 있습니다.















그림1. 헬스케어 서비스의 개념도

모빌리티 테스팅: 5개 주요과제와 해결방안

모바일 기기들이 널리 보급됨에 따라 모바일 기기 테스팅은 SW 개발상의 주요 선결과제로 대두되고 있습니다. 모바일 기기 테스팅은 기존 SW개발 테스팅과는 다른 독특한 특징을 보이고 있으며, 이러한 특징은 아래의 5가지 주요과제로 분류할 수 있습니다.
본 장에서는 모바일 테스팅에 있어 5가지 주요과제별 해결방안을 합리적인 비용측면과 지속가능한 위험감소 측면에서 제시하고자 합니다.


  • 모바일 기기 테스팅에 있어 직면하게 되는 5 가지 주요 과제들
        1. 모바일 OS(operating system) 들과 OS 버전들의 수
        2. 모바일 장치들과 장치 구성 (device configuration) 들의 수
        3. 로컬 네트워크 서비스 제공자들에 대한 의존
        4. 기업 수준의 보안 문제들
        5. 어플리케이션 , OS, 장치의 개발 속도
  • OS 시스템들의 수 : 범위의 한계를 정하라
  • 모바일 기기들과 기기 환경들의 다양성 : 범위의 한계를 정하라
  • 로컬 서비스 제공자들에 대한 의존들 : 서드파티 테스팅 활용하기
  • 기업수준의 보안 문제들 : 적절한 시점에 오인요소들 점검하기
  • 적용속도 : 팀을 적정 규모로 조직해라 , 적절한 테스트 타겟을 설정하라 , 테스트 자동화를 시행하라


확장가능한 Concolic 테스팅 접근 : 경험적 평가

소프트웨어 테스팅은 소프트웨어의 Quality 를 높이는데 표준이 되는 방법이지만 기존의 일반적 테스팅 방법은 fault 를 찾는데 자주 실패합니다 . Concolic 테스팅은 이러한 문제점을 완화시키기 위해 fault 를 찾는 테스트 케이스 생성을 자동화함으로써 가능한 한 많은 프로그램 실행경로를 탐색하려는 시도를 합니다 . 하지만 Concolic 테스팅은 수많은 실행경로를 탐색하기 위해 상당한 시간을 필요로 하기 때문에 실제적용에는 한계를 가지고 있습니다 . 

본 연구는 이러한 한계를 다루기 위해 기존의 Concolic 접근을 많은 수의 컴퓨터를 활용하여 사용할 수 있도록 확장함으로써 테스트 케이스의 생성을 활용되는 컴퓨터 수에 비례하여 빠르게 하는데 그 목적이 있습니다 .

동적 테스팅 기법은 산업체 또는 기관에서 소프트웨어의 Quality 를 높이는데 가장 많이 사용되는 기법이지만 소프트웨어의 많은 실행경로 때문에 테스트 케이스를 버그를 찾을 수 있을 만큼 충분하게 만드는 것에는 현실적인 어려움이 있습니다 . 이러한 한계를 극복하기 위해서 Concolic(CONCrete + symbOLIC) testing[1] 기법이 제시되었지만 가능한 실행경로들을 탐색하는데 상당한 시간이 걸려서 실제적인 적용이 어렵습니다 . 
본 연구에서는 이러한 한계를 극복할 수 있는 Scalable COncolic testing for REliable software(SCORE) framework 를 제시합니다 . SCORE 는 분산된 Concolic 알고리즘으로써 많은 수의 컴퓨팅 노드를 확장가능하고 , 많은 수의 컴퓨팅 노드가 동시에 실행되면서 테스트케이스를 생성하도록 함으로써 테스트 케이스의 생성속도를 컴퓨팅 노드의 수에 비례하여 선형적으로 증가하게 할 수 있도록 합니다 .
  • 분산된 Concolic 알고리즘
  • SCORE 알고리즘
  • 노드들간의 통신
  • SCORE 구현
  • 성능분석

자세히 보기 →

2015년 8월 5일 수요일

제 56회 SW공학 Technical 세미나 발표자료

- 해외의 선진 사례와 국제표준 관점으로 보는 국내 핀테크와 SW Testing의 발전방향 -
 SW공학 Technical 세미나 자료가 업데이트 되었습니다.


자료 보러가기 →

의료기기용 SW특징과 검증시스템

의료기기는 환자의 생명을 다루기 때문에 그 어떤 기계보다도 ‘안전’이 매우 중요합니다. 의료기기 인증 및 판매 허가가 힘든 이유도 각종 의료기기 법과 규정에서 요구하는 ‘성능’과 ‘안전 기준’이 높기 때문입니다. 그렇기 때문에 국내 및 해외 의료기기 인증에 있어 임상 평가, 설계 관리와 함께  소프트웨어에 대한 검증이 점점 중요해지고 있습니다.  즉, 의료기기용 소프트웨어에 대한 안전을 입증해야만 의료기기 인증을 받을 수 있다는 의미입니다.
  
‘자동심장충격기(Automated External Defibrillator. AED)’를 개발하여  판매하고 있는  나눔테크는 2012년에 FDA(Food and Drug Administration: 미국 식품의약국)와 CE(Conformity European: 유럽공동체제품인증) 의료기기 인증을 준비했는데, 이때 의료용 소프트웨어 밸리데이션(Validation)에 문제가 발생했다고 합니다. 이슈는 ‘의료용 소프트웨어에 대한 안전을 객관적으로 어떻게 증명할 것인가’ 였습니다. 처음에는 각종 문서와 관련 규격을 참고하여도 막상 현장에 적용하기엔 무척 어려웠다고 합니다. 어느 누구에게도 도움을 요청할 수 없었기 때문에 막막했습니다.

이렇게 의료용 소프트웨어에 대한 검증을 고심하던 중, 정보통신산업진흥원(NIPA) 부설 SW공학센터(Software Engineering Center)를 알게 되었고, 2013년부터 2년간 SW공학센터의 ‘소프트웨어공학기술 현장적용 사업’ 지원을 받아 의료용 소프트웨어의 설계관리와 검증 시스템을 구축하였다. 이 과정에서 막연하게만 다가왔던 의료기기용 소프트웨어 검증이 지금은 명확해졌으며, 선진국과 비교해도 뒤지지 않을 정도로 자신감이 생겼다고 합니다.

  • 의료용 소프트웨어 검증 시스템 구축 배경
  • 의료기기에서 소프트웨어 정의
  • 의료용 소프트웨어 테스트 환경 구축
  • 의료용 소프트웨어 코딩 규칙과 정적 분석
  • 의료용 소프트웨어의 동적 분석
  • 의료용 소프트웨어 개발을 위한 관리 절차

자세히 보기 →