지속적인 통합을 위해 갖추어야 할 4 가지 기본 요건

지속적인 통합 (Continuous Integration) 은 팀의 구성원들이 자신들의 작업한 내용을 자주 ( 통상 최소 매일 주기 ) 통합하는 개발 지침을 말합니다 . 이러한 지속적인 통합은 복잡한 프로젝트 수행 시 야기되는 문제점들을 적시에 제거해주며 프로젝트 진행을 좀 더 손쉽게 하는 장점이 있음에 따라 , 지속적인 통합을 위해 갖추어야하는 관리방안 , 시스템 환경 등 4 가지 기본요건에 대해 소개합니다 .

▶ 원칙 1: 관리(Management) 

지속적 통합이 실행방안이 되기 위해 개발자들은 소스코드관리(Source code management:SCM)시스템을 이행할 필요가 있음. 

▶ 원칙 2: 자동화 테스팅(Automated testing)

• 애플리케이션의 자가 테스팅 자동화(Automated self-test)는 지속적통합에 있어서 매

우 중요한 부분인데, 이는 테스트 프레임워크인 ‘xUnit1)’와 같은 도구를 사용함에 따라 얻을 수 있음.

▶ 원칙 3: 자동화된 빌드(Automated build)

자동화된 테스트와 함께 ‘지속적통합’ 프로세스의 또 다른 중요한 부분은 시스템이 용이하게 작업 애플리케이션으로 변형될 수 있도록 하는 것임.

▶ 원칙 4: 리포팅 서버(Reporting server)

앞서 밝힌 3가지 이슈가 다루어졌을 때 프로젝트는 ‘지속적 통합 원칙’이 부합된다고 볼 수 있음.

자세히 보기 →

출시제품의 SW 품질확보를 위한 DevOps 도입 접근법

오늘날 대부분의 조직들은 개발단계에서의 SW 품질확보에 주력하고 있으나 , 일단 제품이 출시된 이후에는 SW 품질유지에 무관심한 경향이 있습니다 . 이러한 문제점은 주로 개발팀과 운영팀 간의 협업이 이루어지고 있지 않음에서 기인하고 있으며 , 제품출시 이후 SW 품질관리의 책임이 누구에게 있는가도 불확실함에 따라 , 이를 위한 DevOps 도입 접근법을 제시합니다.

▶ 소프트웨어 배포 전 개발팀과 운영팀의 팀워크 

“소프트웨어 개발 후반부에 문제를 지니고 있다면 소프트웨어 배포의 위험은 매우

심각해진다. 그것이 DevOps 팀워크가 배포 전에 상당히 이루어져야 하는 이유이다.”라고 ALM Consultant인 Howard Deiner는 말함.

▶ QA의 또다른 이름

SW 생산 QA절차는 생산 모니터링이라 불리며 생산엔지니어에 의해 수행되고 생산 디렉터에게 보고 함.

▶ 생산 QA의 애자일 방법론 

애자일의 주요 공헌은 개발과 운영의 협업이라는 DevOps 프로세스를 가능하게 한 것임.

자세히 보기 →

웹 프론트엔드 엔지니어링 (web front-end engineering) 의 스킬셋 part 1

UI 개발에 필요한 베이직 스킬셋

Ⅰ. 웹 프론트엔드에서의 공학

1. 웹 프론트엔드란?

웹 프론트엔드(Web Front-end)는 웹 개발에서 UI(User-Interface)부분이다.

Server-side의 반대 개념이며 웹 브라우저(web-browser)를 통해서 표현되는 부분이다.

다시 말해 웹브라우저를 탑재하고 있는 기기에서는 웹이 존재하고 웹UI영역이 존재한다고 할 수 있다. 

2. 웹 프론트엔드에서의 다양한 공학지식이 필요한 이유

소프트웨어 개발은 어느 분야에서나 공학적인 지식이 필요하다. 웹 프로그래밍의 영역도 공학적인 요소가 필요한데 일반적으로 서버사이드 관련 된 기술에 집중되어 있다.

프론트엔드 개발도 소프트웨어를 만들어가는 과정이라는 점에서 역시 일반적인 공학적 지식이 필요할 것이며, 프론트엔드에 특화된 지식들과 기술도 존재한다.

3. 국내 웹 프론트엔드 분야의 상황 

국내에서는 웹개발자 대비 프론트엔드 전문 개발자는 상대적으로 부족하다. 웹 UI개발자는 일반적으로 HTML/CSS만을 주로 다루거나 Javascript 언어만을 집중적으로 다루는 경우가 많고 디자인과 HTML/CSS와 같은 측면을 다루는 분들도 많다.

UI개발분야 다시 말해, 프론트엔드 개발 분야는 ‘구조/스타일/동적인제어’가 조화롭게 이루어져야 하는 것인데 아직까지 이를 모두 전문적으로 다루는 개발자가 부족한 현실이다.

Ⅱ. 기본 Skill-set

1. 프론트엔드의 필수지식 : HTML, CSS, Javascript 

2. Browser 동작의 이해

3. 기초 학문의 필수적인 지식들 (물리와 수학)

4. 프로그래밍 공통 스킬셋

자세히 보기 →

애자일 기반에서 아웃소싱 활용을 위한 효과적인 적용방안

애자일은 만능이 아니며 여타 개발방법론과 마찬가지로 한계와 문제점을 내포하고 있는데 , 아웃소싱 활용에 있어 그러한 문제점은 더욱 증폭되는 경향이 있습니다 . 효과적인 아웃소싱 활용을 위해서 하이브리드 애자일 모델을 도입하고 내부적 특성에 적합하도록 애자일 방법론을 조정하는 등의 적용방안을 제시하고자 합니다.

애자일 개발방법론은 자체적으로 내제된 문제점과 해결해야할 과제들이 상존해 있으며 , 이는 아웃소싱 상황일 때 더욱 증폭되고 새로운 문제들에 직면하게 됩니다.

본 원고에서는 이러한 문제들을 적절하게 해결할 수 수 있는 일련의 Best Practice 들을 제시합니다.

1. 하이브리드 애자일 모델(hybrid Agile models)을 적용하여 사전에 프로젝트 위험을 감소
2. 요구사항 영역 혹은 특정사항에 따라 아웃소싱 인력 및 작업을 구조화
3. 고객사가 용이하기 적용할 수 있도록 애자일 방법론을 수정
4. ‘변경지시절차’를 가지고 비통제 범위 및 요구사항을 관리

 자세히 보기 →

애자일 관리의 다섯 가지 효율화 방안

애자일 개발방법론의 핵심은 역할과 조직화 등 팀이 프로젝트를 수행하는 데 있어 방해요소가 될 만한 오버헤드를 제거하는 데 있습니다 . 이를 위해 팀을 소규모로 유지하고 , 독립적으로 관리하고 신속한 반복 작업을 수행하는 등의 즉시 적용이 가능한 효율화방안을 소개합니다.

애자일 소프트웨어 개발은 오버헤드를 없애는 것에 대한 모든 것입니다.

애자일 소프트웨어 개발은 소위 “ 워크 어바웃 워크 (work about work)” 라고 불리는 것에서 벗어나 실제 작업을 선호합니다.

애자일 관리의 핵심은 워크 어바웃 워크 문제를 피하는 것이고 이러한 접근방법은 팀원들이 같은 공간에서 작업하는 소규모 팀에게 효과적이며, 많은 애자일 전문가들은 대규모 프로젝트의 복잡함을 해결하기 위해 고안된 DAD(Disciplined Agile Delivery) 와 ASM(Agile Scaling Model) 같은 정교한 접근방법을 제시하고 있습니다.

대규모 팀으로 이루어진 애자일 프로젝트를 수행하기 위해 전문가들에 의해 제안되는 애자일 관리에 대한 팁을 소개합니다.

 1. 소규모 팀의 성과를 우선 수집하기

 2. 팀을 소규모로 유지하기

 3. 조직된 팀을 온전하게 유지하기

 4. 신속한 반복주기를 유지하기

 5. 궁지에서 벗어나는 방법 배우기 

자세히 보기 →

웹 애플리케이션 보안테스팅 수행을 위한 일곱 가지 체크리스트

SW 공학적 관점에서 웹 애플리케이션 (web application) 또는 웹 앱은 인터넷이나 인트라넷을 통해 웹 브라우저에서 이용할 수 있는 응용 소프트웨어를 말하는 데 , 웹 애플리케이션은 클라이언트로서 웹 브라우저를 사용하는 사용자가 매우 많음에 따라 웹 애플리케이션의 보안 취약점에 대한 테스트를 하는 것은 매우 중요한 일입니다.

다음은 웹 애플리케이션 보안 테스트를 수행하는 데 있어서 최적의 결과를 도출할 수 있는데 도움이 되는 필수 요소 체크리스트입니다.

 1. 모두의 기대치를 설정하라

 2. 유용한 툴들을 모아라

 3. 모든 관점에서 애플리케이션을 검토하라

 4. 기본적인 약점을 테스트하라

 5. 스캐너 결과를 다시 한 번 확인하라

 6. 수동으로 결함을 검토하라

 7. 소스 코드를 테스트하라 

자세히 보기 →

실시간 리눅스를 위한 동기화 프로토콜의 구현 및 검증

리눅스는 오픈 소스 기반의 범용운영체제로서 , 실시간성을 제공하는 시스템에는 적합하지 않다 . 그러나 사용의 편이성과 기존의 가용한 응용이 많은 장점 등이 있기 때문에 , 리눅스 운영체제에 실시간성을 지원하기 위한 연구가 지속되어 왔다 . 이러한 연구는 RT-Linux, RTAI, L4/Fiasco, ADEOS, Xenomai, XtratuM 등에서 찾아볼 수 있다 . 리눅스 커널 자체에서 실시간성을 지원하고자 하는 시도는 리눅스 커널 2.2.X 버전부터 도입된 실시간 선점형 (Real-time preemption) 커널이 있다 . 실시간 선점형 커널은 연성 실시간 시스템을 지원하기 위하여 원래의 스핀락 (raw spinlock) 으로 보호되는 임계 영역 (critical section) 이나 ttys 와 같은 오래된 코드들 외에는 커널의 대부분이 선점 가능하도록 한다 . 이를 위해서 대부분의 커널 스핀락 (spinlock) 은 뮤텍스 (mutex) 로 대체되고 , 모든 인터럽트는 커널 쓰레드로 변경된다 .

