2015년 7월 31일 금요일

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 등 많은 대기업뿐만 아니라 크고 작은 적용 도메인 범위를 가지고 여러 설정을 통해 적용되는 중소기업들에서도 성공적으로 이루어져 오고 있습니다.

2015년 7월 30일 목요일

소프트웨어 아키텍쳐 트렌드

소프트웨어 아키텍쳐는 고수준(high-level)의 소프트웨어 시스템과, 그들 사이의 관계, 그리고 그로인한 특성에 깊이 관련되어 있습니다. 이러한 고수준의 구조는 계산능력, 커뮤니케이션, 그리고 구축을 반영한다. 물론 여기에는 긴급 동작, 성능, 신뢰성, 보안성, 유지보수성과 같은 일반적인 특성들도 함께 포함됩니다.

훌륭하게 디자인된 아키텍쳐는 시스템 설계자가 요구사항의 만족성과 절조있는 공학적 균형(tradeoffs)을 제시할 수 있도록 해줍니다. 그러한 아키텍쳐는 각 컴포넌트들의 동작 분배에 대한 확실한 원리, 개념적 통일성에 대한 원칙 수립, 그리고 시스템의 수명에 걸친 반복작업의 상당한 감소를 제공할 수 있습니다. 또한 아키텍쳐적인 설계 특징과 패턴들을 재사용할 수 있도록 해주고, 생산 라인에 접근함으로써 개발 비용을 감소시키며, 그 시스템의 장래의 유지보수자들을 위한 가이드를 제공합니다. 

지난 10년간 소프트웨어 아키텍쳐를 표현하고 사용하는 방법과 아키텍쳐적 설계의 분류에 있어서 놀라운 발전이 있어왔습니다. 결과적으로 우리는 다음과 같은 뛰어난 테크닉들을 얻어낼 수 있었습니다.

(가) 아키텍쳐를 정확하고 분명하게 문서화하는 테크닉,
(나) 소프트웨어 아키텍쳐가 얼마나 잘 시스템의 주 요구사항을 드러내고 있는 지 결정할 수 있도록 평가하는 테크닉
(다) 아키텍쳐적 패턴과 스타일의 재사용에 대한 테크닉 
(라) 생산 라인과 프레임워크를 생성하는 테크닉
(마) 소프트웨어 엔지니어들이 뛰어난 아키텍트가 되도록 가르치는 테크닉 
이 테크닉들의 대부분들은 성공적으로 그들의 요구사항을 만족시키는 효율적인 시스템을 생성하는데 성공한 조직들의 실제 모습에서 공통적으로 발견됩니다. 그러한 조직들은 "아키텍쳐적으로 성숙합니다".

미래 경쟁력 , 이제부터 SW품질이다

SW품질은 선택이 아닌 필수

IT 융합시대를 살고 있는 지금, 산업경쟁력의 핵심은 하드웨어에서 소프트웨어로 이동했고, 소프트웨어의 융복합화로 산업 환경에 급속한 변화가 진행되고 있습니다. 소프트웨어의 활용분야가 산업 여러분야로 다양해짐에 따라 소프트웨어 품질의 중요성이 더욱 대두되고 있는 현실입니다.

소프트웨어 품질은 발주자가 제시한 소프트웨어의 기능에 대한 요구사항 뿐만 아니라 소프트웨어 운영상황에 대한 내재된 요구사항을 충족할 수 있는 소프트웨어 특성의 총체를 말합니다. 산업에서 소프트웨어의 역할이 다양해짐에 따라, 소프트웨어 품질에 대한 의미도 협의의 의미에서 벗어나 광의의 의미로 해석하고 관리할 수 있는 능력이 필요하게 되었습니다.

소프트웨어 품질의 의미는 고객이 요구하는 성능의 소프트웨어를 공급하는 능력정도인 성능 및 적합 차원의 품질인 협의의 의미로 우선적으로 이해됩니다. 소프트웨어가 주어진 기능을 만족하며 결함없이 운영되는 경우 일차적으로 소프트웨어 품질이 달성되었다고 생각할 수 있습니다. 그러나 최근의 산업 환경은 자동차, 항공기, 의료장비, 통신기기 등 사람이 이용하는 많은 기기가 소프트웨어 활용 없이는 작동하지 않기에, 소프트웨어 시스템은 더 높은 수준의 확실성, 안전성, 보안성, 신뢰성 등을 보장해야 합니다.

소프트웨어는 모든 산업분야에서 비즈니스 수행에 없어서는 안되며 많은 도움을 줄 수 있는 중요한 역할을 수행함으로, 소프트웨어 품질은 그 중요성 및 파급 효과가 매우 중대해졌습니다. 이러한 산업의 변화는 소프트웨어 품질을 소프트웨어의 성능을 신뢰할 수 있고 고객지향 만족 서비스를 의미하는 신뢰 및 고객만족 차원의 광의의 의미로 확대하도록 했습니다.

특정 제품에 소프트웨어의 활용을 통해 고객지향 만족을 위한 새로운 가치와 차별화된 비즈니스 기회가 창출되고, 제품의 완성도 및 신뢰도가 높아짐으로 기업은 소프트웨어 품질 이상의 또 다른 비즈니스 명성을 얻을 수 있게 되는 상황입니다. 최근의 도요타 자동차나 스마트폰 앱스토어가 이러한 상황을 대변합니다.

이제 소프트웨어 품질은 비즈니스의 성공을 위한 선택이 아닌 필수가 되었습니다. 융합 소프트웨어 환경 하에서 비즈니스의 성공 및 부가가치 극대화를 위해서는 소프트웨어의 품질경쟁력이 매우 중요합니다. 소프트웨어를 통한 무한의 가치 창출을 위해 품질 개선을 위한 노력 즉 품질 경영이 필요합니다.

무한가치 SW품질

신뢰할 수 있는 소프트웨어 시스템을 위해서는 소프트웨어 개발과정에서의 결함을 발견하고 제거하는 것 이상으로, 시스템 운영과정 중 발생할 수 있는 부정확하거나 바람직하지 않은 동작을 감지하는 것을 필요로 합니다. 소프트웨어 시스템이 의도한 대로 사용자의 기대를 만족시키며 사용하기에 충분하도록 하기 위해, 기업들은 소프트웨어 개발과정에서 다양한 소프트웨어공학 기법을 적용하여 궁극적으로 소프트웨어 품질을 강화하기 위한 노력을 해왔습니다.

Edsger Dijkstra(1972)가 “시험은 오류의 존재만을 보이는 것이지 오류가 존재하지 않는다는 것을 보일 수는 없다.“라고 한 것처럼 결함이 전혀 없는 시스템은 있을 수 없기에, 결함 제거를 통한 소프트웨어 신뢰 향상을 위해 다양한 측면에서 소프트웨어 공학적 노력이 적극적으로 필요합니다. 소프트웨어 시스템의 품질은 제조업에서의 품질과는 다른 것으로, 고객이 원하는 기능의 만족 뿐만아니라 명세화 되지 않은 비기능적 요소나 모호한 품질특성까지도 만족시켜야만 소프트웨어의 품질이라 할 수 있습니다.

도요타자동차 대량 리콜사태 이후 기업인식 조사 결과에 따르면, 20.6% 기업이 ‘경영방침에 변화가 있었다‘고 답했고, 절반가량인 52.4%는 ’특별한 변화는 없었지만 품질과 안전문제에 대한 인식이 강화되었다‘고 밝혔습니다. 구체적인 경영방침의 변화로는 완성품의 품질?안전관리 활동 강화(52.6%)가 절반 이상을 차지했습니다. 또한 ’이러한 사태가 우리 기업에게도 일어날 수 있다고 보느냐‘라는 질문에 64.4% 기업은 충분히 일어날 수 있다고 대답했습니다. 

소프트웨어(SW)개발은 공학적 접근방법이 필요하다

1. 우리가 사는 세상은 SW공학을 필요로 한다.

지금 우리는 디지털 시대에 살고 있습니다. Smartphone, Facebook, Twitter, Cyworld 등 효과적인 커뮤니케이션 전달수단을 통해 사회 전반적으로 새로운 휴먼 네트워크 문화를 구축하고 있습니다. 이와 같은 디지털 시대 중심에 바로 소프트웨어(이하 SW로 명명함)가 자리잡고 있습니다. SW가 없는 우리의 삶은 상상 할 수 없을 정도로 불편할 것입니다. 이제 SW는 글로벌 경쟁력을 위하여 신경써야 할 핵심자산으로 자동차, 조선, 전자 분야 등 국가 전략산업의 가치혁신을 견인하고 있습니다.

이와 같이 우리의 삶에 필수불가결한 요소로 자리잡은 SW를 개발하는데 있어서 체계적인 절차와 방법이 필요한 것은 당연한 것입니다. 초등학교의 수학 학습과 SW공학을 비교하여 설명해보자. 요즘 어린이들은 초등학교 1학년이면 구구단 정도는 이미 알고 있다고 합니다. 이것은 아이들이 살아가면서 부딪힐 일상에서의 생활 수학에 대한 중요성과 필요성에 대한 교육결과입니다. 이때 가장 중요하게 배우는 것이 수의 개념입니다. 자연법칙인 것입니다. 이를 통하여 우리는 미지의 세계와 보이지 않는 것들에 대한 계산과 예상을 해낼 수 있으며, 더 높은 수준의 과학적용과 경쟁력의 밑거름이 됩니다.

우리의 SW개발 상황들은 어떠한가? 이미 다양한 언어들, 플랫폼, 통신기술, 기기제어기술 등 매우 복잡하고 고난이도의 개발기술들이 존재하며, 개별적인 기술들을 구현하고, 발전시키려는 수많은 노력들을 하고 있습니다. 정보의 규모, 학습할 대상의 규모 면에서, 이미 외워서 될 일이 아닌 것입니다. 체계적인 절차와 방법이 정립된 공학적 개념이 필요한 것입니다. 즉, 초등학교 학생들에게 수의 개념이 필요하듯이, 우리 생활에 깊게 파고든 SW를 위해서는 발주처, SW관련 기업 등 이해관계자들에게 SW공학적 개념이 필요한 것입니다.

지난 1990년대 초반 IT열풍과 함께 SW인력에 대한 양적인 성과를 이루어 냈습니다. 이후 SW관련 취업관문에서 ‘SW개발’은 간단한 ‘XX언어 2주 완성’이라는 책 한권을 보거나, ‘속성 XX개발자 1개월 과정’을 이수하면 할 수 있다고 생각하는 많은 사람들이 있습니다. 이것은 마치 주어진 몇 개의 덧셈 문제를 외우려 노력하는 것과 같습니다. 이렇게 출발한 SW개발은 결국 수많은 시행착오와 반복되는 작업, 결과적으로 통제가 불가능한 SW개발 상태, 즉 SW위기를 초래하기가 쉽습니다.

