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)’에는 고객과 개발팀의 책임들이 정의되어 있으며, 이런 정의들은 비즈니스 전문가들과 기술 전문가들 사이의 성공적인 소프트웨어 개발을 위한 협업에 도움을 줌

자세히 보기 →