실시간 운영체제에서는 응용의 수행시간을 예측가능하게 만들기 위하여 우선순위 역전 (priority inversion) 현상이 반드시 제어되어야 한다 . 실시간 선점형 커널에서는 우선순위 상속 (priority inheritance) 이 지원되어 이를 제어하도록 되어 있다 . 그러나 우선순위 상속은 연쇄 블로킹 (chained blocking) 및 데드락 (deadlock) 문제를 해결하지 못하는 단점이 있다 . 본 원고에서는 RT 패치를 적용한 리눅스 커널에 PCP(Priority Ceiling Protocol) 을 구현하여 연쇄 블로킹 및 데드락 문제를 해결하였다 . PCP 의 구현 방법은 두 가지가 있으며 , [8] 에서 제시된 원래의 PCP 와 그 변형인 IPC(Immediate Priority Ceiling) 이다 . 본 원고에서는 이 두 가지를 모두 구현하여 그 성능을 측정 , 비교하였다 .

Ⅱ . 실시간 시스템의 동기화 문제

Ⅲ . 실시간 리눅스와 동기화 프로토콜 구현

Ⅳ . 동기화 프로토콜의 성능 분석

자세히 보기 →

테스트 자동화 : 언제 어떻게 그리고 얼마만큼 하는 것이 효과적인가

테스트 자동화는 테스터에 의존하는 수작업 테스팅 방법과 비교해서 비용이 효과적이며 , 시간을 절감할 수 있다는 점에서 장점이 부각되고 있습니다 . 그렇다면 , 프로젝트 개발단계에 있어 어느 시점에서 테스트 자동화를 수행하며 , 어떠한 방법에 의해서 , 어느 정도 수준으로 적용하는 것이 효과적인가에 대한 내용을 제시합니다.

▶ 핵심 프로그램 요인
▶ 언제 자동화 하여야 하는가
▶ 어떻게 테스트 자동화 프로그램을 이행하는가
▶ 얼마나 자동화하여야 하는가

자세히 보기 →

리얼타임 시스템 프레임워크 및 아키텍처 part 2

전투기로 보는 리얼타임 시스템의 메시지 아키텍처

고 신뢰성과 안정성을 요구하는 전투기의 메세지 아키텍처를 설명하고자 합니다 .

전투기는 다양한 센서들로 구성되며 , 이 센서가 수집한 정보들을 통해 다양한 입 / 출력이 발생한다 . 레이더 ( 공급자 - 센서 ) 를 통해 주위로부터 수집된 정보를 조종기 계기판 ( 수요자 - 계기판 ) 과 조종석의 유리 창에 HUD ( 수요자 - HUD) 에 동시에 전달되어야 하며 , 같은 정보를 조종사가 보기에 빠른 판단을 하기 위해 수치적인 데이터가 아닌 위험도를 색상으로 등급화하여 전달하는 것도 필요하다 .

Ⅰ . 다양한 센서와 입출력 장치로 구성된 전투기

Ⅱ . Event Channel 아키텍처

Ⅲ . Event Channel 의 제약사항

Ⅳ . 리얼타임을 지원하기 위한 Event Channel 의 내부구조

Ⅴ . 개선된 전투기의 아키텍처

자세히 보기 →

[SW공학 동영상 8화] 성공하는 SW만들기 이상은소장

• 성공하는 소프트웨어란?
• 올바른 SW 개발을 위해 중요한 것은?
• SW 개발 전에 반드시 고려해야 할 기술적 사항은?
• SW공학과 서비스공학의 핵심요소?
• 관련된 글로벌 사례
• 성공하는 SW개발을 위해서

동영상 보기 →

ISO 26262 자동차 기능 안전을 위한 MISRA 코딩 규칙 적용 방법

ISO 26262에서는 최신의 SW 공학기술 및 개발 기법을 적용하여 안전한 자동차SW 개발을 하도록 요구하고 있다. 이중에서 MISRA(Motor Industry Software Reliability Association)코딩 표준은 자동차 SW개발자가 필수적으로 준수해야 하는 개발 기법으로,  많이들 어려워하는 부분이기도 하다.  ISO 26262에서 요구하는 MISRA가 무엇인지, 이것을 SW 개발에서 어떻게 적용해야 하는지, ㈜ 티큐엠에스에서 수석컨설턴트로 활동하고 있는 노경현 이사의 자문을 통해 살펴 보았다.

ISO 26262의 소프트웨어 테스팅 방법

자세히 보기 →

SI와 솔루션 개발의 차이 - 테스트 편

테스트의 절차와 목적에 대해 먼저 알아보도록 한다. 테스트 방법이나 절차는 잘 알고 있지만 그 절차가 왜 필요한 지에 대해 정확히 정리하고 SI 와 솔루션 테스트의 차이가 무엇인지 알아보기로 한다. 그리고 솔루션 테스트를 위한 최신 트렌드에 대해 살펴보고, 마지막으로 사례를 통해 솔루션 테스트의 역할과 목표를 확인해보기로 한다.

테스트의 절차와 목적

테스트의 절차

소프트웨어 테스트는 사전적인 의미로 "주요 이해관계자들에게 시험 대상 제품 또는 서비스의 품질에 관한 정보를 제공하는 조사 과정이다. 또한 소프트웨어에 대한 객관적이고 독립적인 시각을 제공하여 사업주체가 소프트웨어 구현의 위험성을 올바로 이해하도록 한다" 라고 정의되어 있다. 다시 말해 개발하고자 했던 의도대로 만들고 있는지 확인하는 것이라고 해석 할 수 있다. <그림 1>은 소프트웨어 테스트 절차를 나타내고 있다.

소프트웨어 테스트 절차

자세히 보기 →

제58회 SW공학 Technical 세미나 안내(10/29(목))

안녕하십니까?

SW Quality Insights 제 58회 SW공학 Technical 세미나에 여러분을 모십니다.

본 세미나는 국내외 SW전문가를 초빙하여 SW개발 관련 최신 기술 동양을 파악하고 개발과정에서의 경험을 공유하는 등 SW개발자와 관리자의 역량강화를 위해 매월 지속적으로 개최하고 있습니다.

신청하러가기 →

소프트웨어 안전성 향상을 위한 코드 리팩토링 기법

자동차 , 원자력 발전소 , 비행기 등과 같은 시설 및 제품들은 다양한 장치들이 상호 협업하고 있으며 , 이들을 제어하기 위한 소프트웨어 시스템이 존재한다 . 이러한 시스템은 소프트웨어 동작과정에서 예기치 못한 오류가 발생하는 경우 , 치명적인 인명 , 재산 , 환경 피해로 이어질 있다 . 소프트웨어에 의해 심각한 피해를 유발할 수 있는 소프트웨어를 Safety Critical Software 라고 하며 , 이들은 예기치 못한 오류를 예방 , 회피 , 억제하는 속성을 의미하는 안전성 (Safety) 을 보장할 수 있어야 한다 .

Safety Critical Software 는 일반적인 소프트웨어 개발 과정과 다르게 안전성을 고려해야 하기 때문에 요구사항 수집부터 운영까지 소프트웨어의 안전성을 향상시키기 위한 많은 활동들이 필요하게 된다 . 기존의 안전성 향상 활동 중에서 대표적인 MISRA-C 코딩 가이드라인과 ISO 26262 기능 안전성 표준은 자동차 등과 같은 안전성을 중시하는 시스템의 소프트웨어 소스 코드 작성 방법을 제시하고 있다 . 

1. 안전성 향상을 위한 코드 리팩토링 절차
2. 안전성 향상을 위한 코드 리팩토링 기법
3. 안전성 향상을 위한 코드 리팩토링 적용 예

자세히 보기 →

가트너가 제시한 빅데이터 전략수립을 위한 4가지 IT핵심요소

최근 개최된 Gartner Business Intelligence Summit 에서 기업의 효과적인 빅데이터 전략수립을 위한 4 가지 IT 핵심요소가 발표되었습니다 . 클라우드 적용 , 데이터 분석역량에 집중투자 , 데이터 거버넌스에 주목 , 조직내 유기적 협업 등이 4 가지 요소입니다 .

 효과적인 빅데이터 전략을 개발하기 위한 CIO규칙

1. 클라우드 수용

• 데이터웨어하우스는 BI(Business Itelligency) 활동에 대한 기반을 유지시킬 것이나 빅데이터 분석이 될 때 비즈니스는 항상 새로운 종류의 기술을 수용할 필요가 있을 것임

2. 기술에 투자

• 일부에서는 데이터 과학자라는 용어가 BI 분석가와 통계학자에 대한 미화된 직함이라고 믿고 있으나 “이는 진실이 아니다”라고 Laney가 말함

3. 데이터 거버넌스 역할에 대한 주의

• 장래에 CDO(a chief data officer)가 당신의 회사에 존재할 것인가? 이러한 CDO를 고용할지 말지 보다 더 큰 의문은 빅데이터에 대한 강력한 데이터 거버넌스 프로그램을 어떻게 구축하는가임 

4. 비즈니스와의 협업

• IT 부서와 비즈니스의 단절에 교량이 되는 것은 CIO의 가장 최우선적 임무인데 비즈니스는 향후 지속적으로 데이터 주도가 되어가기 때문에 이 둘의 간격을 줄이는 것은 더욱더 중요할 것임

자세히 보기 →

리얼타임 시스템 프레임워크 및 아키텍처 part 1

증권 자동화 시스템으로 보는 리얼타임 시스템

리얼타임 ( 실시간 ) 이라는 단어가 가져오는 의미를 잘못 이해해 많은 이들이 리얼타임 시스템을 매우 빠른 응답을 주는 시스템으로 오해 하고 있습니다 .

리얼타임 시스템의 정확한 정의는 사용할 수 있는 자원이 한정되어 있는 상황에서 작업 수행이 요청되었을 때 제한된 데드라인 안에 결과를 내주는 것을 말합니다 . 생명이나 안정성이 중요시되는 군사 , 자동차 , 비행기 , 우주 탐사 로봇 등에는 필수적인 아키텍처이며 이러한 고 신뢰성 , 안정성을 추구하는 영역에서 프레임워크를 논하고 있습니다 . 연재를 통해 리얼타임 시스템에 대한 전반적인 이해와 실적용 사례를 공유하고자 합니다. 