또한 우리는 SW개발 과정 속에서 단순 반복적인 일들과 복잡하고 방대한 작업들의 비효율적인 대처 방법에 대하여 의문을 갖게 됩니다. 체계적으로 접근해서 보다 빠르고, 신뢰성 있는 개발 결과물을 도출하고 싶은데, 현실은 항상 납기 시간에 쫓기면서 비효율적으로 작업을 하고 있는 것입니다. 이와 같은 것을 극복하기 위하여 SW공학이 존재하며, SW공학은 SW개발 프로젝트의 품질과 생산성을 높이기 위한 뼈대가 되는 것입니다.

유비쿼터스 시대에 살고 있는 우리는 생활 곳곳에서 SW를 이용하고 있으며, 우리 생활의 일부분으로 자리잡은 SW의 품질과 생산성을 높이기 위해서 SW공학 적용은 선택이 아니라 필수인 것입니다. 즉, 우리가 사는 세상은 SW공학을 필요로 하는 것입니다.

2. 이제 SW공학의 세계로…

SW공학이란 용어는 1960년 후반에 ‘SW 위기’라는 것을 토론하기 위해서 열린 국제 회의에서 제안되었습니다. 3세대 컴퓨터 하드웨어의 소개로 이전의 시스템 개발 방법을 큰 SW시스템에 적용하는 것이 불충분하게 되면서 SW 위기가 대두되었던 것입니다. SW공학은 컴퓨터 시스템들의 SW를 개발하는데 필요한 방법, 도구에 관심을 두고 있다1). 좀 더 SW공학을 이해하기 쉽게 방송 제작 프로세스와 SW개발 프로세스를 비교하여 설명하면 다음과 같습니다.

모 방송사의 인기 버라이어티 프로그램의 제작과정을 한번 살펴보자. 제작진과 출연진이 구상한 프로그램의 각 코너들은 자체적으로 수많은 검토와 검증, 리허설을 거쳐 무대에 오르게 됩니다. 무대에 오르게 된다고 해도 반드시 방송에 나가는 것은 아닙니다. 현장의 반응을 살펴 바로 편집되는 경우도 있으며, 방송 후에는 시청자의 반응에 따라 코너가 폐지되기도 하고 반응이 좋을 경우 새롭게 다듬어져서 장수코너로 자리 잡기도 합니다. 장기간 제작진과 출연진이 끊임없이 바뀌어 왔지만 인기프로그램으로 존속할 수 있는 이유는 바로 이러한 체계를 엄격하게 유지해 왔기 때문이라고 볼 수 있습니다.

3. 우리의 미래는 SW공학이다

앞에서 SW 중요성을 반영하여 SW공학의 실체를 설명하고자 하였으며, SW공학의 필요성, 우리나라와 선진외국과의 SW공학 수준 차이, SWEBOK의 소개, SW공학 기술 적용 성공사례를 통해 SW공학에 대하여 체계적으로 접근하고자 하였습니다.

그 동안의 수많은 SW 개발 프로젝트를 통해 성공사례와 실패사례가 존재합니다. 우리는 지속적으로 SW공학을 적용하지 못해 실패한 SW개발 프로젝트들을 쉽게 찾아 볼 수 있습니다. 이들 사례를 보면, 비용, 기간 등 현실적인 문제 때문에 SW공학 적용이 결코 쉬운 것만은 아니다. 그러나, 장기적인 관점에서 SW개발비용 절감, 적기개발, 품질개선을 위해서 SW개발 프로젝트에서 SW공학을 적용해야 하는 것도 주지의 사실입니다. 이에 발주자 측면, 기업 측면, 인프라 측면에서 SW개발 시 효과적인 공학 적용 방향에 대하여 정리하면 다음과 같습니다.

첫째, SW개발기업 뿐만 아니라 발주자도 SW공학 사상을 인지하고 성공적인 SW개발 프로젝트가 되기 위해서 SW요구사항 제시부터 SW인수까지 양질의 SW가 생산되도록 노력해야 합니다.
둘째, SW개발 및 유지보수 관련 기업은 지속적인 SW공학 적용에 대한 의지가 반드시 필요하다. 또한, 선행 SW프로젝트의 시행착오 결과를 평가하고 정리한 후 후행 SW프로젝트에서 효율적으로 대처해야 할 것입니다.
셋째, 인프라 측면에서 효율적인 방법론, 자동화된 도구를 사용해야 한다. 복잡해지는 SW아키텍처 특성과 프로젝트 환경을 고려한 SW 개발방법론 및 프로젝트 관리방법론을 적용해야 하며, 자동화된 도구 활용을 통해 SW 컴포넌트의 재사용성을 증대시키고 SW개발 생산성을 향상시켜야 합니다.

자세히 보기 →

2015년 7월 29일 수요일

사용자 관점의 솔루션 개발 방법과 사례

소프트웨어 개발방법론을 사용하는 대부분의 프로젝트는 사용자의 요구사항을 받아 분석하고 설계한 후, 개발하는 프로세스로 진행된다. 개발방법론은 폭포수 모델에서 OO(Object Oriented) 개발방법론, CBD(Component Based Development) 개발방법론 등으로 계속 발전되었지만, 큰 형태는 요구사항 분석(Requirement Analysis), 분석(Analysis), 설계(Design), 개발(Development), 구현(Release)으로 구성되어 있는 폭포수 모델을 바탕으로 하고 있t습니다.
 이러한 개발방법론들은 어떠한 목적으로 만들어졌던 간에 납품(Delivery)형 소프트웨어를 위한 것으로 볼 수 있습니다. 그러다 보니 요구사항이 원하는 형태로 개발되는가 보다는 계약관계가 잘 이행되고 있는지에 더 초점이 맞춰져 있는 것이 사실입니다. 이러한 이유로 기존의 개발방법론은 대기업 위주의 SI(System Integration)형 프로젝트의 변화에 따라 발전했다고 봐야 할 것입다. 이와는 다르게, 중소규모의 솔루션(Solution)형 프로젝트는 개발자 위주로 개발되다 보니 개발방법론의 필요성 자체를 못 느낀 경우가 많았습니다. 하지만 소프트웨어를 더 체계적으로 개발해야 한다는 필요성은 예나 지금이나 소프트웨어를 개발하는 사람이라면 누구나 공감하는 얘기일 것입니다.

<사용자와 개발자 간의 비전 공유(기능적 측면)>

자세히 보기 →

‘얼랭(Erlang)’을 이용한 서버 프로그램 개발

MMORPG 엔진을 C, JAVA, Ruby, Python, 얼랭(Erlang)으로 개발하여 성능 테스트를 해보면,  얼랭이 상대적으로 퍼포먼스가 좋고, 코드의 양도 JAVA나 C언어에 비해서 3분의 1 수준으로 줄어들어 프로그래밍이 간단하다는 것을 확인할 수 있습니다.

특히, 다른 언어로 짜면 실제 로직과 코드가 달라져서 복잡해지는 부분이 있지만 얼랭은 그대로 표현할 수 있다는 점이 가장 큰 매력이라고 합니다. 아직은 우리나라에 생소한 프로그램 개발 언어인 ‘얼랭(Erlang)’을 2008년부터 사용해온 전문가 의견을 정리했습니다. 

자료 처리를 수학적 함수의 계산으로 취급하는 얼랭과 같은  함수형 프로그램 개발은(Functional Programming) 이해가 용이하기 때문에 개발 속도도 빠르다고 할 수 있습니다. 반면, 기존의 다른 프로그래밍 방식(즉,  상태와 가변 데이터에 중심을 두고 명령형으로 처리하는 개발)에 익숙하다면 얼랭을 사용할 때 어려움을 느낄 수 있습니다. 따라서,  편리하고 빠르며 효율 높은 얼랭을 이용하여 모바일 서버 프로그래밍을 자유자재로 하기 위해서는 부단한 연습만이 정법이 될 것입니다.

얼랭 Cowboy 처리 흐름도(자료: Cowboy 홈페이지)

웹 개발을 위한 효율적 테스트

  • 테스트가 중요한 이유
  • 테스트 구간에서 자주 발생하는 문제점들
  • 효율적 개발을 위한 테스트 팁
  • 발생 가능한 예외 상황에 대한 테스트 및 대응
  • 단위별 부하 테스트
  • 주기적인 시스템 모니터링
  • 다양한 환경에서의 테스트 수행
  • 화면 중심의 의사소통


 자세히 보기 →

2015년 7월 28일 화요일

SW공학 웹진

매주 공학 트랜드, 인사이이드 이슈, 동향 브리핑 등 최근 소프트웨어에 관한 정보를 확인하실 수 있는 웹진이 발행되고 있습니다.

Cloud Computing 기반의 Smart Working 시스템

스마트워킹 (Smart Working) 에 관한 관심이 매우 높아지고 있습니다 . 특히 클라우드 컴퓨팅과 다양한 스마트 디바이스를 이용한 SaaS(Software as a Service) 에 대한 활용을 통하여 기업 및 조직의 경쟁력과 조직원 및 개인의 업무 능력을 향상시키기 위한 노력들이 전 세계적으로 펼쳐지고 있습니다.

전 세계적으로 공장 및 현지 사무소 등을 운영하고 있는 회사에서는 전 세계적으로 협업을 추진할 수 있는 스마트워킹 시스템이 이제 필수적입니다 . 특히 , 다양한 스마트 디바이스와 연계하여 언제 어디서나 다양한 방법으로 커뮤니케이션을 촉진하고 더 나아가 스마트워킹을 위한 다양한 시스템이 필요한 시점입니다 .

하지만 아직 국내외적으로 이러한 시스템을 개발하기 위한 효율적인 소프트웨어 아키텍처가 부재한 것이 사실입니다 . 기술적으로는 클라우드 컴퓨팅과 관련된 다양한 기술을 이용하여 효율적인 관리 및 비용의 감소를 추구할 수 있습니다.

이에 따라 위와 같이 스마트워킹을 위한 솔루션은 클라우드 컴퓨팅을 중심으로 협업 솔루션과 스마트디바이스를 지원할 수 있어야 합니다 . 만약 이러한 솔루션을 제고한다면 기업 및 조직 등에 많은 발전을 견인할 수 있을 것으로 판단합니다.

자세히 보기 →

소프트웨어 아키텍처 분석방법

소프트웨어 아키텍처 분석 목적 및 배경

1. 소프트웨어 아키텍처 분석 목적

