SW개발 버그, 이를 식별하고 방지하는 방법

아무리 뛰어난 SW개발자라 할지라도 SW코딩에 나타나는 버그를 피할 수는 없음에 따라 이를 먼저 식별하고 최소화하는 방안이 필요합니다. 버그를 방지하기 위해서는 프로젝트 초기 요구사항 분석단계를 명확히 하며 프로젝트 참여인력 간 SW개발목표 및 프로세스를 공유하고 이해하는 것이 중요합니다.

SW 개발에 있어 버그는 피할 수 없는 어려움이며 , 다만 이를 먼저 식별하고 최소화하는 방안 마련이 필요

• SW 개발 프로세스는 ‘ 요구분석 (Requirement), 설계 (Design), 개발 (Development), 테스트 (Testing), 구현 (deployment)’ 의 다섯 단계로 구성되어 있으며 , 각 단계에서 다양한 종류의 버그들이 나타날 수 있습니다.

간단한 SW 개발 프로젝트가 점차 관리하기 어렵도록 복잡하게 만드는 주요 원인은 고객의 잦은 요구사항 변경과 참여 인력의 대폭 증가임

• 일반적으로 프로젝트가 진행됨에 따라 코드라인이 증가할 뿐만 아니라 SW 개발목표가 지속적으로 변경되는 등 점점 복잡해지는 경향을 보입니다.
• 또 다른 요인은 프로젝트 참여인력의 증가로 인한 개발목표달성 측면의 커뮤니케이션 오류 위험이 대폭적으로 높아집니다.

이러한 버그를 방지하기 위해서는 요구사항관리가 매우 중요하며 , 프로젝트 참여인력 간 원활한 의사소통 등이 주요 요소라 할 수 있음

• 프로젝트 수행초기 요구사항관리가 버그를 방지하는 가장 효율적인 방법입니다.
• 유닛 테스트 역시 버그를 방지하는 좋은 방법으로 유닛 테스트는 개발단계에서 만 활동되는 것이 아니라 코드 테스트 및 회귀 버그도 방지할 수 있습니다. 
• 궁극적으로는 버그를 방지하고 문제를 해결하기 위해서 프로젝트 참여 인력 간 소통이 매우 중요합니다.
• 이 외에도 버그픽스를 좀더 활용하여 코드 퀄러티를 높이고 자동화된 테스트를 최대한 활용하여 버그가 재현되는 일이 없도록 하는 것이 필요합니다.

자세히 보기 →

세계는 지금 애자일한 진화 중

2005년 캘리포니아의 서니베일에 위치한 야후 본사에서 개발자 생활을 시작하면서 애자일이라는 생소한 용어를 처음 접하게 되었습니다. 마침 야후가 전문 컨설턴트를 영입하여 전사적으로 스크럼과 애자일을 도입하기 위한 시도를 하고 있을 무렵이었습니다. 

그때까지만 해도 미국 본사와 15개국의 해외 지사에서 공식적으로 사용하던 SW 개발 프로세스는 PDP(Product Development Process)였습니다. 2002년에 전사적으로 도입되었던 이 폭포수모델 기반의 프로세스가 무겁고 느리다는 이유로 서서히 개발팀들의 외면을 받자 야후 경영진이 고심 끝에 애자일이라는 특단의 조치를 선택한 것입니다.

야후는 2004년 12월 스크럼의 창시자인 Jeff Sutherland를 초청해 산업계에 성공적으로 스크럼을 도입한 사례를 공유한 것을 계기로 2005년 2월에 사내에서 스크럼 파일럿 프로젝트를 시작합니다.

4개의 프로젝트팀이 참여를 희망했고 우선순위에 집중, 자발적인 팀 협업 장려, 고객 참여 확대, 점증적인 제품 출시 등가장 기본적인 스크럼 프레임워크부터 적용이 시작되었습니다. 두 달 뒤 파일럿 프로젝트 팀의 반응은 긍정적이었고 이를 시작으로 점점 더 많은 팀이 스크럼과 일부 XP 프랙티스를 포함하는 야후 애자일을 적용하게 되었습니다.