Ⅰ . 리얼타임 시스템의 이해

Ⅱ . 아직 건재한 Real Time CORBA 의 위치

Ⅲ . 리얼타임 분산 시스템의 아키텍처

Ⅳ . 리얼타임 스케줄링 기법

Ⅴ . 증권 거래 시스템과 리얼타임 시스템

자세히 보기 →

애플리케이션 생명주기 관리(ALM)하에서 지속적 개발의 6가지 비용절감요소

ALM 은 요구사항분석에서 유지관리까지 SW 개발 전주기적 관리 시스템이나 , 시스템 자체에 혼돈을 불러일으킬 수 있는 위험성을 내포하고 있으며 , 이는 곧 비용발생으로 연결됩니다 . 지속적 통합 방법은 SW 통합에서 발생할 수 있는 중요문제를 감소하고 보다 신속하게 SW 를 개발할 수 있다는 장점을 통해 요구사항분석 , 설계 , 테스트 등 각 요소별 비용절감효과를 보이고 있습니다 .

1. 요구사항 검증 비용

• 요구사항 수집 및 검증은 ALM의 치명적인 비용요소중 하나인데, 요구사항이 적절히 수집되고 검증되지 않는다면 실제적인 요구사항과 일치되지 않은 잘못된 솔루션의 설계와 개발로 인해 시간을 낭비할 수 있음

2. 설계 검증 비용

• 조기의 빠른 구축을 수행하는 지속적 개발은 개발 팀들이 중요한 설계 의문사항들을 우선순위화하도록 하고 설계 대안들을 프로토타입 할 수 있도록 하며 그것들을 조기에 테스트할 수 있도록 함 

3. 테스트 비용

• 지속적 개발에서는 테스트가 자동화되고 구축작업에 편입되어, 테스트 자원과 시간이 자동화된 테스트를 설계하는데 사용됨

4. 회귀 오류와 재작업 비용

• 회귀 오류 비용은 지속적 개발 절차인 자동화된 검토, 구축, 테스트 프로세스에 의해 완전히 회피될 수 있음

5. 통합 비용

• 지속적 개발은 모든 모듈이 하나의 시스템으로 통합되도록 절차화 함

6. 릴리즈 비용

• 지속적 개발은 개별적 릴리즈 주기에 대한 필요성을 부정함

자세히 보기 →

효과적 개발 및 운영을 위한 10가지 필수 DevOps 툴

DevOps 는 개발 및 운영체계를 통합하여 , 빠른 서비스 개발과 반영을 위해 개발된 개발모델로 기존의 개발팀과 운영팀이 합쳐지는 등 변화의 폭이 매우 큼으로 인해 적용하기 어려움 . 이에 효과적인 개발 및 효율적인 운영을 위한 오픈소스 및 상용화 등 10 가지 필수 DevOps 툴을 소개합니다 .

1. Git and GitHub

• 버전관리 시스템으로 알려진 Git은 코드의 버전을 저장하기 위한 저장소(repository)이고 GitHub은 코드가 다운로드 되고 공유될 수 있는 공개 관리 저장소(repository)임

2. Jenkins

• 젠킨스는 Agile창시자 중 한 명인 마틴파울러씨가 주창한 지속적 통합(Continuous Integration)을 구현하기 위한 자바 오픈소스 소프트웨어로서 웹 어플리케이션의 형태를 하고 있음

3. Berkshelf

• Riot Games에 의해 유지되는 이 오픈소스는 올바른 버전의 cookbook2)이 실행되는 것을 보장하기 위해 Chef서버로의 패치 및 배포 관리 방법을 제공함

4. Perforce

• Perforce Software 사에 의해 개발된 이 제품은 버전관리 시스템으로 분산개발환경에서 즉각적이 대응성이 있어 지역적으로 분산되어 있는 팀간 공동 개발작업 등을 지원함

5. Nagios

• 코드의 변경이 시스템 환경에 어떻게 영향을 미치는가를 모니터링하는 것은 어플리케이션 배포에 결정적임

6. Sensu

• Sensu는 Nigios와는 오픈소스 모니터링 프레임워크임

7. LogStash

• LogStash는 이벤트와 로그를 관리하는 툴로, 로그를 수집하고 파싱, 저장하여 추후 검색 등을 통해 사용할 수 있도록 웹 인터페이스를 제공함

8. Test Kitchen

• 인프라 관리 자동화 솔루션기업인 Opscode 사에서 배포한 Test Kitchen 툴은 사용자의 cookbook 개발 과정에서 시뮬레이션이 가능함

9. Vagrant

• 개발을 진행하다보면, 개발환경 구성에 굉장히 많은 시간이 필요하며, 참여하는 개발자의 수만큼 개발환경 구축에 드는 시간은 배가 되어 비효율적이며, 구축된 개발환경마다 버전 관리하기도 쉽지 않은 일임

10. Foodcritic

• Foodcritic는 Chef를 조사하고 테스트하기에 매우 좋은 오픈소스로 페이스 북 시스템 엔지니어인 Phil Dibowitz가 추천함

자세히 보기 →

소프트웨어 제품 라인에서 형상관리의 현실적인 이슈와 발전 방향

소프트웨어 제품 라인 공학과 연계하여 다양한 형상관리에 대한 꾸준한 연구가 진행되어 왔으나 이러한 결과를 적용하기에는 현실에서 존재하는 여러 가지 제약 및 예외적인 상황이 있다 . 본 원고는 기존의 소프트웨어 제품라인의 형상관리 기법 및 이러한 기법의 적용이 현실적으로 어려운 이유와 앞으로 나아갈 방향에 대해서 제안한다.

소프트웨어 제품 라인의 형상 관리 모델

1. 소프트웨어 제품 라인의 일반적인 형상관리 모델
2. 크루거(Krueger) 모델
3. Evolution-based 형상 관리 모델

현실적 이슈

1. 환경적 변화 전파 이슈
2. 초고도 결합도 제어 이슈
3. 관리 시점적 이슈

문제 해결을 위한 발전 방향

1. 결합도 관리를 위한 저장소(Repository) 연동 관리
2. 기능별 옵션 관리를 통한 변화 전파 자동화 

자세히 보기 →

모바일 생명주기 관리를 위한 사용자경험 (UX) 도출 4 가지 방안

모바일 기술은 하루가 다르게 발전하고 있고 멀티디바이스 테스팅과 이기종 플랫폼 개발이 대세가 됨에 따라 , 사용자경험 (UX) 의 전문성에 대한 요구가 심화되고 있습니다 . 이에 모바일 어플리케이션 생명주기 관리를 위한 UX 도출을 위해 디바이스의 사용자 여정지도 (customer journey map) 에서 사용자경험 활용까지의 4 가지 방안을 제시합니다.

• 모바일 생명주기 프로젝트는 새로운 기술을 빨리 획득하도록 소프트웨어 전문가들을 강요하고 있음
• 모바일 생명주기 프로젝트들이 멀티 디바이스 테스팅 및 크로스 플랫폼 개발을 취한 것처럼 , 또 다른 모바일 기술에 대한 수요는 바로 목전에 와있는데 그것은 바로 사용자 경험 (UX) 관련 기술임
• “ 실패 ( 죽음 )” 는 기업 모바일 애플리케이션 개발 기업들에게는 익숙하고도 중요한 뜻을 가진 단어임
• 상업용 모바일 애플리케이션 개발자들은 일반적으로 사용자 경험의 중요성을 인식하고 있으나 , 대다수의 기업 개발 팀들에 대해선 그것은 완전히 새로운 종목이나 마찬가지임
• 성공적인 모바일 애플리케이션 개발을 위해서는 UX 의 고려가 매우 중요함 

1. 사용자 여정 지도 (Customer journey map) 를 고안함
2. 시각적 디자인과 유용성 사이에 차이점을 이해함
3. 기본적 유용성 테스트를 수행함
4. 솔직한 사용자 경험상의 관심사항들을 다룸

자세히 보기 →

아키텍팅 노력과 IT 역량 간의 관계

오늘날 많은 기업들이 IT 에 대해 투자하고 있다 . 이런 투자의 배경에는 IT 투자가 생산성 및 효과성 향상과 같은 조직목표 달성에 기여할 것이라는 기대가 깔려 있다 . IT 하드웨어와 소프트웨어 같은 자원은 경쟁기업에 의해 손쉽게 복제될 수 있으므로 이에 대한 투자만으로 조직의 성과로 이어지는 것은 아니고 , 더 중요한 것은 이들 자원을 조합하고 결합할 수 있는 조직 고유의 능력을 갖추고 있는 여부라는 점을 강조한다 . 다시 말하여 , IT 투자가 성과로 이어지는 가의 여부는 조직의 IT 역량에 의해 크게 좌우된다는 것이다 .

MIS 분야는 이 IT 역량을 매우 중요하게 다루어왔으나 이 IT 역량을 어떻게 높일 수 있을 것인가에 대한 연구는 별로 없었다 . 최근 아키텍처 관련 노력이 하나의 대안으로 자주 언급되고 있다 . Bradley and Byrd[2006] 은 아키텍처는 IT 자원의 효과적 관리를 가능하게 해준다고 지적하였다 . Keen[1993] 은 시스템 간의 비호환성을 제거해주는 아키텍처 관련 능력이야말로 IT 역량 나아가서 조직 역량의 핵심이 될 수 있음을 지적하였다 . 나아가서 최근에는 아키텍처 노력을 전략적으로 확보해 두어야 할 조직역량으로 제시하기도 하였다 .

연구모형 및 가설

• 가설 1：아키텍팅 노력 정도가 IT 역량에 영향을 미칠 것이다.
• 가설 2：시스템 전면 개편 여부는 아키텍팅 노력이 IT 역량에 미치는 영향에 음으로 조절한다.

연구방법 및 분석결과

• 자료수집 및 변수 측정
• 척도의 타당성과 신뢰성
• 연구 문제의 검정