시스템의 아키텍처에 대한 가장 중요한 사실 중 하나는 , 비록 소프트웨어가 아직 개발이 되어 있지 않는 상황에서도 소프트웨어 아키텍처는 시스템의 중요한 요소에 대해서 표현하고 있다는 것입니다 . 소프트웨어 아키텍처를 바탕으로 이해관계자 및 아키텍트는 중요한 의사결정을 할 수 있게 될 뿐만 아니라 예상되는 사이드 이펙트 (side effect), 위험요소 및 시스템 구성에 대한 예측을 할 수 있게 됩니다 . 만약 소프트웨어 아키텍처가 없다면 이해관계자나 아키텍트 , 혹은 관리자들이 쉽게 파악할 수 없는 소프트웨어에 대해서 특별한 해결책 없이 의사결정을 해야만 하고 그로 인한 위험이나 불확실성은 시스템의 규모가 크고 복잡해질수록 기하급수적으로 커지게 됩니다 .

아키텍트가 소프트웨어 아키텍처를 파악할 수 있게 되면 , 정교한 의사결정이 가능하게 되고 , 우선순위화도 쉽게 결정할 수 있게 됩니다 . 또한 , 다양한 아키텍처의 팁 및 패턴의 적용이 가능 하여 , 소프트웨어 시스템이 더욱 견고해지고 개발과 유지보수가 용이해 지게 된다 . 이러한 이유로 소프트웨어 아키텍처는 “ 분석 가능한 ” 상태이어야 합니다 . 다시 말해 , 소프트웨어 아키텍처가 분석 가능하면 이해관계자 및 아키텍트는 중요한 의사결정을 내릴 수 있을 뿐만 아니라 , 성공하는 소프트웨어를 위한 다양한 전략 및 패턴의 적용이 가능하고 , 개발자와 테스터들도 분석된 소프트웨어 아키텍처를 기반으로 개발 및 검증이 가능하여 보다 견고한 소프트웨어 시스템을 개발 및 배포할 수 있게 됩니다 . 또한 , 소프트웨어의 지속성 및 업데이트를 고려하여 다양한 소프트웨어 아키텍처의 발전 및 유지 보수가 가능하게 됩니다 . 이러한 소프트웨어 아키텍처의 분석은 심지어 아직 개발이 완료되지 않은 소프트웨어에 대해서도 충분히 적용이 가능합니다 .

2. 소프트웨어 아키텍처 분석 시점

일반적으로 가능한 이른 시점에 소프트웨어 아키텍처를 분석하면 할수록 비용절감의 효과를 크게 노릴 수 있습니다 . 즉 , 문제를 빨리 발견할수록 고치기가 쉬워지며 요구사항이나 스펙 , 특징 , 기능 등 필요한 부분에 쉽게 적용시킬 수 있습니다 . 소프트웨어 품질은 프로젝트의 마지막 부분에 점검하는 것이 아니고 , 가능한 시작점으로부터 시작되고 그 품질 검증이 프로젝트의 마지막까지 , 테스트 마지막 시점까지 연결되고 상속되어야 합니다 .

소프트웨어 아키텍처를 분석하는 시기에 대해서는 특별히 정해진 단계나 프로세스는 없으나 , 일반적으로 소프트웨어 아키텍처를 분석하기 위한 최적의 시점은 디자인 단계로 이야기됩니다 . 그러나 소프트웨어 아키텍처 분석은 많은 단계에서 수행되면 다양한 문제점 분석 및 소프트웨어 아키텍처의 개선을 가져올 수 있기 때문에 , 전체 소프트웨어 프로젝트 라이프 사이클 단계에서 몇 개의 지점을 선택하는 것이 좋습니다 . 만약 소프트웨어 아키텍처가 아직 정해져 있지 않고 많은 의견이 오가는 단계이면 , 여러 가지 의사 결정을 위해 소프트웨어 아키텍처 분석을 실시할 수 있고 , 이미 소프트웨어 아키텍처가 정해지고 개발을 진행하는 단계라면 , 개발이 소프트웨어 아키텍처를 잘 참조하여 개발하고 있는지 혹은 개발에 문제가 있거나 다시 고려해야 할 아키텍처 요소가 없는지 , 아니면 소프트웨어 아키텍처를 재설계할 필요가 있는지를 파악하기 위해서 분석을 실시 할 수 있습니다 . 이미 개발되고 완료된 소프트웨어 프로젝트나 레거시 코드라면 소프트웨어 아키텍처를 분석을 통해서 기존 아키텍처를 쉽게 파악하면서 , 개선이나 유지보수가 필요한 점을 찾을 수도 있고 , 재활용한 컴포넌트나 구조에 대해서 자산화 (asset) 을 할 수 있습니다 . 그리고 다른 시스템이나 다른 구조로 적용 (porting) 을 위한 레거시 시스템의 분석 기준으로도 삼을 수 있습니다 .

결국 , 소프트웨어 아키텍처 분석은 소프트웨어 시스템이 품질 속성이나 시스템의 요구사항을 어떻게 잘 만족시키고 있냐를 다수의 사람들이 쉽게 이해하고 파악할 수 있는 최고의 발굴 행동 이라고 할 수 있습니다 .
더군다나 , 만약에 매우 크고 긴 개발기간을 가진 소프트웨어 시스템이라면 , 개발팀이 소프트웨어 아키텍처 분석을 통해서 전체적인 큰 그림과 디자인을 파악하고 , 후보 아키텍처와 트레이드 오프에 대해서 상호 토론을 통해서 발전시켜 나가는 것이 매우 중요합니다 . 이러한 것을 통해서 개발팀은 중요한 품질 ( 속성 ) 에 대한 팀의 의견을 통일 시키고 지속성장 가능한 소프트웨어 아키텍처를 유지 , 발전 시켜나갈 수 있게 됩니다 .

2015년 7월 25일 토요일

관련지침개발 - 아키텍쳐 설계연구

아키텍처 설계연구는 수준이 낮은 중소SW기업이나 초급개발자 혹은 초급 설계자를 위해 SW아키텍처의 기본 개념을 전파하여 SW설계의 인식을 제고하기 위한 연구입니다.

급속한 성장을 거듭해온 SW개발 분야 중 특히 아키텍처 설계는 인식이 미비하고, 기업의 비밀에 속하는 대상으로 공개하거나 기술을 공유하는데 인색한 것이 현재의 상황입니다.
이에 SW아키텍처의 기본 개념을 전파하여 SW설계의 인식을 제고하고, 실용적인 아키텍처 설계 절차를 연구하고 이를 실제 적용하기의 위한 적용 가이드라인을 연구하여 SW품질 및 SW공학 역량 강화를 지원하고자 합니다.

SW아키텍처 수준이 낮은 중소SW기업이나 초급개발자 혹은 초급 설계자를 대상으로 SW아키텍처 기본 개념 및 일반적인 설계절차를 제공함으로서 SW아키텍처 설계에 대한 기반구축 및 개선사례를 확보하여 공유합니다.



SW공학기술 현장적용 지원 사업 예산지원

SW 공학기술 현장적용 지원사업은 SW 품질 및 생산성제고를 위해 기업에게 실질적으로 필요한 SW 공학기술영역 ( 요구사항 , 분석 / 설계 , 구축 , 테스트 , 유지보수 , 형상관리 , SW 공학관리 , 도구 및 기법 , SW 안전성 등 ) 에 대한 맞춤형 컨설팅을 지원해주는 사업으로 예산범위 내에서 최대 2 억원을 (SW 안전성 분야의 경우 ) 지원해 주고 있습니다 .

사업 추진방식은 사업수행단계(문제점분석 및 목표설정 -> 구축 -> 교육 -> 도구도입 및 활용 -> 시범사업 -> 성과분석)에 따라 SW개발/구현/유지에 필요한 표준 프로세스 정립과 SW공학도구 통한 자동화 구현을 목적으로 하고 있습니다.


SW공학센터, 학교로 찾아가는 직업체험활동 실시

SW 공학센터는 지난 7 월 16 일 홍익대부속여자중학교 1 학년 학생 중 SW 진로에 관심이 많은 18 명을 대상으로 ' 학교로 찾아가는 직업체험활동 ( 전문직업인과의 만남 )' 을 진행했습니다 .

이는 여름 방학 직전에 학생들이 평소 많은 관심을 가지는 SW 분야의 진로를 탐색하는데 도움을 주고자 진행되었으며 , 윤지석 수석과 배현석 책임이 참여하였습니다 .


2015년 7월 24일 금요일

SW발주기술지원 신청

예산수립/심의단계에서 요구사항 도출과 사업규모 및 예산수립, SW영향평가를 추진하고 RFP작성 지원, 과업변경 등 발주자에게 필요한 전문발주기술을 지원합니다.

● SW발주기술지원 대상
- 공공SW사업중 SW개발이 포함된 사업으로 SW개발사업을 기준으로 2억이상, 20억 미만의 별도의 지원체계를 활용하기 어려운 사업이 우선 대상사업.

※ SW발주기술지원 사전 유선상담

● SW발주기술지원 신청 및 절차



SW공학교육

SW Quality Insight 컨퍼런스 및 개발자 세미나
SW Quality Insight 컨퍼런스 및 개발자 세미나는 최근 이슈화 되고 있는 SW공학 품질에 대하여 관련 산ㆍ학ㆍ연 유관기관 종사자들의 경험과 지식을 상호 공유할 수 있는 장을 마련하고 있습니다.

SW Quality Insight Conference
최신 SW공학기술, 공학기술 현장적용 방안과 적용 우수사례를 국내 SW기업과 SW개발자에게 전파하기 위해 SW품질 컨퍼런스를 개최하고 있습니다.(2회)

SW공학 Technical 세미나
SW개발 관련 최신 기술동향 파악, 개발과정 및 프로세스관리ㆍ지원영역에서의 경험공유ㆍ전파로 SW개발자와 관리자의 역량 강화를 위한 SW공학기술세미나를 개최하고 있습니다. (매월 1회)


※ 분석설계기법, 소스코드 품질향상, 효율적 테스팅 방안 및 프로세스개선 방안 등 SW개발 프로젝트 세부요소기술 및 조직관점의 이슈와 해결 방안을 제시합니다.

컨퍼런스 안내보기 →

세미나 안내보기 →


정량적 SW공학 데이터관리

정량적 SW공학데이터 관리는 국내 기업들의 SW개발 프로젝트 능력수준과 성과(품질, 비용, 납기)등에 대해 정량적인 분석을 통해 국내 SW 기업들의 SW공학수준 현황을 진단하고, 이를 기반으로 향후 개선정책을 마련하기 위한 사업입니다.

본 사업을 기반으로 국내SW공학수준과 생산성 분석 등이 포함된 SW공학백서가 발간되고 있으며, 기업의 경영자, 프로젝트 관리자(PM), SW개발자, 학계 및 컨설턴트들에게 다음과 같은 정보를 제공하게 됩니다.



2015년 7월 23일 목요일

SW형상관리 서비스

