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 테스팅 기법을 터득해서 비즈니스 아이디어에 확신을 더하기까지 합니다. 

자세히 보기 →