자세히 보기 →

SI와 솔루션 개발의 차이 - UX 편

1. UX에 대한 명확한 정의

대다수의 사람들이 UX에 대한 정의가 명확하지 않다고 생각한다. 기존의 UI로는 설명하기 어려운 부분들이 있어 의미적으로 ‘확장’의 필요성에 의해 나타난 것이 바로 UX이다. <그림 1>은 API와 UI의 정의를 나타낸 것이다. API는 시스템 간의 인터페이스이고, UI는 시스템과 사용자 간의 인터페이스이다. 인터페이스는 양자 간의 약속된 통신 방법이기 때문에 시스템 간의 통신이 많았던 SI에서는 매우 중요하게 다뤄졌던 분야이다.

API와 UI 정의

인터랙션과 UX

2. 소프트웨어에서 UX 역할

3. SI UX와 솔루션 UX의 비교

자세히 보기 →

ICT 넘버1 KOREA를 위한 또 하나의 투자, 소프트웨어 안전성

소프트웨어(SW)의 적용 범위가 조선, 발전, 자동차, 철도, 의료분야 등 전 산업 분야로 확대되면서 SW 품질이 그 어느 때보다 중요해지고 있다. 그동안 한국은  반도체, 디스플레이, 그리고 이동통신 단말기 등 하드웨어 중심의 IT 산업 분야에서는 세계 최고 수준을 누려왔다. 하지만 SW 분야, 특히 ‘높은 안전성’을 요구하는 SW분야에서는 선진국들과 격차가 있는 것이 사실이다. 특히 문제가 되는 부분은 국민 다수의 안전과 관련되는 국가인프라 관련 산업인데,  전자·기계장치와 연결되는 SW의 기능 결함은 치명적인 사고로 이어지게 되고, 이미 세계적으로  큰 혼란과 피해 사례를 보인 바 있기 때문이다. 또 이들 분야의 사고는 수출 저하는 물론, 우리나라 대외 이미지에도 치명적인 영향을 줄 수 있다.

고 신뢰 SW를 위한 개발 생명주기 모델

자세히 보기 →

IT 10대 전략 기술

IT 조사와 자문 분야의 세계적 기업인 가트너그룹에서 2016년 10대 전략 기술을 발표했다. 키워드는 ‘digital mesh’ 이다. 우리는 지금 장치, 다른 사람, 정보, 다양한 서비스의 중심에 앉아 있다고 할 수 있는데, 이것들은 유동성을 갖고 있으며 다이나믹하게 상호 연결되어 있다.  말하자면, 일상의 모든 것을 연결하면서 매우 자연스런 동적 네트워크 환경을 제공함으로써 물리적 세계와 가상 세계의 결합을 가능하게 하는 기술들이 주목 받을 것으로 내다봤다. 

디지털 그물망(Digital Mesh)

• 기기들간의 그물망(Device Mesh)
• 자연스런 일상 경험(Ambient User Experience)
• 3D 프린팅 소재(3D-Printing Materials)

똑똑한 스마트 기기들(Smart Machines)

• 만물 정보 (Information of Everything: IoE)
• 첨단 기계 학습 (Advanced Machine Learnin)
• 무인 장비와 사물(Autonomous Agents and Things)

새로운 IT 세계(New IT Reality)

• 능동형 보안 아키텍처(Adaptive Security Architecture)
• 첨단 시스템 아키텍처(Advanced System Architecture)
• 그물망 앱과 서비스 아키텍처(Mash App and Service Architecture)
• 사물인터넷 플랫폼(Internet of Things Architecture and Platforms)

자세히 보기 →

애자일을 새롭게 적용하는 개발팀을 위한 세 가지 기본원칙

SW 개발팀이 애자일 적용을 통해 처음 개발을 시도할 때 , 어디서부터 시작해야 할지 몰라 핵심 포인트를 잃어버리는 경우가 있음 . 애자일 방법론 도입초기에 개발팀이 출발점으로 잡아야하는 세 가지 기본원칙인 애자일 회고 (retrospectives), 전사적 테스팅 (whole-team testing), 자체편성 - 자기주도적 팀 (self-organized, self-directed teams) 등을 소개합니다 .

 서론

• 팀이 애자일 적용을 통해 개발을 시작할 때, 출발점을 찾는 것은 벅찬 임무일 수 있음
• 지난해 스웨덴 말모의 Øredev 개발자 컨퍼런스가 열리기 전, 참가자들이 5분 단위로 주제에 대해 논의하고 투표하는 모임 형식인 "린 커피(Lean Coffee)"로 불리는 것을 개최했을 때, 이러한 질문들이 제기됨

1. 애자일 회고

• 애자일 회고(retrospective)란 프로젝트 프로세스를 면밀히 살펴보고 배우며, 해결책을 모색하거나 새로운 방법을 시도하기 위한 계획을 수립하면서 일의 진행사항을 검토하는 것임
• 애자일 회고의 가장 단순한 형태는 프로젝트에 대해 지금까지 무엇이 맞고 틀린지 그리고 다음에는 무엇을 바꿀지에 대해 모든 팀원이 확인하도록 하는 것임

2. 전사적 테스팅

• 다른 애자일 개발 원칙은 전사적 테스팅(Whole-team testing)으로 이것은 전체 프로젝트팀이 테스트 전략을 결정하고 결과에 대한 책임을 분배하는 조직적 계획임
• 기존의 개발자가 사무실 구석에서 벗어나서 작업하고 스스로의 애자일 회고를 실행하며 "품질 보장"에 책임을 지는 "테스트 팀"인 애자일 조직에 들어갔을 때 불편할 수도 있음
• 전사적 테스팅을 수용하는 것은 단지 하나의 업무만을 완수하는 것이 아니라 소프트웨어를 실행시키는 것으로, 팀의 각 부분의 목표를 변화시키는 것을 의미함

3. 자체편성-자기주도적 팀

• 애자일 회고 이후 변경 사항이라는 힘든 부분이 발생함
• 계획 지향적인 팀은 승인을 필요로 함

4. 결론 : 애자일 개발 원칙의 중요

자세히 보기 →

테스트 진행단계를 어떻게 측정할 것인가

- 차트와 그래프 기반의 대시보드 활용방법 -
모든 테스트 관리자는 중요한 두 가지 질문에 맞닥뜨리게 되는데 첫째는 “ 현재 테스트의 진행단계는 어디인가 ” 이며 , 둘째는 “ 얼마나 더 테스트를 진행해야 하는가 ” 임 . 이러한 질문들에 대한 답을 구하기 위해 차트와 그래프 기반의 테스트 프로젝트 대시보드 활용 사례를 제시함 .

• 모든 테스트 관리자가 답변을 해야 하는 두 가지 중요한 질문이 있음.
• 테스트 관리자들은 테스트  프로젝트의 진행 상황을 추적함에 있어 불량률에 너무 많이 의존하고 있음 . 
• 결함 숫자는 중요하지만 , 그것들이 전체를 말하는 것은 아니기 때문에 테스트 프로젝트가 진행하는 방법에 대한 큰 그림을 만들려면 테스트 관리자는 측정하고 보고해야 함.
• 여기서는 테스트 대시보드에 추가할 수 있는 네 개의 샘플 차트와 그래프를 제시하고 , 이러한 측정들이 중요한 이유와 테스트 프로젝트 진행 방법의 큰 그림을 그려볼 수 있는 방법을 설명할 것임.

1. 테스팅은 언제 완료될 것인가

2. 테스터는 얼마나 진행하고 있는가

3. 개발자는 얼마나 진행하고 있는가

4. 시간 경과에 따른 결함 동향

자세히 보기 →

전사적 프로젝트 관리 이해와 적용 사례

전사적 프로젝트 관리 (Enterprise Project Management) 이해와 적용 사례

Ⅰ. 전사적 프로젝트 관리 현황 및 효과

프로젝트 관리라고 하면 개별적 프로젝트 관리를 대상으로 착수부터 종료에 이르는 과정을 관리하는 것으로 생각하게 마련이다 . 개별 프로젝트를 관리하는 것이 어떻게 효과적이고 효율적으로 하나의 프로젝트를 수행하는지에 대한 방법이라면 , 전사적 프로젝트 관리 (Enterprise Project Management) 는 동시 다발적으로 진행되는 복수의 프로젝트 환경에서 비즈니스 적응력과 대응력을 높여 수익성을 높이고 위험을 줄일 수 있는 방안을 마련하는 것이다 .

2010 년 475 개 기업을 대상으로 수행된 InformationWeek Analytics Enterprise Project Management Survey 결과를 살펴보면 , 70% 이상의 조직에서 전사적 프로젝트 관리 방법을 적용하고 있으며 , 주로 전사적 관점에서의 우선순위와 프로젝트에 대한 표준화된 접근방법을 수행하기 위해 전사적 프로젝트 관리 조직을 운영하는 것으로 알려져 있다 . 또한 2012 년 수행된 미국 PM Solutions 의 조사에 따르면 , 전사적 프로젝트 관리 조직을 운영하는 조직들이 2000 년 48% 에서 2012 년 87% 로 증가하였으며 , 프로젝트 목표 달성과 고객만족도 향상 , 예산 및 납기 준수 그리고 생산성 개선에서 직접적인 기여를 하고 있다고 제시하고 있다.

Ⅱ. 전사적 프로젝트 관리 방법론 소개

앞에서 전사적 프로젝트 관리 접근방법은 크게 2가지로 구분하였으나 일반적으로 통용되는 전사적 프로젝트 관리방법은 전사 목표 달성을 위한 조직적 경영관리 관점에서의 접근방법을 의미한다. Paul Dinsmore가 펠로우(Fellow)로 있는 PMI(Project Management Institute)는 CMM(Capability Maturity Model)의 성숙도 개념과 PMI의 지식 영역을 통합한 전사적 프로젝트 관리방법론으로 프로젝트 관리 성숙도 모델(Project Management Maturity Model: PMMM)을 제시하였다.

Ⅲ. 전사적 프로젝트 관리 사례 분석