SW 형상관리 서비스는 국내 중소 SW기업에 대한 SW 형상관리 프로세스 적용을 지원하는 기업 밀착형 컨설팅 지원 서비스입니다.

SW 형상관리 서비스는 SW 형상관리 개념 전파 및 기본 교육을 통한 SW 형상관리에 대한 인식을 제고하고, SW 형상관리 시스템의 활용 및 컨설팅을 통한 SW 품질 및 SW 공학 역량 강화를 지원합니다.

SW 형상관리 현황 파악
신청 기업의 SW 형상관리 수준에 관련하여 인터뷰를 진행하여 서비스 시청 기업의 SW 형상관리 현황을 파악.

SW 형상관리 기본교육
신청기업에 대한 SW 형상관리 개념을 정립하고, 형상관리 프로세스 적용의 필요성에 대한 인식을 제고.

SW 형상관리 시스템 활용
실제적인 SW 형상관리 시스템의 활용을 통한 기업의 형상관리 프로세스 정착.



[SW아키텍처 참조모델] 의료정보 시스템 참조설계모델 2.0

의료 정보시스템의 이해

참조 모델 아키텍처의 정의를 위해 의료 정보 시스템의 중요성, 표준 프레임워크의 필요성, 경제적인 수익 창출 방향성에 대해 고민하고 그 현황을 분석하였습니다.

1)의료정보 시스템의 중요성

  • 의학분야는 접근성의 문제, 자원의 적절하지 못한 분배, 의료사고의 문제, 표준화되지 않은 진료 패턴, 의료비용 증가 등의 문제를 직면하고 있음.
  • Institute of Medicine(IOM)의 의료비용과 품질, 정보과학기술에 대한 보고서에 따르면 건강관리 개혁의 핵심적인 부분은 컴퓨터를 기반으로 한 환자 기록이라고 함.
  • 환자의 의무기록과 처방기록, 검사기록을 전산화하고 이를 통해 의료과오를 줄이고 건강 관리를 향상시킴과 동시에 의료의 품질을 향상할 수 있음.

2) Healthcare SW Framework의 필요성

  • 현재의 의료정보솔루션은 사용자 측면에서 본다면 최신 기술에 대한 무분별한 추종이나 비효율적인 정보시스템 구축, 다양한 의료기 회사와 서비스 회사들의 표준화되지 않은 기술 경쟁으로 비효율 고비용 양상을 보이고 있음.
  • Healthcare SW Framework(이하 HSF)는 표준화된 프레임워크 형태로 의료정보솔루션을 개발함으로써 높은 확장성과 재사용성을 확보하여 구축 기간 및 비용을 절감할 수 있음.
  • 국제 표준을 적용하여 차후 국내뿐 아니라 선진국 및 개발도상국 시장에서 SI 서비스 및 Package제품을 수출 가능하도록 하는데 목적이 있음.

3) 수익 창출 방향성

  • 의료정보시스템은 병원 간 환자 정보를 연동할 수 있는 Health Information Exchange System (이하 HIE), 개인건강기록 지원 및 의료진과 환자에게 모바일 서비스를 제공하는 것으로 확대 중임.
  • 의료 정보 서비스의 확장, 다양한 외부 시스템과의 연동,수출형 SW Framework에 대한 정의는 지속적인 수익 창출을 위한 필수 요소임.
  • 따라서 대상 아키텍처는 다양한 요구사항에 대한 유연성과 시스템 확장성을 고려해 모듈화 되어야 하고 개방형 구조를 기반으로 만들어져야 함.
  • 또한 외부 시스템과의 연동을 표준에 기반하여 상호 운용성 및 호환성을 확보해야 함.

SW프로세스품질인증 - 인증기준 및 등급

소프트웨어프로세스 품질인증 기준

「소프트웨어프로세스 품질인증 기준」이란 소프트웨어 기업 및 개발 조직의 소프트웨어 프로세스 품질역량 수준을 심사할 때 활용하는 기준을 의미합니다.소프트웨어프로세스 품질인증 기준은 조직의 프로젝트 수행역량 강화를 위해 필요한 핵심 활동을 제시하고 있으며. 조직은 인증기준에서 제시하고 있는 핵심 활동의 수행을 통하여 프로세스 역량수준을 효과적으로 개선할 수 있습니다.
소프트웨어프로세스 품질인증 기준은 5개 영역, 17개 평가항목, 70개 세부평가항목으로 구성되어 있습니다.


소프트웨어프로세스 품질인증 등급

「소프트웨어프로세스 품질인증 등급」이란 인증신청 조직의 품질역량 수준을 심사한 결과를 의미하며, 해당 조직의 품질역량을 프로젝트에서 조직 차원으로 유도하기 위한 계층 구조로 되어 있습니다. 
※ 인증등급은 2개 등급(2등급, 3등급)만 유효 수준을 효과적으로 개선할 수 있습니다.



2015년 7월 22일 수요일

드론 소프트웨어 개발

드론은 유통, 광고, 측량, 보안, 안전관리, 셀피, 게임, 헬스 등 우리 일상은 물론 국방, 행정 등에서도 다양한 변화를 만들어 낼 것입니다. 

Flyver 회사는 드론 소프트웨어 개발용 SDK를 GitHub에 오픈하고 다양한 드론 소프트웨어 개발에 도전하고 있으며 자신들의 App Gallery에서 드론이 가져올 일상의 변화를 이해하기 쉬운 컨셉으로 제시하고 있습니다(그림1). 그리고, 이 컨셉 중에는 이미 실현된 앱도 있습니다.

그림1. Flyver App Gallery: 일상을 변화시킬 드론 앱
출처: http://flyver.co/drone-apps/
국내에는 2015년 3월 기준으로 UAV(Unmanned Aerial Vehicle, 무인항공기) 전문 소프트웨어를 생산하는 기업은 안타깝게도 없습니다. 전량 외국에서 수입합니다. AI(인공지능), 운영체제 기술, 충돌 회피 알고리즘 등 고도의 기술력이 요구되는 드론 전문 소프트웨어는 드론 생산 비용의 40% 이상을 차지합니다.

현재 중국 기업 DJI가 세계 드론 소프트웨어 시장의 50%를 차지할 정도로 거의 독점하고 있습니다. 이 회사는 2006년에 설립된 이래 정부의 지원과 지속적인 연구개발로 2014년에는 매출 5,503억원을 달성하는 등 이 분야에서 세계적 기업이 되었습니다. SW품질은 선진국 수준이고, 가격은 경쟁업체 대비 10분의 1에 불과합니다. DJI는 자신들의 드론 사용을 확대하고 좀 더 창의적인 드론 개발 아이디어를 얻고자 SDK(Software Development Kit)를 공개했습니다. 이 SDK로 개발자는 DJI 드론뿐만 아니라 드론 카메라, 짐벌(나침반·크로노미터를 수평으로 유지하는 장치), 공중 커뮤니케이션에 대한 컨트롤을 수행할 수 있습니다. 더군다나 이 SDK는 iOS 및 Android systems과 호환이 됩니다.

SW사업 선진화를 위한 SW발주기술 지원 사업

최근 몇 년간, 범국가적으로 SW산업 활성화가 눈에 띄게 가시화되고 있습니다. SW산업진흥법, SW중심사회, SW제값주기 등 발주분야뿐만 아니라 SW분야 전반에 걸쳐 제도적인 개선을 추진해 온 것입니다. 하지만 이런 움직임 이후에도, 기대와는 달리 여전히 SW기업들이 적정사업기간과 적정대가를 보장받지 못하고 있으며, 새롭게 공공 정보화 시장에 참여한 중견기업들도 여전히 발주관행, 대가체계, 일하는 방식 등 후진적 환경구조를 답습하고 있습니다. 

 이것은 SW기업의 문제라기보다는 보다 근본적으로 발주환경과 잘못된 관행에 큰 원인이 있다고 할 수 있습니다. SW사업에 대한 이해와 전문성이 부족한 발주자가 요구사항을 명확히 제시하지 못하면 해당 SW사업은 물론 관련 조직의 존폐에도 영향을 미칠 수 있습니다.


SW 발주 전문성이 부족할 때 초래하는 문제점 

l  개발중에 잦은 과업변경과 그로 인한 개발기간 지연
l  SW 사업의 부실과 더불어 참여기업 수익성 악화
l SW 개발자의 노동환경 악화
l  개발을 담당한  SW기업과 사업에 참여한 솔루션 업체들의 생존 위협


발주역량 강화와 발주환경의 체계를 선진화하기 위해, 
[SW발주기술지원센터] 출범

공공부문 정보화 사업 발주/관리의 모든 단계에서 상세요구사항도출, 사업기간 및 비용산정 등 발주자가 어려워하는 업무지원을 위해 해당 분야의 전문가를 투입하여 지원하는 내용을 골자로, 공공SW 사업의 발주담당자 역량강화를 위한 제도적인 지원 장치를 마련한 것입니다.

자세히 보기 →

사용자 의도를 정확히 파악하여 소프트웨어를 개발하는 TDD(Test Driven Development) 활용법

사용자 스토리 워크샵은 사용자와 소프트웨어 개발자 간의 커뮤니케이션을 활발하게 하여 만들려는 소프트웨어의 비전을 공유하고, 기능을 구체화한 사용자 스토리를 정리하는 활동이다. 사용자 스토리 워크샵의 가장 큰 목적은 “사용자의 요구사항을”, “사용자와 함께”, “사용자의 용어”로 정의하는 것입니다.

이렇게 만들어진 사용자 스토리를 기초로, 소프트웨어 개발자는 사용자의 요구사항을 프로젝트 초기부터 명확히 반영한다면, 사용자의 요구사항이 제대로 반영되지 않아 재개발을 해야 하는 문제가 발생하지 않을 것입니다. 최근의 소프트웨어 개발 트랜드는 소프트웨어 개발자의 개발 역량에 치중하는 것이 아니라 사용자의 요구사항을 명확히 반영하여 사용자의 만족도를 높이는 것으로 변하고 있습니다. 다시 말해, 소프트웨어를 개발자의 관점이 아닌 사용자의 관점으로 개발하는 것이 소프트웨어 개발자에게 요구되고 있는 것입니다.

사용자 스토리를 작성한 후 소프트웨어 개발자가 어떤 활동을 해야 하는지를 살펴보고자 하며, 그 중에서도 소프트웨어 개발자 주도로 진행되던 테스트를 사용자 관점으로는 어떻게 해야 하는지 알아보도록 합니다.

<소프트웨어 개발자의 필요역량 변화>




2015년 7월 21일 화요일

[SW아키텍처 참조모델] 모바일 오픈 아키텍쳐 레퍼런스 설계(안드로이드)

본 문서는 안드로이드를 기반으로하는 모바일 제품의 아키텍처 참조 모델로 작성되었습니다.