2005년부터 매년 야후 애자일 지원 부서에서 시행하고 있는 사내 만족도 조사를 살펴보면 해마다 평균 80% 이상이 애자일을 계속 사용하겠다는 긍정적인 반응을 보이고 있습니다.

이처럼 해외 선진국의 경우 중소기업은 물론, 마이크로소프트, 구글, IBM, HP, 모토롤라 등 대부분의 대기업이 일찌감치 애자일을 성공적으로 활용하고 있습니다. 포레스터리서치가 2009년 Q3에 1298명의 IT 개발자를 대상으로 실시한 설문조사에 따르면, 35%의 응답자가 애자일 방법론을, 21%의 응답자가 반복점증 방법론을, 13%의 응답자가 폭포수 방법론을 주로 사용하고 있으며, 나머지 30.6%의 응답자가 정형화된 방법론을 사용하지 않는다고 응답했습니다. 단일 방법론으로 보면 스크럼이 11%로 가장 인기가 높았고 전통적인 폭포수 방법론이 8.4%로 그 뒤를 이었다. 가트너 역시 Gartner Predicts 2010에서 2012년까지 SW 개발 프로젝트의 80%가 애자일 개발 방법론을 사용할 것이라는 다소 파격적인 예측을 내놓았습니다.

최근의 동향은 기존에 사용되고 있는 표준 방법론에 애자일 기법을 효과적으로 접목하는 것입니다. 즉, 프로젝트 참여 인원, 응용 분야, 중요성, 혁신성 등의 프로젝트 환경에 따라 기존의 방법론과 애자일방법론은 공생하는 관계에 있으며 프로젝트 상황에 맞게 위험 수준을 분석하고 그 결과에 따라 이 두 가지 방법론을 적절하게 조합하여 이용하는 전략이 요구됩니다.

애자일은 프로젝트 가시성이 높아 현업에서 부담으로 작용할 수도 있습니다. 하지만 이를 사용해본 개발팀의 과반수 이상이 지속적인 사용을 원하는 이유는, 사람이 기본적인 개발 주체인 소프트웨어 프로젝트에 엄격하고 한정된 프로세스를 적용하기보다는 변화의 가능성을 열어두고 환영하는 애자일 철학이 비즈니스 성공과 더불어 개인 능력의 향상에도 큰 도움을 주기 때문입니다.

그렇다면 국내에서 애자일의 도입과 적용이 늦은 이유는 무엇일까.

외국의 애자일 서적을 보면 애자일 기법을 책에서 가르치는 대로 따르지 말라고 합니다. 그만큼 애자일은 가볍고 유연하며 모든 가능성에 대해 열려있습니다. 그런데 많은 국내 개발자들이 책에서 애자일을 배우고 현업에서 부분적으로 적용을 시도하다가 난제를 만나면 커뮤니티에 와서 공유하는 식의 열악한 투쟁을 지속하고 있습니다. 효과적인 애자일 도입을 위한 전략은

첫째, 적절한 시간, 외부 코치, 교육자료, 내부 지원 그룹 등의 전사적인 지원 계획, 

둘째, 프로젝트 도메인, 규모, 특성 등을 반영한 단계별 도입을 포함하는 유연한 도입 모델,

셋째, 전문성을 갖춘 자발적인 팀에 대한 권한 위임,

넷째, 협업을 돕는 각종 도구의 사용이다. 

2000년대 초반에 국내에 상륙한 애자일이 아직까지도 개발자 커뮤니티와 일부 대기업에서의 실험적인 적용 단계 수준에 머무르고 있는 현실을 보면 전사적 차원의 체계적이고 일관된 지원의 중요성을 다시금 확인할 수 있다.

자세히 보기 →

Product Line Engineering 생산라인 공학