조직의 프로젝트 관리 성숙도를 향상시키기 위해서는 전사적 프로젝트관리를 지원할 수 있는 기반 체계 구축하고 프로젝트 관리에 대한 지속적인 훈련과 체계를 제공하는 것이 중요하다. 효율적인 전사 프로젝트 관리를 위한 기반 체계로 포트폴리오 관리와 프로그램 관리가 필요하고 이를 수행하고 관리하기 위한 프로젝트 관리조직이 정착될 필요가 있다.

자세히 보기 →

클라우드 & 버츄얼 네트워킹 컨퍼런스 안내(10/22(목))

클라우드, SDN/NFV 기술을 활용한 기업 IT인프라 변화상을 점검하고 이에 대응한 새로운 비즈니스 창출 방안을 제시하고자 '클라유드, SND, NFV 활용 전략' 란 주제로 오는 10월 22일(목)에 여의도 중소기업중앙회 그랜드볼륨에서 [클라우드 & 버추얼 네트워킹 컨퍼런스 2015]을 개최합니다.

자세히 보기 →

제58회 SW공학 Technical 세미나 안내(10/29(목))

SW Quality Insights 제 58회 SW공학 Technical 세미나에 여러분을 모십니다.

본 세미나는 국내외 SW전문가를 초빙하여 SW개발 관련 최신 기술 동양을 파악하고 개발과정에서의 경험을 공유하는 등 SW개발자와 관리자의 역량강화를 위해 매월 지속적으로 개최하고 있습니다.

이달의 주제는 "SW공학을 통한 비즈니스 혁신방안과 모델 기반의 클라우드 서비스 개발·운영" 입니다.

신청하러 가기 →

2015년도 SW품질대상 공모

국내 SW산업 발전에 크게 기여한 SW공학기술 적용 우수 사례 기업을 선발 포상하고, 그동안의 노고를 격려하고자 합니다.

• 신청서 제출기한: 2015.11.01(일) 24:00
• 제출방법: 전자문서로 제출(관련 자료를 포상담당자 이메일로 송부

        - 서명 등이 있는 원본은 PDF파일로 제출하되, 작성된 글파일도 함께 제출

• 제출서류: 신청서 1부, SW품질대상 심사자료 1부

신처하러 가기 →

기업의 빅데이터 활용을 방해하는 4가지 공통요인

데이터를 얻는 능력 , 즉 데이터를 이해하는 능력 , 처리하는 능력 , 가치를 뽑아내는 능력 , 시각화하는 능력 , 전달하는 능력이야 말로 앞으로 10 년간 엄청나게 중요한 능력이 될 것임은 틀림없다고 생각합니다 . 빅데이터 분야가 성장세임에도 불구하고 빅데이터의 진가에 대한 인식부족과 빅데이터 관리 및 분석에 필요한 지식 기반이 취약하여 기업의 충분한 효과를 담보하지 못하고 있습니다 . 본 원고에서는 빅데이터의 활용을 방해하는 4 가지 공통요인을 살펴보고 개선을 위한 가이드를 제공하는 기회를 삼고자 합니다 .

1. 기업들이 시각화의 중요성을 인식하지 못함
2. 데이터를 분석하는 것보다 수집하는데 더 많은 투자를 함
3. 기업들은 실력의 격차에 직면해 있음
4. 정보를 빠르게 처리하기 위한 시스템의 불충분으로 분투함

자세히 보기 →

클라우드 컴퓨팅 환경 하의 효율적인 SW수명주기 관리

어플리케이션이 클라우드 상에서 관리될 때 성능 문제가 발생할 가능성이 훨씬 커짐 , 그러나 이러한 성능 문제에 대응하는 방식에 있어 성능이슈를 해결하기 위해 고장이 발생할 때까지 기다리는 것은 특히 클라우드 환경에서 문제가 됨 . 성능문제를 예방하기 위한 가장 좋은 방법은 소프트웨어 생명주기 초기에 클라우드 이슈를 고려하는 것임 . 본 원고에서 클라우드 응용프로그램 성능 이슈를 소프트웨어 생명주기 초기에 다루기 위한 Best Practice 를 제안하고자 함 . 

1. 클라우드 인프라의 복잡성을 이해할 것
2. SW생명주기 시작부터 응용프로그램에 탄성을 구축할 것
3. 경영자들이 클라우드 성능에 투자하게 할 것
4. 단위테스트로 성능을 고려할 것
5. 서비스수준협약(SLA)를 너무 의지하지 말 것

자세히 보기 →

스크럼 개발방법에서의 측정지표에 관한 분석 및 도입방안

Ⅰ . 애자일 방법론의 한계 및 대안

오늘날 소프트웨어 개발은 시장환경의 변화에 따라 사용자의 요구사항에 빠르게 대응하고 기술 변화에 유연하게 대응할 수 있어야 한다 . 이러한 소프트웨어의 새로운 변화에 따라 계획 중심의 전통적인 개발 방법보다는 애자일 (Agile) 과 같은 가볍고 변화를 수용하는 개발방법론을 활용하여 개발하는 사례가 증가하고 있다 최근에는 신속한 변화와 반응이 중요한 웹 서비스 분야뿐만 아니라 게임 , 임베디드 및 SI 분야에서도 애자일 도입이 확산되는 추세이다 .

Ⅱ . 스크럼 및 소프트웨어 측정 프레임워크 이해와 측정지표 분석

     2.1 스크럼 소개 

     2.2 소프트웨어 측정 프레임워크 

     2.3 스크럼 측정 분석

Ⅲ . 스크럼 개발방법 도입바안

위의 평가 결과를 바탕으로 스크럼을 도입하는 조직에서 고려할 사항을 살펴보도록 하자. 첫째, 비용 절감의 목적으로 스크럼을 도입하는 조직에서는 전체 예산과 실적을 관리할 수 있는 별도의 방법이나 활동을 고려할 필요가 있다. 제품 백로그로부터 제품을 릴리즈하는데 필요한 범위를 결정하고 필요한 스프린트를 산정해 본다. 첫 스프린트는 개발보다는 전체 개발 일정과 시스템 청사진(blueprint) 기획에 초점을 두고 전체 스프린트 횟수와 투입될 비용을 산정해보는 것이 필요하다. 전체 투입 예산이 산정되면 이를 기준선(baseline)으로 삼고 스프린트 종료 시점에서 전체 예산 대비실적을 분석해 볼 수 있다. 

자세히 보기 →

SW 품질관리자가 주도해야 할 5가지 보안테스트 원칙

소프트웨어 개발 프로젝트 기간 내 품질 보증 담당자들은 ( 또는 팀 ) 보안 테스트에 있어 기존 개발 프로세스보다 더 큰 역할을 수행해야 합니다 . 품질 보증 담당자는 개발자 관점이 아닌 사용자 관점에서 보안 테스트에 대한 역할을 주도해 나가야 합니다 . 본 보고서에서는 보안 전문가와 품질 보증 전문가들이 응용프로그램 보안 테스트 수행을 위한 5 가지 기본 원칙들을 제안합니다 .

1. 조기 참여하여 보안 요구사항의 개선을 위한 작업을 수행
2. 사용자 인터페이스 테스트로 시작
3. 주요정보가 있는 곳을 알아내고 모든 가능한 경로를 보호
4. 각 개발자들의 강·약점을 이해하고 거기에 맞춰 테스트를 수행
5. 응용프로그램이 할 수 없는 것에 대한 테스트와 에러 메시지에 세심한 주의

자세히 보기 →

애자일 개발팀이 주목해야 할 SW품질관리 3가지 핵심요소

성공적으로 애자일 방법론을 적용했으며 , 스크럼 팀으로서 교육단계와 성장단계를 통해 업무를 잘해내고 있음에도 불구하고 , 일반적으로 문제는 테스팅 작업을 거의 강조하지 않는 새로운 개발에서 시작됩니다 . 이 글에서는 품질이 우수한 제품을 생산하기 위해 스크럼과 테스트 팀의 능력 모두를 향상시킬 수 있는 세 가지 방법을 제안합니다 . 강한 의사소통 라인을 구축하고 , 테스트 시기를 유연하게 하며 , 제품이 개발됨에 따라 개선되는 빠르고 효과적인 테스팅 방법들을 사용하는 테스트 가치를 향상시킴으로써 품질관리개선에 기여할 것입니다 .

• 강한 의사소통체계 구축하기 (1)
• 강한 의사소통체계 구축하기 (2) - 스크럼 팀을 편안한 분위기로 만들기
• 유연한 테스트 시기
• 빠르고 효과적인 테스트 방법

자세히 보기 →

요구사항의 성공적 기술을 위한 6가지 핵심요소

소프트웨어 개발 프로젝트 활동 중 , 비즈니스 이해관계자들로부터의 프로젝트 성공을 위한 정의 즉 , ‘ 시스템 요구사항 ’ 을 면밀히 기술하는 것은 매우 중요한 활동임입니다 . 그럼에도 불구하고 비즈니스 이해관계자들은 이에 대한 사항들을 잘 얘기하지 않으며 , 프로젝트 팀 구성원들도 이를 도출하기 위한 작업을 간과하기가 쉽습니다 . 본 장에서는 프로젝트 팀 구성원들이 요구사항을 보다 잘 기술할 수 있도록 하기 위한 상식적인 6 가지 조치들을 제안하고자 합니다.

1. 이해관계자들이 요구사항을 구체화 할 수 있도록 가이드하라
2. SW 테스트 수행자들을 조기에 참여시켜라
3. 이해관계자들의 관점으로 성공을 정의하라
4. SW 요구사항 재사용 환경을 조성하라
5. 요구사항은 비즈니스 규칙을 따른다
6. 프로젝트 이해관계자들에게 승인절차를 용이하게 하라

자세히 보기 →

안드로이드 소프트웨어를 위한 테스트케이스 생성 도구

Ⅰ . 서론

최근 안드로이드 소프트웨어의 숫자가 날로 증가하고 있는 동시에 사용자들의 요구 수준도 함께 높아지고 있다 . 이에 따라 소프트웨어의 품질을 높이기 위한 테스트과정의 중요성도 두드러지고 있다 .

안드로이드 소프트웨어의 품질을 높이기 위해서는 GUI 에 대한 검증이 선행되어야 한다 . 하지만 , GUI 테스트과정은 GUI 뿐만 아니라 그 내부 동작 및 사용자의 사용 흐름에 대한 테스트까지도 포함해야 하므로 각 테스트케이스를 생성하고 재현하여 테스트하는 과정이 복잡하고 이에 많은 시간이 소요되는 문제점을 내포하고 있다 . 이를 해결하기 위한 GUI 테스트 기법들 중에서 편리성과 테스트의 정확성으로 인해 현재 가장 많이 사용되고 있는 RPB(Record-Play Back) 기법을 적용한 테스트케이스 생성도구를 제안한다 .

RPB 기법은 대상 프로그램 , 대상 동작에 따라 테스트케이스를 각각 생성해야하기 때문에 대상 프로그램에 대한 종속성이 생기고 테스터의 비효율적인 노동을 증가시킨다 . 또한 , 안드로이드 소프트웨어에 적용하기 위해서는 임베디드 특성에 대한 추가적인 고려가 필요하다 .

이러한 문제점 해결을 위해 원시코드와 테스트코드의 분리를 위하여 테스트정보를 메타화하고 메타데이터와 원시코드를 결합하여 테스트케이스를 생성하는 방식을 제안한다 . 이러한 구조의 사용은 테스트코드의 종속성 제거는 물론 테스트정보의 가독성과 유연성을 높일 수 있다 .

Ⅱ . GUI 테스트 기법

Ⅲ . RPB 기반 소프트웨어 테스트케이스 생성 도구

1. 기반 정보 구성
2. 테스트정보 생성과정
3. 테스트케이스 생성과정
4. 실행화면
5. 특징

Ⅳ . 결론

자세히 보기 →

SW테스팅 비용절감을 위한 4가지 Tip

모든 소프트웨어 테스팅 기술들 중에서 품질을 희생하지 않고 비용을 절감하는 방법이 있다면 기업들이 언제나 환영할 것입니다 . 여기서 제공하는 팁의 목표는 어떤 테스트 팀이라도 새로운 도구들 구입이나 다른 비용 투자 없이 , 보다 빠르게 적용할 수 있도록 하는 구체적인 단계를 제공하는 것입니다 . 여기서 제안하는 조언은 소프트웨어 테스트 비용은 절감하고 품질은 높이는 연구를 기반으로 하며 , 네 개의 새로운 소프트웨어 테스트 기법을 소개하고자 합니다 .

Tip 1: 일반적 실수에 대한 고려
실수는 언제 어디서나 발생할 수 있음에 따라 모든 실수를 방지하려는 노력은 엄청난 고비용과 비효율적인 것으로 판명이 났으나, 계속된 실수는 방지할 수 있는 사항임.

Tip 2: GUI 환경 하에 테스트 자동화
자동화 테스트 때에 모든 빌드에 높은 수준의 함수를 요구하는 코드를 작성하는데 집중하는 것이 필요함.

Tip 3: 문서화하는 시간 축소
테스터들은 응용프로그램을 수정 보완하는 작업에만 시간을 많이 소비하는 것은 아니며, 많은 시간이 소비되는 작업 중 하나는 문서화 즉 작업을 계획하고, 한정하며, 최신상태로 유지하기 위한 문서를 업데이트하는 것임.

Tip 4: 스크립트 작성 대신 테스터 교육 수행
애자일 테스팅 데이즈에서 헤인즈의 첫 번째 질문은 시스템에 익숙하지 않은 신임 테스터들을 대하는 방법임

자세히 보기 →

GIT 핵심을 활용하는 프로젝트 개발 part 2

GIT 기반의 온라인 협업 개발

Ⅰ. 프로젝트 협업개발과 GIT

개인이 진행하는 프로젝트가 아니라면 프로젝트 구성원들과 같이 개발하는 건 당연하다. GIT은 협업 개발을 지원하기 위해서 GIT Server를 제공한다. 내 로컬의 .git 디렉토리 안에 모든 commit정보가 포함되어 있지만, 이것은 내PC에서 일어난 일이고, 이를 동료, 프로젝트 구성원과 공유해야 하는데 이것을 가능하게 하기 위해서는 GIT Server를 구축하거나 GITHUB 와 같은 온라인 호스팅 서비스를 이용하면 된다. 이렇게 구축된 Server에 내가 개발한 내용을 업로드하고 프로젝트 구성원이 확인한 후, 다시 이를 받아서 수정하고 업로드 하는 과정이 가능하다. GIT server라는 건 자체적으로 구축1) 할 수도 있지만, 본 문서에서는 그 과정을 생략하고 대표적인 GIT호스팅 서비스인 GITHUB를 통한 GIT 온라인 협업 과정을 살펴본다.