* 모바일 오픈 아키텍쳐 레퍼런스 모델의 해결 문제 목록
- 안드로이드 OS의 파편화
- 오픈 소스로써의 개방성 문제 : 폐쇄성
- 품질 속성 문제: 사용성
- 품질 속성 문제: 유지보수성

* 아키텍쳐 설계 개선 목적
본 모바일 오픈 아키텍처 개선 과제에서는 많은 개발자들과 오픈 소스 커뮤니티에서 검증된 오픈 소스들을 가져와서 개선/수정/리팩토링을 하여서 위에서 언급한 문제들 ? 파편화, 폐쇄성, 사용성, 유지보수성 ?을 해결하면서 다양한 요구사항을 만족시키고 개발 생산성 향상을 꾀하여서 개발 비용 관련 이슈나 파편화 문제 등을 해결하고자 한다. 더불어 이번 과제를 통해서 개선된 아키텍처 및 소스코드를 소개 및 공개/배포함으로써 다른 개발자들이 쉽게 활용하고 더 나은 feature, 아키텍처 및 생태계를 만들어 나갈 수 있도록 하였다.

* 관련 계층
- 유저 인터페이스 (User Interface)
안드로이드의 화면 단편화및 버전 단편화로 인해 버전 별로 제공할수 있는 Widget 함수와 기능들이 상이하다. 액션바 같은 경우, 3.X 버전 때부터 안드로이드에 추가 되었지만, 2.X 버전의 사용자가 전체 안드로이드 폰에서 40%이상이므로, 실제 배포되는 앱에 적용할수 없다. 또한 안드로이드는 커스텀 유저 인터페이스 컴포넌트를 만드는데 많은 비용이 발생한다.

- 네트워크 (Network)
독립형 어플리케이션보다 네트워크 기능을 제공하는 어플리케이션의 중요도가 (앱 내부 결제나 소셜 서비스의 연동)갈수록 성장하고 있다. 2012년 Distimo의 조사에 의하면 네트워크 기반의 어플리케이션의 매출이 전체 앱 시장에서 72%의 매출을 차지한다. 하지만 안드로이드가 제공하는 네트워크 기능은 단순해서, 어플리케이션 구축시 많은 비용이 발생하는 영역이다.

- 공용부 (Common)
안드로이드는 구글의 폐쇄적인 정책으로 인해, 시장의 요구를 재빨리 반영하지 못하고 있다. 이로 인해 어플리케이션에 필요한 로깅, 결제 모듈, 컴포넌트 설정부등을 별도로 제공하지 않고 있다. 

- 서비스로써의 백엔드 (BaaS)
모바일 앱을 개발할때, 구글이 제공하는 백엔드 기능 (푸쉬, 사용자 통계, 오류 리포트)의 품질이 부족하다. 푸쉬 서비스 같은 경우는 지연이나 손실율이 발생하고, 에러 리포트 기능 또한 제한적인 정보만 제공한다. 그러므로 모바일 개발에 필요한 백엔드 서비스를 직접 구축해야 하는 문제가 발생한다.

본 문서는 위의 4계층에서의 주요 문제의 해결책과 아키텍쳐적인 관점, 오픈소스 사례등을 설명하고 있습니다.

자세히 보기 →

[입찰공고]2015년 SW R&D 품질관리 사업 성과분석

용 역 입 찰 재 공 고