소프트웨어 개발은 거대해지고 복잡한 산업으로 변해가고 있습니다. 대부분의 기업은 이럴 때 자신들이 개발하는 소프트웨어를 특화시키려 노력합니다. 주요 내용은 비용, 품질, 출시 등 동시대에 다양한 산업현장에서 성과를 입증한 조직적이고 완성된 상품을 개발하는 생산라인 공학에 대해 살펴볼 것입니다.

1. 생산라인 공학(Product Line Engineering)의 필요성

기업들은 소프트웨어 유형에 초점을 맞추는 동시에 다양한 고객들의 여러 가지 요구 사항과 복잡한 시장 요소들에 의해 보다 더 넓은 범위로 확대되는 다양한 변화를 함께 반영해야 합니다. 결과적으로 기업들은 생산물들의 다양한 범위를「단순히 시간을 넘어서는 것이 아닌 동시다발적으로」 증가시켜 개발하게 되는 것입니다. 이는 특정한 분야에 의존하지 않는 자연적인 현상으로, 임베디드 시스템에서든 ERP 시스템에서든 마찬가지입니다. 이것은 재사용의 문제로 규정지어질 수 있는데, 그렇다면 우리는 기존의 최적화된 생산품을 위해 개발된 소프트웨어가 새로운 환경에서 완전히 재사용될 수 있을지를 생각해봐야 합니다.

2. 생산라인 공학(Product Line Engineering)이란?

생산라인 공학의 주 아이디어는 시스템적으로 공통적인 생산라인 인프라를 개발하고, 그로부터 반 자동적인 시스템 방식에 의한 다양성을 파생시키는 것입니다. 여기에는 생산라인의 전체를 파악하는 전략적 접근이 요구됩니다. 조직에 이와 같은 방식으로 소프트웨어 개발에 새로운 방향을 제시하기는 쉽지 않겠지만, 결국 이런 경험들은 기업에게 중요한 자산이 될 것입니다.

개별적인 생산을 하는 공학에서 완성된 생산라인 개발로 이루어지는 초점의 변화는 소프트웨어 공학의 모든 레벨에서 중요한 결과를 가져옵니다. 이는 조직과 개발 프로세스, 도구의 종류에 영향을 끼칠 뿐만 아니라 아키텍처, 코딩, 테스팅들이 어떻게 실행되는지를 알 수 있으며, 이러한 영향력은 다음과 같은 원리로 요약될 수 있습니다.

① Minimal duplication

② Strategic Development

③ Variability Management

④ Architecture-centric approach

⑤ Two Life-Cycles

3. 생산라인 공학(Product Line Engineering)의 이점
이와 같은 접근방식은 특히 고객의 입장에서 볼 때 최적의 상황은 아닌 것처럼 보일 수도 있겠지만, 실제로는 소프트웨어 개발 조직과 고객 모두에게 매우 경제적입니다. 생산라인 공학은 넓은 범위에서의 재사용을 유도하고 있어 성공적인 생산라인 조직은 80% 혹은 그 이상의 재 사용률 보이고 있습니다. 이것은 또한 노력과 비용을 절감할 수 있는 요소가 된다. 일부 생산 라인 조직은 평균적으로 50% 이상의 비용절감 효과를 보았고, 이러한 효과는 고객에게도 상당히 환영받고 있다고 밝혔습니다. 이러한 업무의 감소는 또한 시장으로 출시되는 기간이 감소하는 것을 의미하기 때문에 재사용의 높은 수준은 소프트웨어 품질을 증진시키는 직접적인 중요 요소로 나타납니다. 구성요소들은 많은 상품에 공유되기 때문에, 만약 고객에 의해 결함이 발견되면 그들은 공유된 구성요소를 제거함으로써 모든 고객을 위한 품질 향상을 이끌어 냅니다. 결국, 다양한 요소들이 공유되기 때문에 유지보수 활동은 오직 한 번만 실행되는 것입니다. 이러한 이로운 점은 Simens, Nokia, Cummins, Thales 등 많은 대기업뿐만 아니라 크고 작은 적용 도메인 범위를 가지고 여러 설정을 통해 적용되는 중소기업들에서도 성공적으로 이루어져 오고 있습니다.

자세히 보기 →