Ⅱ. GITHUB 협업 개발 시나리오

기본적인 협업의 시나리오

• 내가 개발 한 코드를 commit하고GITHUB에 업로드 한다(push) 
• 동료 B는GITHUB에서 소스코드의 변경사항을 내려 받는다 (pull) 
• 동료 B는 코드를 수정하고 다시GITHUB에 업로드 한다(push)

1. 기본적인 협업 개발 방법

2. GITHUB협업 중 발생하는 충돌문제의 해결

3. pull이 아닌 fetch와 merge를 통한 원격지의 충돌 해결

자세히 보기 →

[SW공학동영상 7화] Relationship between Automotive SPICE and ISO 26262

• A-SPICE / ISO 26262 Process Mapping
• Major work products in A-SPICE Engineering Process
• Mapping between A-SPICE ENG and ISO 26262
• A-SPICE / ISO 26262 Integrated Engineering Process

SI와 솔루션 개발의 차이 - 아키텍처 편

불과 얼마 전까지만 해도 소프트웨어는 기관이나 기업에서 필요에 의해 만들어지는 경우가 대부분이었습니다. 컨설팅이 고객에게 시스템의 필요성을 전달하고 고객은 필요한 예산을 확보한 후 SI(System Integration) 프로젝트로 이어지는 흐름이었습니다. 하지만 최근에는 어느 정도 구축이 완료된 상태인 ICT의 투자 필요성이 많이 줄어들었고 오픈 플랫폼, 클라우드와 같은 다양한 ICT 기술이 나타나면서 SI 사업은 예전보다는 많이 줄어들고 있는 추세입니다.

이와는 반대로, 모바일 디바이스와 같은 개인용 기기가 늘어나면서 불특정 다수가 사용하는 솔루션 소프트웨어가 증가 추세에 있습니다. 솔루션 소프트웨어는 고객이 미리 정해져 있지 않기 때문에 소프트웨어를 개발하는 프로세스나 방법이 SI와는 다소 상이한 편입니다. SI는 고객의 요구사항을 파악하고 분석하는데 많은 시간을 할애하지만 솔루션은 개발과 딜리버리, 그리고 업그레이드 등에 많은 시간을 할애합니다. 다수의 사용자가 원하는 소프트웨어를 개발하고 오랫동안 사용될 수 있도록 서비스하고 업그레이드를 해야 하기 때문입니다.

SI와 솔루션 소프트웨어의 차이를 좀 더 체계적으로 확인하여 소프트웨어 개발에 도움을 주고자 이번 달에는 SI와 솔루션 개발의 차이를 아키텍처, UX, 테스트, 그리고 개발 관점으로 알아보고자 하며, 이번 회에서는 아키텍처 관점으로 차이점을 살펴보기로 합니다. 먼저, SI의 아키텍처와 솔루션 아키텍처의 구성과 역할에 어떤 차이가 있는지 알아보고, 두 아키텍처의 설계 프로세스를 비교하여 차이점을 살펴보기로 합니다.

자세히 보기 →

빅데이터 플랫폼 구축 사례와 오픈소스 활용

‘빅데이터’ 라는 단어가 국내외 IT분야의 화두가 된 지도 벌써 3년이 훌쩍 넘었습니다. 이제는 IT컨퍼런스 주제에서도 약간 식상한 기술이라는 느낌까지 들 정도입니다. 또한, 국내 IT 선도 업체들이 5~7년 전부터 하둡을 비롯한 빅데이터 분석 기술을 활용해 프로세스 개선 / 서비스를 운영해 온 것을 보면, 지금쯤은 보편적이고 친근한 기술이 되어 있어야 함이 마땅할 것입니다. 하지만 막상 빅데이터 플랫폼을 실제로 구축 하려고 하면, 수많은 고민과 어디서부터 시작해야 할 지 모르는 막막함이 밀려오는 게 사실입니다. 이런 고민을 해결하기 위하여 다양한 빅데이터 플랫폼 구축 경험이 있는 SK(주) C&C 이정일 차장을 만나 빅데이터 도입 방법론에 대해 살펴 보기로 하였습니다.

1. SK C&C 빅데이터 플랫폼 구축사례 2. 준비사항과 필수 요소 3. 빅데이터 배포판을 이용한 플랫폼 구축 방법론에 대한 견해 4. 빅데이터 플랫폼 구축을 시작하려는 중소기업 / 개발자를 위한 Tip

자세히 보기 →

Readiness & Fit Analysis

조직이 새로운 실행방법 (Practices) 을 적용할 때 , 적용과 관련한 많은 이슈들을 만나게 됩니다 . SEI 는 조직이 새로운 실행방법을 적용할 때 , 조직과 실행방법간의 상호 적합성의 원칙이 관련된다는 사실을 알 수 있었습니다 . 따라서 RFA(Readiness and Fit) 이라 불리는 분석방법을 통하여 애자일 실행방법을 적용하려는 조직의 획득관리가 어떻게 변화되고 애자일 원칙에 일치되어야 하는지의 방법을 10 가지 핵심요소를 가지고 설명하고자 합니다.

SW획득관리를 위한 핵심적인 10가지 요소

1. 명확한 프로그램 목표

“비즈니스 혹은 프로그램 목표는 명확해야하고 이해관계자의 관심사항을 반영해야한다.”

2. 정의된 성공 전략의 정의

“성공전략은 정의되고 명확하게 의사소통되어야 한다.”

3. 프로젝트 투자의 보장

“프로젝트를 위한 투자가 보장되어야 한다.”

4. 밀접한 이해관계자/개발자 협력 추진

“개발자와 기타 이해관계자들 사이에 긴밀하게 협력 하도록 하는 메커니즘이 계약 및 획득 전략에 취해져야 한다.”