1. 입찰에 부치는 사항
  가 . 입찰건명 : 2015 년 SW R&D 품질관리 사업 성과분석
  나 . 추정소요예산 : 45,000,000 원 ( 부가세포함 )
  ※ 부가세 면세사업자(비영리기관 등)는 부가세를 제외한 금액한도 내에서 가격제안
  다 . 용역기간 : 계약체결일로부터 약 6 개월간
  라 . 제안서 ( 입찰참가신청 ) 제출 ( 시간초과시 서류제출이 불가합니다 .)
     ① 제출마감일자 : 2015. 7. 29( 수 ) 15 시까지
     ② 접수방법 : NIPA 전자계약시스템 을 통한 온라인 접수 ( http://cont.nipa.kr )

* 접수마감 기한 경과시 전자계약시스템 ( 온라인 접수 ) 이 자동마감 ( 연장불가 ) 되며 , 마감시간에 임박하여 접수를 시도할 경우 시스템 사용 미숙에 따른 오류 , 등록 집중으로 인한 시스템 장애 등이 발생할 수 있으니 가급적 1~2 일 전부터 여유를 갖고 접수하시기 바랍니다 .

제 56회 SW공학 Technical 세미나

"해외의 선진 사례와 국제표준 관점으로 보는 
 국내 핀테크와 SW Testing의 발전 방향"

일  시: 2015.07.30(목) 14:00-17:00
장  소: 누리꿈스퀘어 비즈니스타워 4층 대회의실


자세히 보기 →

2015년 7월 18일 토요일

SW코드닥터 서비스

본 서비스는 SW 제품 품질과 개발자 역량 향상을 위한 SW공학기술의 확산을 목적으로, 코딩 기술에 대한 교육과 코딩 가이드를 제공하고 소스 코드 품질 진단을 통하여 SW자산의 구축을 지원하는 기업맞춤형 컨설팅 서비스입니다.

자세히 보기 →

제 55회 SW공학 Technical 세미나 - 스튜어트 리드 STA CEO(2부)

7월 2일(목)에 진행한 Technical 세미나 동영상이 업로드 되었습니다.
  • 리뷰 타입과 리뷰 요소를 고려한 리뷰선택
  • ISO 29119/33063/20246 표준 진행 사항




제 55회 SW공학 Technical 세미나 - 스튜어트 리드 STA CEO (1부)

7월 2일(목)에 진행한 Technical 세미나 동영상이 업로드 되었습니다.
  • IOS/IEC 20246 & ISO 29119 표준소개
  • 일반적 리뷰 프로세스(Generic review process)
  • 개별리뷰기법(Individual review techniques)




2015년 7월 17일 금요일

관련지침개발 - 제품라인 공학연구(PLE4G)

제품라인 공학연구(PLE4G)는 재사용성 향상을 통해 수출용 소프트웨어의 품질과 생산성을 끌어올리기 위하여, 공학센터와 제품라인공학 분야 해외 석학인 Klaus Schmid 교수가 공동 개발한 SW글로벌화에 적합하도록 경량화된 제품라인공학방법론 교육과정입니다.

글로벌 SW 개발을 위해 필수적으로 요구되는 제품에 대한 글로벌/로컬 요구분석, 글로벌 아키텍쳐 구성, SW 재사용성을 극대화하기 위한 제품 설계 및 구현 부분에 이르기까지 이론과 실습을 함께 구성하여 제품라인공학 기술을 곧바로 현업에서 도입하고 활용할 수 있도록 하였으며, 교육 효과를 높이기 위해 공학센터 전문가에 의한 순차 통역 제공합니다.

SW테스팅프론티어 서비스

SW테스팅프론티어 서비스는 비효율적이고 일관성 없는 SW테스트로 인해 SW개발을 실패한 중소SW기업을 위하여 기업 내에 SW테스트 프로세스의 체계 수립 및 효율적인 SW테스트를 수행 방안 마련을 목적으로 한 서비스입니다.

본 서비스는 기업 내 테스트 현황을 파악하여 개선 항목을 도출하는 역량평가 서비스와 SW테스트 기술 습득 및 적용을 위한 이론 교육 및 실습으로 구성되어 있습니다.

  • 지역 내 중ㆍ소 SW 기업의 SW 테스팅 전문인력 육성과 역량강화를 위해 테스팅 프론티어 서비스를 무료로 제공
  • 본 서비스는 지역 SW기업을 위한 맞춤형 서비스로 각 지역 SW 진흥기관과의 긴밀한 협력을 통해서 수행
  • 지역 SW진흥기관의 수요기업 모집을 통해 교육 대상 및 일정을 확정하여 지역 SW진흥기관에서 교육 서비스를 실시
  • 컨설팅 서비스를 요청한 업체에 대해서는 기업별로 일정을 확정하여 직접 방문 서비스를 실시
  • SW공학센터 포털 사이트를 통해 업체에서 서비스를 신청하면 담당자와 협의를 통해 서비스를 실시



SW품질역량 강화를 위한 공통교육(GCS school) 교육생 모집

SW품질역량 강화를 위한 공통교육(GCS school)교육생 모집(정부지원 과정)

정보통신산업진흥원 SW공학센터에서는 GCS과제(선도 과제 포함) 수행기관의 원활한 과제수행과 품질역량 강화를 효율적으로 지원하기 위해 기반이 되는 SW공학 교육(GCS school)을 지원합니다.

































자세히 보기 →

2015년 7월 16일 목요일

프로젝트의 새로운 의사소통 채널, User Story Workshop⑵

최근 들어, 소프트웨어 개발 프로젝트에 애자일이 많이 적용되고 있다. 고객의 요구사항을 빠르게 받아들이고 불필요한 프로세스를 커뮤니케이션 위주로 해결하는 애자일은 소프트웨어 개발자들에게 거스를 수 없는 것이 되어 버렸습니다. 애자일이 기존의 개발방법론이다라고 오해하는 사람들이 많습니다. 애자일을 기반으로 개발방법론을 만드는 것이지 애자일 자체가 개발방법론은 아닙니다. 그러다 보니 기존의 개발방법론처럼 산출물 위주의 프로젝트 관리를 위한 것이라고 볼 수 없습니다. 애자일 기반으로 정리된 사용자 스토리 워크샵 또한 프로젝트 관리를 위해서 행해지는 것은 아닙니다. 사용자 스토리 워크샵은 사용자의 요구사항을 정확히 이해하고 명확히 소프트웨어에 반영하기 위한 도구라고 할 수 있습니다. 소프트웨어 개발자는 이제 소프트웨어를 개발하기 위한 요소기술만 알아서는 품질이 높고 사용자가 편한 소프트웨어를 개발할 수 없다는 것을 명심해야 합니다.


GCS(Global Creative Software) R&D 품질관리

정부는 2010년부터 글로벌 전문기업*육성을 위해 유망 중소기업 주도의 상용화 연구개발 사업을 추진 중이며, 연구개발사업의 성공 가능성을 높이고 글로벌 품질 수준 달성을 위해 SW공학센터를 통해 품질교육, 기술자문, 점검 등 품질관리 사업을 추진하고 있습니다.

SW공학센터는 2010년부터 2013년까지 3년간 수행된 대형 국책 R&D 사업인 WBS(World Best SW) R&D 품질관리 사업을 통해, 축적된 경험을 바탕으로 기업 현황과 과제 목표에 맞는 차별화된 품질관리 서비스를 제공합니다.


개발자를 위한 Fintech Payment Architecture

Payment 기술 개발에 있어 가장 중요한 고려사항은 무엇인가요? 
‘고객 관점에서 얼마나 편리한 서비스를 안전하게 구현하는가’ 입니다. 그리고 함께 고려해야 할 제약사항이 하나 더 존재하는데, 바로 정부 정책 즉, 규제에 대한 부분입니다.

정리하자면, 고객의 결제 UX 를 개선하고 편리함을 주기 위한 서비스 설계가 필요하며, 이와 상반될 수 있지만, 보안성과 관련 규제를 지켜낼 수 있는 설계 또한 필요한 것이 Payment 기술 개발이라는 것입니다.

UX(User eXperience)의 개선방향은? 
Payment 기술 개발은 사용자 결제 UX 를 더 편리하게 하고, 어떤 경우에는 기존 UX 를 혁신하고 타파할 수 있어야 합니다. 이를 위해서는 결제나 금융 서비스 사용 환경에 대해 끊임없는 관심과 애정을 기반으로, 다양한 아이디어를 고민하고 이를 구현해 보려는 시도를 즐겨야 합니다. 기술적으로는, 사용자의 불편함을 초래했던 서비스 플로우들(사용자 입력 및 추가적인 솔루션 설치 등)을 백그라운드 프로세스로 처리할 수 있는 방안을 도입하여, 이를 해결할 수 있습니다.
예를 들어, 사용자가 인증 문자를 받아서 이를 해당 결제 서비스 페이지에 입력해서 결제를 수행하는 방식을, 사용자 단말에서 해당 결제 서버에 문자를 자동 발송해서 결제 인증을 수행하는 방식으로 변경하는 것은 백그라운드 프로세스를 통해 사용자가 입력하는 불편함을 제거한 좋은 기술적 방식입니다.


SK Telecom 종합기술원 솔루션개발팀 조문옥 부장은 용어 자체에 대한 철학적 견해도 내놓았습니다. 바로, ‘핀테크’가 아니라 ‘테크핀’이어야 한다는 것. 지금까지는 Finance 가 Technology 를 끌어 가는 모양새였다면, 이제는 Technology 가 Finance 를 이끌어 간다는 의미입니다. 이제는 IT 기술이 생활전반에 깊숙이 파고들어 있고, IT 없이는 Finance 를 더 이상 논할 수 없게 되었습니다. 이러한 환경에서 Technology 를 누구보다 잘 알고 있는 개발자들이 더 과감한 생각을 가지고 혁신과 도전, 그리고 시장을 리드해 나간다면 개발자들의 위상이 지금보다 높아질 것은 자명하고, 그러려면 개발자들의 더 ‘주도적인 태도변화’도 필요하다고 강조했습니다.




자세히 보기 →

2015년 7월 15일 수요일

SW영향평가제

중앙부처 등 공공기관 및 광역자치단체를 대상으로 SW기획 및 구축 사업(운영·유지보수 사업 포함)에 대해 SW영향평가를 수행 합니다.

SW모니터링단을 통해 접수된 공공기관 SW개발 발주분야 불공정행위(공공기관 SW무상배포 등)를 심사하여 시정요청 등 발주분야 개선을 수행 합니다.


자세히 보기 →

개발자를 위한 UX 5 Tips

  1. 사용자 중심의 질문
  2. 사용이 단순하고 쉽고 빠르게
  3. 디자인의 강약
  4. 액션을 바로 줄 수 있는 친근한 카피라이트
  5. 인포그래픽으로 표현하는 분석



SW사업 대가산정

SW사업 대가산정 체계연구는 SW사업대가기준 고시가 폐지됨에 따라, 민간운영을 통해 시장 자율에 의한 SW대가가 적용될 수 있는 환경을 조성하기 위해 SW기술자 임금실태 조사 및 분석, 공공부문 발주자 대상 SW사업 대가산정교육, SW사업 대가산정 가이드 개선을 위한 관련 연구 수행 및 사례 수집, 기능점수당 단가산정 체계 보완 연구 등을 수행하는 사업입니다.

기존의 공공부문 SW사업 대가산정 체계연구는 「소프트웨어사업 대가의 기준」과 「엔지니어링사업 대가의 기준」을 활용하여 왔으나, 2010년 2월 26일 고시된「소프트웨어사업 대가의 기준」 (지식경제부 고시 제2010-52호) 부칙 제4조(소프트웨어사업 대가의 기준 재검토)에 의거하여 “정부는 소프트웨어사업에 적용되는 사업대가가 민간 자율로 결정되도록 유도하기 위하여 동 기준을 시행일로부터 2년이 되는 시점에 폐지한다.”라고 고시됨에 따라 SW사업 대가의 기준은 2012년 2월 26일 이후 더 이상 적용될 수 없게 되었습니다.

기존 정부 고시의 정적인 형태로 유지되어 왔던 SW사업 대가의 기준을 민간으로 이양하고, 이에 따른 혼란을 최소화하기 위해 국가기관 등에서 SW사업의 대가산정 시 준용할 수 있는 대체방안으로 “SW사업 대가산정 가이드” 가 마련되었으며, 이는 2012년 2월 한국소프트웨어산업협회에서 공표되었습니다.

본 가이드는, SW산업의 동적인 상황과 글로벌 표준에 입각한 ISO12207 기반의 소프트웨어의 수명주기(기획, 구현, 유지보수·운영) 전반에 걸쳐 대가산정 방법을 알기 쉽게 설명하고, 보다 편리하게 수행할 수 있는 도구를 제공하는 것을 목적으로 하여 개발되었습니다.

2015년 7월 14일 화요일

패키지SW활용촉진

SW산업을 육성하기 위해 공공부문 정보화사업에서 패키지SW를 활용하여 정보시스템 구축을 활성화하고, 공공정보화 사업 수행 시 자체개발(Make)을 지양하고 패키지SW 구매(Buy) 및 활용에 집중하고 있습니다.

  • 공공부문 정보화사업의 기획부터 사업발주 및 운영단계에서 비교자료로 활용할 수 있는 패키지SW 정보를 체계적으로 수집하고 시스템화하여 제공
  • 패키지SW 솔루션맵 및 가이드라인을 활용하여 사전검증·도입검토 등 패키지SW 적용 지원 시범 서비스 추진


패키지SW도입 vs. SI개발 및 적용프로세스

자세히 보기 →

국가 R&D과제 품질관리

GCS R&D 품질관리 사업은 대형 상용화 SW R&D사업인 “WBS(World Best Software) 프로젝트”에 대해 이름에 걸맞는 글로벌 품질 경쟁력 확보를 목적으로 SW개발 全단계에 걸쳐 제3자의 독립적 관점으로 품질점검 및 지원을 수행하는 사업입니다.


"리얼타임테크, 미국 콘퍼런스서 한국형 SW공학 성공사례 발표" 기사

리얼타임테크, 미국 콘퍼런스서 한국형 SW공학 성공사례 발표

인메모리 데이터베이스관리 전문기업 리얼타임테크는 지난 12일(현지시간) 미국 시애틀에서 열린 CMMI(Institute Global Congress Seattle)글로벌콘퍼런스에서 한국형 소프트웨어(SW)공학 성공 사례를 발표했다고 15일 밝혔다. 

CMMI글로벌콘퍼런스는 미국 CMMI협회가 매년 주최하는 행사로 올해 25회째를 맞았으며, SW 개발과 프로세스 개선, 기업 혁신 부문 관련 전세계 주요 기업과 연구기관에서 발표를 진행한다. 국내 기업 중 발표를 진행한 것은 이번이 처음이다.

리얼타임테크는 정부 R&D 사업인 글로벌 크리에이티브 SW(GCS)와 월드베스트SW(WBS) 수행시, 정보통신산업진흥원 SW공학센터의 도움을 받아 구축한 SW 시각화 체계를 이용해 인력, 업무, 기술 현황을 통합해 유지보수 비용을 절감한 사례를 발표했다. 

한혁 리얼타임테크 연구소장은 "SW공학을 통해 제품 기술력을 강화할 수 있었다"며 "개선된 기술력을 통해 해외시장 수출에서도 성과를 기대하고 있다"고 말했다.

지난 12일 미국 시애틀에서 열린 CMMI글로벌콘퍼런스에서, 국내 업체 리얼타임테크 프로세스 개선 업무를 컨설팅한 프로와이즈 정성규 대표가 한국형 SW공학 성공사례를 발표하고 있다.
출처: 디지털 타임스

SW발주기술지원

범국가적인 SW산업 활성화(SW산업진흥, SW제값주기 등)를 위해, 공공SW분야 발주 전반 걸쳐 제도적 개선을 추진했으나, 제도개선과 모니터링만으로는 SW산업활성화 실행력 확보에 한계가 있어 직접적 지원체계가 필요합니다.

공공SW사업 발주관리 全과정에 걸쳐, 전문성이 요구되는 발주업무에 대해 발주관리 전문가 직접투입 지원을 추진하고, 대상 발주기관의 지원요청별 특성, 환경, 내용 등에 따른 맞춤형 최적화 지원을 추진합니다.


자세히 보기 →

2015년 7월 11일 토요일

SW아키텍처 관리 서비스

중소 SW기업에 대한 SW 아키텍처 설계 기본 및 설계 기법 실습 교육과 SW기업의 설계 멘토링을 제공하는 SW기업 밀착형 컨설팅 지원 서비스입니다. 

SW 아키텍처의 기본 개념을 전파하여 SW 설계의 인식을 제고하고, 실용적인 아키텍처 설계 절차의 실습 교육/적용/멘토링을 진행하여 SW 품질 및 SW 공학 역량 강화를 지원하고, 초급 개발자에서 아키텍처 설계자까지 SW 설계의 방법 및 수행 절차에 익숙하지 않는 개발자를 대상으로 설계의 개념과 수행 방법을 이해시키며, 설계 단계 수행 시 실제 업무에 적용가능한 수준의 설계 수행 절차를 소개하고 있습니다.


SW요구사항 관리 서비스

SW요구사항 관리 서비스는 불분명한 요구사항으로 인하여 SW개발이 실패한 중소 SW기업을 위하여 SW요구사항으로 효율적이고 체계적으로 분석하고 관리하기 위한 방안을 전수하기 위한 목적으로 하는 SW요구사항 오퍼링 서비스입니다. 

본 서비스에서는 SW 요구사항 기본 개념/요구사항 명세 기법을 교육/실습하여 개발자, 관리자, 이해관계자 등 서로 다른 입장에서 적용 가능한 다양한 요구사항 기법 및 수행 방안을 제시하고, 업무에서 바로 사용가능한 요구사항 명세서를 비롯한 계획서, 정의서와 보고서 양식에 대한 작성/관리 방법을 교육함으로써 SW요구사항 업무체계확보 및 SW제품의 품질 향상을 기대할 수 있습니다.


SP인증(SW프로세스품질인증) 사전진단서비스

SP 인증획득에 관심있는 기업을 대상으로 인증심사 준비내용등을 진단하여 인증심사 준비를 효율적으로 할 수 있도록 지원합니다.

원내소속 ‘SP 인증심사원 ’ 이 신청기업을 방문하여 인증제도 , 심사절차 설명 등 상담 서비스를 하고 있습니다.


2015년 7월 10일 금요일

SW글로벌화 지원

SW 글로벌화 지원은 SW 개발 및 글로벌화 전 단계에 걸친 재사용성 강화, 국제화 이슈 대응, 애자일 방식 추진으로 글로벌 품질 경쟁력을 확보하는 사업입니다.
소프트웨어의 해외 진출 또는 수출을 준비하고 있거나 현재 진행하고 있는 국내 기업을 대상으로 GQM 교육/멘토링 서비스, GQM 컨설팅 서비스, 해외 전문가 초청 엔지니어링 워크샵 등을 지원하고 있습니다.


자세히 보기 →

10,000명의 글로벌 IT 전문가는 지금 Hybrid Cloud 도입에 무게를 두고 있다.

하이브리드 클라우드(Hybrid Cloud)는 클라우드 컴퓨팅의 구축 모델 중 하나입니다. IT 리소스로 내부 프라이빗 클라우드(Private Cloud)와 타사 서비스 공급업체의 퍼블릭 클라우드(Public Cloud)를 이용하여 서비스를 제공하는 방식입니다. 

그간 IT 환경 구축은 일반적으로 소프트웨어와 하드웨어를 개별적으로 구매하고 관리하면서 수 개월의 시간을 투자하는 방식이었습니다. 그에 반해, 클라우드 컴퓨팅 환경에서는 다양한 IT 리소스를 단기간(몇 분 또는 몇 시간 내에도)에 이용할 수 있고, 비용은 실제 사용량에 따라 지불됩니다. 

IDC(International Data Corporation)는 2015년 클라우드 컴퓨팅 시장 규모를 작년 대비 23% 성장한 1,180억 달러로 추정하고 있습니다.  
65% 이상의 IT 기업들이 2016년에는 하이브리드 클라우드 서비스를 채택할 것으로 전망하고 있습니다.

‘사용자 스토리 워크샵’의 현장 적용을 위한 조언

소프트웨어 개발에 있어서 쉬운 부분은 어느 하나도 없겠지만, 다들 가장 어렵다고 입을 모으는 것이 바로 ‘요구분석’ 입니다. 정확도와 속도, 이 두 가지를 모두 만족해야 하기 때문입니다. 그래서 최근 주목 받아 온 것이 ‘애자일 방법론’ 이지만, 그 적용은 생각보다 쉽지 않습니다. 아니, 사실 무척 까다롭습니다. 

그런 애자일의 ‘사용자 스토리 워크샵’을 맨몸으로 몸소 부딪혀가며 배우고, 익히고, 조직에 흡수시켜 온 요구분석계의 ‘잔다르크’ 같은 사람이 있다고 해서 궁금했습니다. 바로, ㈜ 넷스루의 오재훈 연구소장입니다. 
왜 사용자 스토리 워크샵이어야 하며, 어떻게 조직원들과 함께 적용시켜왔는지 궁금해, 직접 만나봤습니다.

(주)넷스루는 2012년부터 스크럼과 XP(eXtreme Programming)을 기반으로 한 애자일 개발 프로세스로 제품을 개발하고 있습니다. 오재훈 연구소장이 이 사용자 스토리 워크샵을 2012년에 처음 도입할 때는 도움을 받을 곳이 마땅치 않아 책을 읽고 이해하고, 현실에 적용하면서 좌충우돌하면서 배우기 시작했다고 합니다.  마침, 2012년에 정보통신산업진흥원(NIPA) 산하 소프트웨어 공학센터에서 지원하는 ‘소프트웨어공학기술 현장적용 사업’을 수행하면서 애자일에 대한 이해도가 높아질 수 있었습니다.  2014년에도 소프트웨어공학기술 현장적용사업의 지원을 받아 프로젝트를 수행했는데, 애자일 전문컨설팅 기관의 도움을 받아 스크럼을 적용하면서 깊이가 더해졌습니다. 그 전까지는 책을 읽고 형식을 주로 따라하는 과정이었다고 한다면, 전문 스크럼 마스터가 스크럼 이벤트를 퍼실리테이션(facilitation)하는 과정을 보면서, 책에서는 배울 수 없는 실천 지식을 많이 배울 수 있었다고 합니다.



  1. 요구사항 분석에 활용할 수 있는 ‘예제를 활용한 명세기법’(Specification by Examples)
  2. 예제를 활용한 명세기법을 이용해서 사용자 스토리 워크샵을 진행하는 방법
  3. 예제를 활용한 명세기법을 적용했을 때 얻을 수 있는 효과
자세히 보기 →

2015년 7월 9일 목요일

SW사업정보 저장소

SW사업정보 저장소 사업은 SW사업 대가기준 고시가 폐지 및 민간이양 됨에 따라 국가 정보화예산 편성·집행시 필요한 객관적·정량적 대가산정 근거 마련을 위해 SW사업 수행 실적데이터를 수집, 검증, 분석하여 신규 사업 추진 시 요구사항 식별, 비용, 공수, 개발기간 등의 정보를 객관적으로 추정토록 하는 사업입니다.

추진배경은 SW사업 예산수립 및 대가산정에 있어 발주자, 수주기업 등 이해관계자들은 업무 수행에 어려움을 겪고 있으며, 근본적인 해결책을 요구하고 있습니다.


자세히보기 →

알기 쉬운 SW공학배우기_8화

소스코드 품질을 알아보겠습니다.
  • 코딩 가이드북
  • 정적분석 도구



공공데이터 개방

공공데이터개방 안내

공공데이터는 데이터베이스, 전자화된 파일 등 공공기관이 법령 등에서 정하는 목적을 위하여 생성 또는 취득하여 처리하고 있는 광(光) 또는 전자적 방식으로 처리된 자료 또는 정보입니다.

공공데이터 개방은 공공기관이 이용자에 ① 정보를 재활용할 수 있도록 제공하고, 제공받은 정보를 ② 영리·비영리적으로 이용할 권한을 부여하는 것입니다.

관련규정
공공데이터의 제공 및 이용 활성화에 관한 법률
공공데이터 공개 (공공데이터의 제공 및 이용활성화에 관한 법률 제19조)
- 2015년 SW공학센터 개방 DB

자세히 보기 →

2015년 7월 8일 수요일

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

제 55회 SW공학 Technical 세미나
"리뷰(Review) 국제 표준(IOS/IEC 20246, Work Product Reviews)"
발표자료가 업데이트 되었습니다.

자세히 보기 →

프로젝트의 새로운 의사소통 채널, User Story Workshop⑴


요구사항 분석 패러다임의 변화

간단히 사용되는 소프트웨어부터 기관이나 기업에서 사용되는 대규모 소프트웨어까지 사용자가 원하는 것을 얼마나 잘 반영하여 개발했는지에 따라 소프트웨어 개발 프로젝트의 성공여부가 결정되기 때문에 소프트웨어를 개발하는 프로젝트의 가장 큰 목표는 사용자의 요구사항을 어떻게 하면 정확히 알아낼 수 있을까 하는 것입니다. 따라서 소프트웨어공학에서는 사용자의 요구사항을 어떻게 하면 잘 이끌어내고 정리할 것인지에 대한 고민이 계속되고 있습니다.

개발자 관점에서 사용자 관점으로 요구사항을 분석한다.

요구사항 분석은 개발자가 궁금한 것을 질의응답 형태로 확인하여 일괄적으로 정리하던 전통적인 방식에서 2000년대 중반전후부터 짧은 기능이나 업무 단위로 분리하여 반복하여 확인하는 이터레이션(Iteration)을 적용한 방식이 널리 사용되고 있습니다. 하지만 여전히 개발자 중심으로 진행되는 방식으로는 사용자가 원하는 것을 모두 정리하는데 한계가 있기 때문에  최근에는 사용자가 원하는 것을 스토리로 정리하는 방식이 주목받고 있습니다. 개발자 관점에서 사용자 관점으로 요구분석 패러다임이 변하고 있는 것입니다.
 

SW공학센터 체험형 인턴 채용 공고

정보통신산업의 고도화와 미래 신사업 창출을 선도할 진취적이고 창의적인 인재를 다음과 같이 모집합니다 .
 
1. 모집분야 및 자격요건

 o 공통 지원 자격
    - 국가공무원법 제 33 조에 해당하지 않는 자
    - 해외여행에 결격사항이 없는 자 , 남자인 경우 병역필 또는 면제자
    - 응시연령 : 만 34 세 이하 (1981. 7. 6 이후 출생자 )
    - 학력사항 : 제한없음

o 우대조건
    - 취업보호대상자 ( 국가보훈대상자 등 ), 장애인복지법상 등록장애인 등

o 모집분야


공고일 및 접수기간 : 2015. 7. 6( 월 ) ~ 2015. 7. 20( 월 ) 16:00 까지
 

2015년 7월 7일 화요일

청소년 SW 진로탐색 지원 협약식 (마포진로직업체험지원센터)

소프트웨어공학센터는 7월 1일(수)  서울 상암동 누리꿈스퀘어에서 마포진로직업 체험지원센터와  현장직업 체험 프로그램을 포함한 봉사 협약을 체결하였습니다.
 
 
 

패키지SW가이드라인

공공부문 소프트웨어사업을 위한
패키지소프트웨어 사전검증 가이드라인


1.가이드라인의 목적
소프트웨어산업의 경쟁력 제고 및 공공 정보화 시스템의 효율적 운영을 위해서는 지속적인 기술 및 서비스의 축적과 제공이 성공의 핵심요소라 할 수 있습니다. 그러나 개발(SI) 방식은 일회성·단발성으로 이루어져 지속적인 기술축적 및 상품화에 한계가 있을 수 있습니다.

공공 정보시스템 구축 시 개발(SI) 대신 패키지소프트웨어 도입으로 추진할 경우 산업현장에서 검증된 안정적인 소프트웨어의 사용을 통해 글로벌 프로세스를 적용할 수 있으며, 개발(SI) 대비 도입 비용과 시간의 단축이 가능하다는 장점이 있습니다. 그러나 발주기관은 필요한 시스템 구축에 개발(SI)이 적합한지 패키지소프트웨어 도입이 효율적인지를 판단할 근거와 기준이 부족하여, 패키지소프트웨어 도입에 어려움을 겪고 있습니다.

 이에 본 가이드라인은 공공부문 발주기관이 패키지소프트웨어를 기반으로 정보시스템을 구축하려 할 경우 1) 개발(SI)과 패키지소프트웨어 도입 사이의 사전검증기준과, 2) 개발(SI)과 패키지소프트웨어 도입 결정을 위해 고려해야할 점검사항을 제시하여 소프트웨어 사업 진행 시 예산·기간·운영 상 효율성을 제고하고자 합니다.

2. 가이드라인의 적용 대상 및 범위
본 가이드라인은 국가, 지방자치단체, 정부투자기관 및 기타 공공기관(이하 “국가기관 등“이라 한다)이 발주하는 정보시스템 구축 사업에 적용되며, 공공부문 소프트웨어 사업에 참여하는 공급자도 이를 참조합니다.

3. 소프트웨어 개발(SI)/패키지소프트웨어 도입 사전검증 기준
본 가이드라인에서 제시하는 사전검증 기준은 제안요청서 작성 이전에 소프트웨어 개발(SI) 또는 패키지소프트웨어 도입 사이의 발주자 판단을 돕기 위한 기준 및 점검사항을 의미합니다.

4. 소프트웨어 개발(SI)/패키지소프트웨어 도입 결정을 위한 체크리스트
공공부문 소프트웨어 사업 진행을 위한 개발(SI)/패키지소프트웨어 도입 결정 시, 고려 해야 할 일반사항들을 다음의 체크리스트로 점검합니다. 체크리스트에는 소프트웨어 사업 진행시, 새로운 시스템 개발(SI)과 패키지소프트웨어 도입 후 적용 사이에 무엇이 더 적합 할지를 선택하는데 도움이 되는 질문들이 정리되어 있습니다.
 

SW Visualization