5. 임시 납품 추진

"공식적인 납품 사이에 중간 검증과 납품을 하게하는 계약과 획득 전략 메커니즘을 취해야 함.”

6. 관리감독의 애자일 원칙 지원

“계약 감독 메커니즘은 애자일 원칙과 일치되어야 한다.”

7. 소프트웨어 목표와 프로그램 목표의 명확한 일치화

“소프트웨어 관련 목표와 프로그램 수준의 목표를 명확히 일치시켜야 한다.”

8. 적절한 계약 유형 

"계약 유형은 프로그램에서 애자일 방법론 사용을 설명해야 한다.”

9. 적절한 생명주기 활동

“획득전략에서 기획된 생명주기 활동은 애자일 방법론과 양립하여야 한다.”

10. 대규모적 애자일 프로젝트 추진 가능성 고려

“획득전략은 프로그램에서 요구되는 규모 정도로 애자일 방법론의 사용을 고려해야 한다.”

자세히 보기 →

15년도 SW공학경쟁력강화사업 성과분석 및 SW공학 정책수요조사 용역

용역입찰공고

1. 입찰에 부치는 사항
 가 . 입찰건명: 15 년도 SW 공학경쟁력강화사업 성과분석 및 SW 공학 정책수요조사 용역
 나 . 추정소요예산: 70,000,000 원 (부가세포함)
 다 . 용역기간: 계약체결일로부터 약 2 개월
 라 . 제안서 (입찰참가신청) 제출 (시간초과시 서류제출이 불가합니다 .)
     1) 제출마감일자: 2015. 10. 19. ( 월 ) 15 시까지
     2) 접수방법 : NIPA 전자계약시스템 을 통한 온라인 접수 ( http://cont.nipa.kr )

      * 회원가입 후 서류는 전자파일로 제출 , 방문접수 불가

2. 입찰방법: 제한경쟁입찰 (공동수급허용)
3. 낙찰자 선정방법: 협상에의한계약 (기술 : 가격 = 90:10)

제안서를 제출받아 평가한 후 협상대상자를 선정 ( 개별통지 ) 하여 , 기술 / 가격협상에 참가할 수 있는 자격을 부여하고 제안서 평가 1 순위 업체부터 협상하여 우리 원에 가장 유리하다고 인정되는 업체를 낙찰자로 결정합니다 .

자세히 보기 →

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

• 핀테크 비즈니스 모델과 관련 기술에 대한 이해
• 창의적 제품개발과 Agile 방법론 활용
• 효율적인 협업을 위한 신개념 문서관리 방법
• 전자문서활용 및 관리에 대한 기술적 트렌드
• 전자문서를 이용한 스마트 재난통보서비스
• 전자출판물 표준 포맷 EPUBv3

발표자료 보러가기 →

프로젝트 위험관리의 10가지 Golden Rules

불확실한 프로젝트 상황에서 위험요소들을 사전에 미리 주도적으로 다룰 수 있다면 , 기업은 그만큼 금전적인 이익을 얻을 수 있 등 프로젝트 위험관리는 비용측면에서도 매우 중요한 프로세스입니다 . 위험관리는 프로젝트 위협의 영향을 최소화하고 기회를 포착 할 수 있게 하며 , 적시에 적절한 예산을 가지고 품질수준을 맞추어 프로젝트를 종료할 수 있게 합니다 . 본 보고서에서 프로젝트 위험관리를 적용하기 위한 10 가지 중요한 Rule 을 소개하고자 합니다 .

10가지 Golden Rules

• Rule 1. 프로젝트에서 위험관리 부문을 생성할 것
• Rule 2. 프로젝트 초기에 위험을 도출할 것
• Rule 3. 위험에 관한 의사소통을 지속할 것
• Rule 4. 위협과 기회 모두를 고려할 것
• Rule 5. 소유권의 명확화할 것
• Rule 6. 위험에 대한 우선순위를 결정할 것
• Rule 7. 위험에 대한 분석을 면밀히 할 것
• Rule 8. 위험반응을 기획하고 이행할 것
• Rule 9. 프로젝트 위험을 기록할 것
• Rule 10. 위험과 관련된 과업을 추적할 것

자세히 보기 →

GIT 핵심을 활용하는 프로젝트 개발

 GIT Branch중심의 프로젝트 개발

프로젝트 개발에서 생기는 일은 무엇인가?

복잡한 프로젝트 소스관리를 위해 필요한 건 무엇일까?

GIT Branch의 활용

GIT Branch 중심의 프로젝트 개발 방법

1. 개발 시작하기
2. 신규 기능 개발하기
3. 신규 기능을 master에 합치기
4. beta버전 출시
5. 그 외 사항을 branch로 개발하기

자세히 보기 →

W품질비용 절감방안

엔지니어는 시스템의 진단 및 재작업에 시간을 소비함으로써, 개발 일정의 지연, 지원비용 상승, 회사 제품의 명성 훼손 등의 결과를 초래하기도 합니다. 이러한 실패 비용을 최소화하고 전체 품질비용을 줄이면서도 통제를 가능하게 하는 평가비용에 투자하게 되면, 프로젝트 통제가 용이해지고 더 나아가 프로젝트를 성공시킬 수 있는 지름길이 되는데, 본 보고서를 통해 이에 대한 방안을 소개하고자 합니다. 

• 품질 비용은 모든 프로젝트에서 중요한 비용이며, 신중한 관리자들은 이 비용을 줄이기 위한 방안을 찾고 있음
• 품질비용은 검토(review), 품질보증인프라, 준비테스트를 포함하는데, 이러한 품질 비용은 평가비용에 속함.
• 엔지니어는 진단 및 재 작업에 시간을 소비함으로써, 개발 일정 지연, 지원비용 상승, 회사 제품의 명성 훼손 등의 결과를 초래하게 되는데, 이러한 실패 비용은 매우 의미 있는 품질비용이며, 직접적인 통제가 어려운 비용임.
• 그러나 실패 비용을 최소화하고 전체 품질비용을 줄이면서도 예측을 가능하게 하는 평가비용에 투자함으로써, 간접적으로 이를 통제할 수 있음.

1. 품질비용 : 평가비용 vs 실패비용
2. 실패비용을 절감하기 위한 평가의 레버리지 효과
3. 통제 하에 존재
4. 표 1에 관한 해석

자세히 보기 →

태블로 알고리즘 기반 온톨로지 T-Box 추론 및 논리적 오류 원인 탐지 시스템

시맨틱 웹에서 중추적인 역할을 수행하는 것은 기계가 이해할 수 있도록 개념들을 명확하게 명시하고 , 개념을 공유할 수 있는 형식으로 표현한 온톨로지입니다 . 온톨로지 스키마의 내부에 많은 논리적 표현이 반영될수록 구축 과정은 점점 복잡해집니다 . 따라서 온톨로지를 구축하는데 있어 온톨로지 설계자들은 의도되지 않은 논리적 오류를 온톨로지 내용에 포함시킬 수 있습니다 . 이런 이유로 온톨로지에 존재하는 논리적 오류를 탐지하는 것은 매우 중요한 과정이 되었습니다 . 또한 온톨로지 기반의 시맨틱 검색에 있어서 온톨로지들을 구성하는 개념 (class) 들 간의 숨겨진 관계를 추론하는 것은 검색 결과의 질을 높이는데 도움을 줍니다 .

온톨로지의 논리적 오류를 탐지하고 온톨로지를 구성하는 개념들 간의 포함관계 (subsumption) 를 도출하기 위해서 , 많은 OWL 추론 엔진이 소개되고 있습니다.   현재 소개되고 있는 온톨로지 추론 엔진 대부분은 기술 논리 기반의 태블로 알고리즘 (Tableaux algorithm), F- 논리 , 규칙 기반 추론 방식을 적용하여 개발되었습니다 . 일반적으로 규칙 기반 추론 엔진에 비해서 태블로 알고리즘 기반의 온톨로지 추론 엔진은 정확하면서 (sound) 좀 더 완전한 (complete) 추론 결과를 보여주는 반면에 온톨로지 개체 추론에 있어서는 상당히 느린 속도를 보이고 있습니다 . 따라서 대용량의 개체 추론이 필요한 경우는 규칙 기반 추론 엔진이 주로 사용되는 추세입니다 .  

1. 태블로 알고리즘과 T-Box 추론
2. HAL 의 구조
3. T-Box 추론을 위한 최적화 기법
4. 시스템 평가

자세히 보기 →

SW 교체시기를 판단할 수 있는 4가지 비용 요소

과거에는 소프트웨어의 교체시기를 결정하는데 있어서 직관적이고 즉흥적인 방법을 사용하였다면, 현재는 IT 활동들을 측정하는 시스템을 통하여 데이터를 확보할 수 있는 기반이 갖추어졌으므로, 교체시기 결정의 과학적 접근법이 필요합니다.

따라서 측정된 IT 활동 데이터로부터 시스템이 교체해야 할 시간임을 의사결정하기 위한 4가지 비용적 요소를 소개합니다.

유지보수(Maintenance)

기본적으로 기업은 시스템을 유지보수하는데 매년 얼마의 비용을 소비하는가를 알고 있음

사업비용(Business Cost)

실질비용을 위하여, 사업비용을 계산에 반영할 필요가 있음

시스템의 접근성, 생산성 손실비용, 위험비용 등으로 인한 사업비용을 고려해야함 

손실액(Lost Revenue)

오래된 시스템 사용으로 인한 손실비용은 얼마나 되는지를 고려해야할 필요가 있음

직원의 사기(Staff morale)

오래된 시스템을 유지하기 위한 인력활용 비용과 이로 인해 고용기회를 잃을 수 있는 첨단기술을 보유한 인력의 기회비용 등을 고려해야함

자세히 보기 →

EPC(Electronic Product Code) 정보 서비스 성능 테스트 도구

최근 RFID(Radio Frequency Identification) 태그 가격이 떨어지고 크기가 작아져, RFID 기술은 유통 물류, 제약 물류 등 많은 분야에서 필수 기술이 되어 가고 있습니다. EPCglobal EPC(Electronic Product Code)를 이용한 표준 아키텍처를 제안했습니다. 이중 EPCIS(EPC Information Service)는 이벤트 데이터를 저장하고 검색 하는 기능을 제공합니다. EPCIS가 EPCglobal 표준 아키텍처 상에서 가장 많은 부하를 받는 곳입니다. 실제 예로 EU(European Union)에서 2006년 BRIDGE (Building Radio Frequency Identification Solutions for the Global Environment) 프로젝트에서 그러한 부하를 확인 할 수 있습니다. BRIDGE 프로젝트는 RFID 미들웨어를 유럽 몇몇의 생산 공장과 물류 센터에 설치하고 실제로 RFID를 이용하여 물류 운송과정을 시험 하는 것인데 이 프로젝트에서 가장 문제가 되었던 시스템이 바로 EPCIS와 DS(Disc overy Service)의 성능 문제였습니다. 많은 양의 데이터를 빠르게 처리 하지 못하여 하나의 EPC를 검색하기 위해 지연되는 시간이 15초 이상이 소비되었습니다.

문제정의

첫 번째 문제는 데이터 생성 지연 문제이다.

RFID 데이터를 실시간으로 생성하는 논문들[9, 10, 11]의 테스트 대상인 ALE는 실시간 데이터만을 처리한다. 이벤트 사이에 일정한 대기 시간이 있을 경우 시나리오대로 데이터를 생 성하기 위해서는 실제 시나리오 상의 시간대로 테스트 데이터 생성 도구도 대기했 다가 데이터를 생성해야 하므로 대량의 데이터를 생성하기에 부적합하다. 

두 번째 문제는 데이터 생성 중 대기시간문제를 해결해야 한다.

RFID 데이터를 실시간으로 생성하는 논문들[9, 10, 11]의 테스트 대상인 ALE는 실시간 데이터만을 처리한다. 이벤트 사이에 일정한 대기 시간이 있을 경우 시나리오대로 데이터를 생성하기 위해서는 실제 시나리오 상의 시간대로 테스트 데이터 생성 도구도 대기했다가 데이터를 생성해야 하므로 대량의 데이터를 생성하기에 부적합하다.

테스트 데이터 생성 도구의 설계 및 구현 

1. 파라미터 및 모델
2. 이벤트의 생성 흐름

성능 테스트

자세히 보기 →

모바일 기반의 소프트웨어 품질 확보 가이드

모바일 디바이스 사용률이 지속적으로 증가하면서 개인과 기업들은 수많은 모바일 애플리케이션을 제공하고 있습니다. 하지만 모바일 애플리케이션의 양이 증가하는 것에 비해 품질 측정과 평가 방법이 많지 않아 이에 대한 대책이 시급한 상황입니다.

모바일 애플리케이션은 휴대와 이동에 원활히 대응해야 하지만 네트워크 연결 지속, 처리 제한, 저장 공간 제한 등과 같은 제한적인 특성도 포함하고 있어 일반적인 소프트웨어와 다소 차별화된 품질 기준과 평가 방법이 필요합니다. 또한, 모바일 애플리케이션은 시간과 장소에 구애 받지 않고 동작하기 때문에 동일한 기능이라고 하더라도 구동 환경이 시시각각 변할 수 있습니다. 하지만, 개발자들은 모든 환경을 테스트할 수 없기 때문에 배포 후 예기치 못한 오류가 발생하기도 합니다.

이번 회에서는 모바일 애플리케이션 개발 환경의 특징과 구동 환경을 고려한 품질 기준을 제시하고 평가 방법에 대해 살펴보기로 합니다. 또한 시나리오 기반으로 사례 연구를 해보기로 합니다.

자세히 보기 →

DevOps 현황과 전략적 선택

데브옵스(DevOps)는 개발(Development)과 운영(Operations)의 합성어로서, SW 개발자와 IT 운영 전문가 사이의 소통과 협업을 강조하는 개발방법론입니다. 데브옵스는 SW 개발과 운영 조직간의 상호 의존과 통합을 의미하며 SW 제품과 서비스를 빠른 시간에 개발하고 배포하기 위한 목적으로 도입됩니다.

10 여 년 전만 해도 대부분의 SW 개발은 장시간이 소요되는 선행 투자 수반의 ‘폭포수 방법론(Waterfall Model)’을 선택했고, 이후 지속적인 통합과 배포로 이어지는 운영이 뒤따랐습니다. 디스켓이나 CD에 포장된 소프트웨어를 거래하던 시대에는 이런 것들이 잘 성공적이었다. 골드 디스크를 만들고 수천에서 수백만장의 사본을 생산했었습니다. 하지만, 버그가 있어도 다음 출시까지 고칠 수는 없었습니다. 이런 환경에서, 소프트웨어 출시는 대단한 이벤트였던 것입니다. 

 그러나, 요즘같은 웹과 모바일 애플리케이션의 시대에서 개발과 배포는 하루가 멀다 하게 수시로 이루어집니다. 이제 버전업과 배포는 그렇게 대단한 일이 아닙니다. 자주 출시할 수 있으며, 새로운 릴리즈에서 문제가 발견되면 빠르게 해결할 수 있습니다. 테스트 릴리즈를 하는 A/B 테스팅 기법을 터득해서 비즈니스 아이디어에 확신을 더하기까지 합니다. 

자세히 보기 →

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

국내 중소 SW기업과 개발 조직의 SW품질 향상과 신뢰성 확보에 목적이 있습니다.

SW개발자, 품질 담당자, 테스트 담당자 등을 대상으로 SW프로세스 개념과 SP인증 기준 이해를 바탕으로 실제 업무에 필요한 SW 프로세스 교육을 진행합니다.

신청하기 →

SW 품질향상을 위한 SW 테스트 관리방식의 변화

가상화(Virtualization), 예방 테스트 축소, 비정형 결함 수정(ad hoc defect fixing), 단편적 개발 (piecemeal deployment)등의 트렌드는 테스트 매니저의 역할을 변화시키고 있습니다. 여기에서는 산업연구와 테스트 컨설팅 작업에서 볼 수 있는 일반적인 개발 경향들을 소개하고 테스트와 QA 관리자를 위한 조언들을 소개합니다.

테스트 관리 트렌드

• 제품통합 개발팀들(Integrated Product Teams) 
• 단편적 개발, “테스트 단계”의 종료를 불러옴 
• 가상화(virtualization) 
• 이러한 경향들을 살펴본다면, 전통적인 테스트 관리를 위해 사용했던 툴들이 불필요해 지거나, 적어도 가치가 감소된 것을 알 수 있음 

QA 관리자가 고려해야 할 사항들

• 제품 책임자가 될 것
• 높은 수준에서 수행하는 사업 관리자가 되어야 함 
• 팀에서 팀으로 이동하는 컨설턴트가 되어야 함 

자세히 보기 →

애자일 개발 프로세스에서 스크럼 마스터(Scrum Master)의 역할

대표적인 애자일 개발 방법론 중에 하나인 스크럼(scrum)은 상호적이고 점진적으로 소프트웨어를 개발하는 방법으로, 반복을 통해 개발주기를 단축하여 팀의 생산성을 높입니다. 반복 개발을 통해 프로젝트를 진행시키는 방식인 스크럼은 일반적인 관리를 수행하는 프로젝트 관리자 역할과는 다른 스크럼 마스터 고유의 역할을 요구합니다.

　

스크럼 마스터는 팀원을 이끌어 가면서, 프로젝트의 문제들을 해결해 나갑니다. 이와 같은 방식으로 스크럼은 고객의 비즈니스 요구사항을 만족시키는 소프트웨어를 개발할 수 있도록 합니다. 여기서는 애자일 개발 프로세스에서 요구되는 스크럼 마스터의 역할을 소개합니다.

스크럼 마스터의 역할

• 스크럼 팀에 의해 확인된 문제들을 해결하기 위해 스크럼 마스터는 섬기는 리더(servant leader)로서 수행함
• 스크럼 마스터는 일일 회의, 계획 회의, 회고작업, 개발 팀원들과 소비자 팀원들 사이의 대화를 더욱 용이하게 함
• 팀은 지속적으로 소프트웨어의 품질과 프로세스 개선을 위해 노력해야 되며, 스크럼 마스터는 팀의 당면 과제를 개선시키기 위해 도움이 되어야 함
• 다른 도급업자들과 함께 개발해야 하는 대규모 팀의 경우, 내부 팀들과 고객들 그리고 외부 팀들을 상호 조율할 수 있는 프로젝트 관리자가 있었음
• 요구목록에서 해야 할 일을 선별하고 자기 자신에 대한 업무량을 관리하는 자주적인 팀의 원칙을 익스트림 프로그래밍(Extreme Programming)과 같은 애자일 방법뿐만 아니라 칸반(Kanban)과 같은 다른 애자일 프로젝트 관리 프레임워크에도 적용해야 함
• 애자일의 모든 ‘플래버스(flavors)’에는 고객과 개발팀의 책임들이 정의되어 있으며, 이런 정의들은 비즈니스 전문가들과 기술 전문가들 사이의 성공적인 소프트웨어 개발을 위한 협업에 도움을 줌

자세히 보기 →

프로그래머가 알아야 할 10가지 빅데이터 툴

프로그래머들이 빅데이터 앱을 구축하거나 데이터들로부터 중요한 정보를 만들어 내기 위해서는 데이터 분석 툴이 그 어느 때보다 중요해지고 있으며, 많은 회사들이 개발자들의 니즈와 기술을 기반으로 설계된 툴들을 구축하는 것이 필요합니다. 따라서 데이터 전문가가 아닌 코딩을 수행하는 프로그래머 관점에서 유용한 10가지 빅데이터 툴(알파벳 순서)을 소개합니다.

Ⅰ. 비트델리(BitDeli)

Ⅱ. 컨티뉴이티(Continuuity)

Ⅲ. 플러리(Flurry)

Ⅳ. 구글 프리딕션 API(Google Prediction API)

Ⅴ. 인포침스(Infochimps)

Ⅵ. 킨 IO(Keen IO)

Ⅶ. 콘테이전트(Kontagent)

Ⅷ. 모르타르 데이터(Mortar Data)

Ⅸ. 플레이스드 분석(Placed Analytics)

Ⅹ. 프리코그(Precog)

자세히 보기 →