SW공학센터는 국내환경에 최적화된 SW공학기술을 연구·적용하여 SW기업의 경쟁력을 높이고자 합니다.

SW Visualization은 효율적인 SW 개발 관리를 통하여 기업의 SW 경쟁력 확보를 지원하기 위한 서비스입니다.
성공적인 SW 개발 관리를 위해서는 명확한 목표수립과 효율적인 수행, 지속적 모니터링 및 통제 활동이 필요합니다.
 SW Visualization은
①품질지표에 의한 명확한 목표수립
②시스템 기반의 효율적인 개발 활동
③시각화를 통한 지속적 모니터링 및 통제를 가능토록하여 성공적인 SW 개발 관리의 기반을 제공합니다.

기업은 SW Visualization을 활용함으로써 SW의 비가시성을 극복하고 SW개발 과정의 투명성을 확보할 수 있습니다. SW 개발 과정의 투명화는 SW 품질 확보 및 SW 품질 문제의 조기 검출을 통한 품질비용 절감으로 기업 경쟁력을 확보할 수 있습니다.

자세히 보기 →

2015년 7월 4일 토요일

공공QMO

SW공학센터는 개발 생산성 및 품질 제고를 위한 다양한 컨설팅 서비스를 제공합니다.
공공QMO(Quality Management Office) 컨설팅은 공공부문 정보화사업의 성공적인 추진과 품질확보를 위해, 발주자를 대상으로 발주관리능력과 품질관리체계를 지원하고, 수주자에게 SW공학기법을 통해 개발능력 강화를 지원하는 컨설팅입니다.

기존 정보화사업은 체크리스트 중심의 관리관점으로 추진되어 발주자의 관리역량 및 수행자의 역량이 부족할 경우, 관리되지 않고 사업 종료시점에 최종 문제점이 발생되는 등 여러가지 문제점이 발생하여 지속적인 통제 개념의 접근방법이 필요 하게 되었습니다.

대부분의 공공 정보화사업은 PMO(Project Management Office), 감리 등을 통해 지원하고 있으나 관리적 관점에서 접근하여, 단계별 검토만을 수행함으로서, 최종단계에서 문제가 발생했을 경우 해결을 위한 어려움이 발생하고, 사업 종료후 미봉책에 그치는 등의 문제가 발생하고 있습니다.

이에 SW공학센터에서는 공공 정보화사업을 대상으로 발주자, 수주자 동시접근을 통해 수행역량을 강화시키고, 수행과정상 품질을 확보하여, 공공 정보화사업을 성공적으로 추진할 수 있도록 지원하고 있습니다.

Q-Clinic

SW공학센터는 개발 생산성 및 품질 제고를 위한 다양한 컨설팅 서비스를 제공합니다.

Q-Clinic은 SW공학센터의자체수행 컨설팅 서비스를 기반으로 SW개발 라이프 사이클 전반에 걸친 컨설팅을 제공하는 서비스입니다.
SW공학수준진단을 기반으로 요구사항부터 테스팅까지의 SW공학 컨설팅 서비스의 내재화와 지속적 컨설팅 서비스를 제공합니다.

SP인증(SW프로세스품질인증)

SW기업의 SW개발 프로세스 품질역량 수준을 심사하여 등급을 판정하는 제도입니다.
SW프로세스 품질인증(‘SP인증’)제도는 SW산업진흥법 제23조에 근거하여 국내SW기업의 SW사업 수행능력을 강화하고 SW사업의 부실방지를 목적으로 기업의 SW개발단계별 작업절차 및 산출물 관리 역량 등을 분석하여 SW개발 프로세스 역량수준을 평가·인증하는 제도입니다.

① 미래창조과학부(정책기관)
- SW프로세스 품질인증제도 관련 정책 수립, 인증기준 및 인증지침 고시 등

② 정보통신산업진흥원(인증기관)
- SW프로세스 품질인증 업무 전반을 주관
(인증심사 신청 접수부터 인증 사후관리까지)
- 인증심의회 운영
- 인증심사원을 통한 인증심사 실시

③ SW기업(인증신청인)
- SW프로세스 품질인증 신청
- 인증획득 후 인증표시에 대한 활용

자세히 보기 →

2015년 7월 3일 금요일

공학기술개발

공학기술개발 사업은 융합SW산업환경에서 필요한 SW공학요소기술을 대학과 공동으로 연구개발하고 해당 도메인 전문인력을 양성하며, 연구개발된 기술을 국내 실정에 맞게 산업현장 적용 및 확산을 통해 융합SW핵심요소기술을 확보하기 위한 사업입니다.

NIPA SW공학센터는 기업수요과 기술공급의 균형 발전을 촉진하기 위한 체계를 마련하고, 융합SW의 핵심 요소기술을 대학 연구센터를 통해 연구개발하고, 기업현장에 적용하기 위한 산학협력사업을 수행하고 있습니다.


SW공학현장멘토링

SW공학 현장멘토링 사업은 국내 중소/중견 기업의 열악한 SW공학기술 도입환경을 극복하고, 지속적인 개선을 통한 국내기업의 SW경쟁력강화를 목적으로, 다년간의 현장적용 수행사례를 토대로 공학센터의 전문가가 직접 현장에서 지원하는 현장맞춤형의 무료 멘토링 제공 사업입니다.

SW공학센터의 전문가가 직접 현장에서 지원합니다.
 - 통합되어 연결성을 가지는 전체 프로세스
 - 하나의 큰 특징을 가지는 과정 [Phase]
 - 과정별 세부 내용을 나타내는 단계 [Step]
 - 단계별 실행 지침을 포함하는 활동 [Activity]
 - 활동별 특수하게 진행되는 작업 [Task]

자세히 보기 →

SW프로슈머 지원

SW프로슈머 사업은 일반 및 전문평가단을 통해 창업·중소기업 SW제품의 결함 사전 검출 및 개선지원을 제공함으로써 제품의 품질을 향상시키고 성공적인 시장 연착륙을 지원하기 위한 사업입니다.

SW프로슈머란?
SW분야에 전문성을 지닌 개인이 SW제품의 개발 · 개선과정에 참여하여 실패 위험성 요인 중 하나인 품질 문제 극복을 지원하는 사용자입니다.


자세히 보기 →

2015년 7월 2일 목요일

2015년 글로벌 SW개발역량 혁신 프로그램 참가자 모집

SW개발에 대한 열정을 가진 국내 SW엔지니어들을 대상으로, 美실리콘밸리의 최신 기술 동향, 개발 프로세스 경험을 제공하여 SW엔지니어들의 개발역량 혁신 및 기술 개발 경험 사례를 전파합니다.

  • SW개발에 대한 열정을 가진 SW개발자를 대상으로 SW기술과 개발방법론에 대한 현장 중심적 경험을 제공하는 글로벌 SW개발역량 혁신을 위해 'SAVE 프로그램' 운영

  • 신기술 활용 및 개발프로세스 개선으로 SW개발역량 혁신글로벌 SW개발문화 전파 촉진
 

알기 쉬운 SW공학배우기_7화

SW개발 프로젝트에 필요한 산출물 관련 문서
  • 요구사항 명세서
  • 요구사항 추적표
  • 테스트 시나리오
  • 테스트 결과ㅏ서



SW에 내재된 위험, Technical Debt는 얼마나 되고, 왜 발생하는가?

눈에보이지않는 SW, SW비가시성 때문에 반드시Technical Debt를 만나게 됩니다

또 한가지 중요한 사실은 기술부채가 시장의 변화속도에 맞추기 위한 노력의 부산물이기도 하다는 것입니다. 

SW제품은 사실상 창조되어서 시장에 유통되기 전에는 개념조차 없던 제품들이 대부분입니다. 예를 들어 몇십년 전만해도 지금과 같은 ERP시장은 존재하지 않았습니다. 또한 J2EE에서 없어서는 안 될 Application Framework만 해도Framework를 구성하는 컴포넌트나 라이브러리 하나 하나 전부 새로 표준화와 합의를 통해 만들어 진 것입니다. 원래는 없었거나 있었더라도 각자 자기들의 방식으로 사용하던 것들인 반면, 다른 산업은 제품이 만들어지는 과정이SW산업에 비해 상당히 길고 장기적이며, 시장에서 고객들이 먼저 제품의 기능을 결정하고 난 후에 제품이 출시되는 특징이 있다. 이러한 분명한 차이 때문에 SW제품은 제품 출시 이후에도 명확한 제품의 포지셔닝을 하지 못하고 애매한 영역에 걸쳐 영업을 함으로써 치명적인 Technical Debt를 내재하고 있는 경우가 많습니다. 이러한 기술부채는 미처 채우지 못한 품질의 부족함을 넘어서는 경우가 많습니다. 

SW는 다른 산업의 제품들과 다르게 사용자의 명확한 제품에 대한 이해가 있기 전에 출시되는 경우가 많습니다. 때문에 아래에서와 같이 최근에 SW기업들은 대부분 제품 출시 전에 먼저 고객층을 찾아서 확보하고 고객의 피드백을 시장출시 전부터 적극적으로 제품 요구사항에 반영하는 유연생산(Lean Product Development)방식을 도입하고 있습니다.