2016년 9월 30일 금요일

SW 개발도구 비교

SW 개발도구란?


SW 개발과정 (Software Development Life Cycle) 전체에 걸쳐서 사용되는 도구 (tool)를 쉽게 사용할 수 있도록 도구 활용가이드, 동영상 및 연계사례를 제공합니다.


프로젝트관리도구 비교

프로젝트 관리 도구
프로젝트 관리 도구는 범위 관리, 일정 관리, 예산 관리, 의사 소통, 계획 관리, 공정 관, 자원 관리 등 프로젝트를 관리하는 활동을 편리하게 할 수 있게 해준다.

도구 개요
레드마인이미지 Gantt project 이미지   Open Proj 이미지  


주요기능
  일감 관리( 등록, 변경, 추적, 통보 등)
  문서관리, 파일관리, 위키 사이트 구축 
  이메일 통보

장점
  간략한 일정관리 가능 
  웹서버를 이용하여 다수의 인원이 협업할 수 있음 
  프로젝트, 사용자 권한 등을 관리할 수 있음 
  일감의 진행에 따른 이메일 통보 가능

단점
  자원의 투입율을 관리할 수 없음 
  휴일이나 일단위 작업시간을 설정할 수 없음 
  Critical Path 식별을 위한 선후행 작업의 조건설정이 불가함



SW 개발 산출물 작성 가이드

SW 개발 산출물 작성 가이드란?

SW 개발 산출물 작성 가이드는 SW 개발 단계에서 나오는 산출물 중 프로젝트 계획서, 위험관리 계획서 및 위험관리 문서, 요구사항 관리문서, SW 설계문서, 테스트 계획서 및 결과서, 동료검토 계획서 및 결과서에 대해서 작성법 및 실사례를 설명합니다.


    

SP인증 성공사례 - (주)윈스

윈스는 2003년 코스닥에 상장된 정보보안 전문기업으로 침입방지시스템(IPS), DDoS, APT방어 시스템, 통합위협관리(UTM), 방화벽등의 핵심 솔루션을 제공하고 있으며, 침입방지시스템(IPS)과DDoS 차단시스템에서 국내 시장점유율 1위를 차지하고 있는 네트워크 보안 분야에서 기술과 시장을 선도하고 있는 기업입니다.




네트워크 보안에 대한 관심도 및 시장 규모증가사이버 공격으로 인하여 언론사, 금융사 등의 시스템이 제대로 동작하지 않는 상황이 발생했으며 그로인해 다양한 피해가 야기되었으며, 철저하게 관리되어야 하는 고객의 개인정보가 의도치 않게유출되어 보이스피싱 범죄 등 부적절한 방법으로 사용되는 문제가
증가하였다. 네트워크 보안과 관련된 사회적 이슈가 증가하면서 네트워크 보안에 대한 관심도가 급증하였으며, 이로 인한 시장 규모도 급성장하게 되었다.

우리만의 품질체계 필요성 - 경험은 중요하지만 문제 또한 유발시킬 수 있다

품질에 대한 중요성을 이해하게 되면서 품질문제를 유발시킬 수 있는 가장 큰 원인을 찾아보기로 하였다. 경험은 무조건적으로 품질향상에 도움이 된다고 생각하고 있었다. 하지만 경험에는 좋은 경험과 좋지 못한 경험이 존재한다. 경험이 도움이 된다는 것은 좋은경험은 살리고 좋지 못한 경험은 앞으로 좋은 경험이 될 수 있도록개선한다는 전제일 경우를 의미할 것이다.

개발자들은 경험을 통해 개발에 대한 방법을 이해하게 된다. 우리의 고참 개발자들은 좋은 기술력과 경험을 보유하고 있다고 생각하고 있다. 하지만 모든 조직원은 서로 다른 기술력과 경험을 가지고있으며, 제품 개발은 고참 개발자만으로는 이루어질 수 없다. 또한대부분의 개발자는 중급 이하일 경우도 존재한다. 이럴 경우 고참개발자가 경험을 통해 머릿속으로 알고 있는 방식을 초급 중급 개발자가 따라갈 수 있다고 생각했던 것이 첫 번째 오류였던 것 같다.

더보기          

2016년 9월 29일 목요일

SP인증 성공사례 - ㈜포시에스


포시에스는 1995년 설립되어 전자문서 개발, 엔터프라이즈 리포팅,BI리포팅 및 분석 등의 솔루션 제품에 대한 자체 기술력을 보유한업체로 전체 산업분야의 3,000여 고객사를 확보하여 국내 시장점유율 1위를 차지하고 있는 기업입니다.



조직 성장과 더불어 증가하는 납기일 미준수와 제품 결함

시장에서의 인지도 상승과 개발하는 솔루션 제품의 시장점유율이높아짐에 따라 사업규모가 커지고 그에 따라 조직의 규모도 커지게되었다. 시장 경쟁력의 향상은 매출액 증가와 조직규모 증가로 연결되었으나 반대로 기존 조직원의 이탈과 신규 조직원 유입이 반복적으로 발생하는 현상이 같이 나타났다. 조직규모의 증가와 기존조직원의 이탈 그리고 신규 조직원의 유입은 생각하지 못했던 문제를 유발하였다. 조직규모가 커지기 전까지는 개발팀 내부의 의사소통이 원활하여 조직 내 상호협력관계가 유기적으로 움직였으나, 조직이 커지고 조직원이 변동되면서 조직 내 의사소통은 점점 어려워졌으며, 조직의 역량이 몇몇 개개인 역량에 의존하는 현상이 발생하게 되었다. 또한 역량이 뛰어난 조직원의 경험과 지식이 다른 조직원의 역량 향상으로 연결하기에는 조직 자체의 자산과 체계가 부족한 상황이었다.

또한 기업 환경 변화로 인해 솔루션 제품의 개발 주기는 점점 더짧아지게 되었고, 사업의 증가는 개발 업무량 증가로 이어져 개발자의 업무부하가 증가하여 야근으로 이어지는 업무 환경은 조직원의 불만으로 이어지게 되었다.

이러한 복합적인 상황들은 개발업무 지연으로 연결되었으며, 개발자간 원활한 소통을 방해하는 요인이 되어 결함을 유발시키는 원인으로 작용하였다. 증가한 결함은 개발자의 업무 증가로 연결되어업무 지연을 다시 유발하는 악순환이 반복되었다.


조직을 객관적으로 바라보는 것에서 혁신을 시작하다.

제품개발 프로젝트 납기 미준수 증가와 제품 품질저하 등의 문제로 고객의 제품 신뢰도 저하와 시장 경쟁력 약화 가능성에 대한 우려와 위기감이 조직 내 심각하게 제기되면서 이에 대한 시급한 해결이 이뤄져야 한다는 것에 조직원 대부분이 공감하게 되었다.


자세히 보기         

SP인증 성공사례 - (주)심네트


심네트는 1999년 설립된 기업으로 실전 전투경험을 위한 훈련용모델과 기능 분야별 작전요소 분석을 위한 분석용 모델 등의 M&S시스템, 가상훈련 시뮬레이터와 CBT(Computor Based Training)장비, 각종 전장정보의 디지털 데이터화 분석을 통해 실시간 지휘통제 능력을 제공하는 BMS(Battle Management System) 장비를개발하고 선도하고 있는 전문 기업입니다.



고객의 변화 - 고객의 품질 인식변화로 사업의 상황이 바뀌다.

국방 도메인 특성 상 다른 도메인에 비하여 과거부터 품질에 대한요구는 매우 엄격하였다. 과거의 사업과정에서는 결과적인 제품의품질 요구는 매우 엄격하였던 반면 개발과 관리 과정에 대해서는고객과 우리 모두 별다른 관심을 기울이지는 않았었다. 하지만 제품의 품질이 개발과 관리 활동의 과정에 대한 품질로부터 시작한다는 인식의 확대로 개발과 관리에 대한 과정 즉 프로세스에 대한 품질 요구가 강화되고 있는 조짐이 보이기 시작하였다.

그러한 조짐 이후 우려했던 결과가 나타났다. 무기체계 SW연구개발 사업에서 SW프로세스 품질인증 제도를 도입하여 연구개발사업자 선정 시 SP인증 획득 업체에게 인센티브를 부여하고 나아가 국내 업계의 SW 품질향상 공감대 유도한다는 방침이 발표된 것이었다. 하지만 기술력과 제품에 대한 자신감은 있었지만 프로세스를 통한체계적인 개발에 대해서는 아무런 준비와 역량을 보유하지 못했던것이었다. 프로세스 품질역량이 사업에 영향을 주는 요소라고는 전혀 생각하지도 못했기에 전 조직원은 당황할 수 밖에 없었다.


자세히 보기         

SP인증 성공사례 - (주)와이즈넛


와이즈넛은 2000년 설립이후 15년 동안 자연어 분석기술, 텍스트마이닝 기술, 언어 처리기술, 문장 의미 분석기술 등의 핵심 기반기술을 자체 개발하였으며, 현재 인공지능 기반 빅데이터 분석(Machine Learning, Context Aware, NLP 등)과 빅데이터 수집 및 검색(대용량 검색, 표절검색 등) 솔루션을 국내 2,200여 고객사와 미국, 중국, 일본 등 세계 9개국에 공급하는 등 국내외에서제품의 우수성과 기술력을 인정받은 기업입니다.



제품 품질이슈와 개발일정 지연은 왜 증가하고 있는 것일까?

개발되는 솔루션을 점차 늘리면서 그에 따라 조직 규모 또한 증가하게 되었다. 제품과 조직규모가 증가하면서 기존에는 나타나지 않았던 품질이슈가 증가하고 제품 개발에 대한 일정 지연이 증가하는현상이 나타났다. 기존에는 드물게 발생했던 현상이 일상적으로 발생하는 현상으로 바뀌면서 처음에는 그 이유를 알지 못해 무척이나 당혹스러워 했던 기억이 난다.


성공 Tip
- 조직 규모가 증가하면 기존의 개발방식은 반드시 바뀌어야만 한다.
- 조직원의 인식을 먼저 개선하기 위한 방안을 마련해라.
- 아무리 좋은 체계라도 조직원이 경험하여야만 한다.
- SP인증은 종착점이 아닌 지속적 개선의 출발점이다.
- 도구 적용을 통해 프로세스 이행 효율을 증가시킬 수 있다.


자세히 보기       

2016년 9월 28일 수요일

패키지 SW 도입 사전검증 체크리스트 항목별 고려사항 및 사례

체크리스트

패키지 소프트웨어 도입 또는 개발(SI)를 결정해야 하는 경우에, 우선적으로 정보시스템을 발주하는 조직 및 기관의 특수성, 수행하는 업무의 복잡성 등의 조건에 대해서 검토를 실시해야 한다. 조직의 특성한 특수한 업무를 수행할 경우에는, 이를 지원하는 패키지 소프트웨어가 존재하지 않을 가능성이 높다.

또한, 수행하는 업무의 복잡성이 높은 조직의 경우에는 기존의 패키지 소프트웨어가 적합하지 않거나, 패키지 소프트웨어의 많은 부분을 수정해야 하거나, 조직에 맞게 커스터마이징을 하는데 시간과 비용이 많이 소요될 수도 있으므로, 조직의 특수성과 업무의 복잡성에 따라 별도로 맞춤형 설계가 필요한지에 대해서 면밀하게 사전검토를 실시해야 한다.

점검 시 고려사항

발주기관에서 추진하는 사업의 목적 및 범위가 다른 발주기관 및 조직과 비교하여 차별화된 특수성을 가지고 있으며, 패키지 소프트웨어에서 제공하는 표준화된 기능및 프로세스만으로는 발주기관의 독특한 업무 프로세스를 구현하는 것이 어려울 경우에는 패키지 소프트웨어의 도입 보다는 개발(SI)이 적합하다.

또한, 발주기관에서 새롭게 추진하고자 하는 차별화된 사업을 지원하기 위해서 자체적인 정보시스템을 구축하려고 하거나, 구축할 정보시스템이 특수한 기능적 요구사항을 필요로 할 경우에도 패키지 소프트웨어의 도입보다는 개발(SI)이 적합하다.이러한 경우에는 대부분 적합한 패키지 소프트웨어가 없는 경우가 일반적이다.패키지 소프트웨어는 산업 내에서 검증된 베스트 프랙티스와 프로세스를 기반으로설계하고 코드화하여 개발이 되었으며, 이를 도입하는 기관에 대해서도 표준화된 업무 프로세스의 적용을 가정하고 개발되었기 때문에 특수한 맞춤형 설계가 필요한 경우에는 패키지 소프트웨어의 도입보다는 개발(SI)이 적합하다.

이와 같이, 발주기관의 업무 특수성을 지원할 핵심 기능을 지닌 패키지 소프트웨어가 없는 경우에는 개발하는 것이 적합하지만, 약간의 프로세스 변경 및 기능의 추가로 가능할 경우에는 패키지 소프트웨어의 도입을 고려하는 것이 바람직하다.

관련 사례

인천국제공항의 항공기이동관리시스템(A-CDM)을 구축할 시에 공항이라는 업무의 특수성을 반영하여 패키지 소프트웨어가 아닌 개발(SI)로 진행되었다. 항공기이동관리시스템(Airport Collaboration Decision Making)이란, 항공기 이동에 대한예측능력을 강화하고자 이해관계자인 공항, 항공사, 관제기관, 지상조업사간의 항공기 이동정보를 공유하는 시스템을 의미한다.




패키지 SW 도입 사전검증 체크리스트

<사전검증 체크리스트 개요>

공공 부문 정보시스템을 구축할 시, 발주자들이 패키지 소프트웨어를 도입할지 직접 개발(SI)로 진행할지에 대한 결정을 해야 할 때, 객관적인 판단의 근거로서 발주자들이 활용할 수 있도록 패키지 소프트웨어 사전검증 체크리스트(이하 “사전검증 체크리스트”)를 개발하여 제공하고 있다.

사전검증 체크리스트에는 정보시스템 구축 사업 진행시, 패키지 소프트웨어 도입과새로운 시스템의 개발(SI)과 적용에 있어서 무엇이 보다 더 적합할지를 선택하는데 도움이 되는 질문들이 정리되어 있다. 각각의 질문들은 발주자들이 응답하는 Yes/No의 결과에 따라 패키지 소프트웨어 도입과 개발(SI) 중 보다 더 적합한 사업유형이 제시되어 있다. 발주자는 체크리스트를 통한 점검결과에 따라 자신의 환경에 적합한 사업유형을 확인할 수 있다. 또한, 각각의 사전검증 체크리스트 항목에 대해서 발주자들이 이해하기 쉽도록, 각각의 체크리스트 항목별 고려사항과 사례 등에 제공되고 있다.



SW 테스트 자동화 기술 및 사례 - 3

금융 분야 테스트 자동화 사례

전문 기반 테스트 자동화

• 금융 시스템 아키텍쳐 특징


전문 기반 테스트 자동화

• 전문 기반 시험 자동화 도구 개념도



더보기     

2016년 9월 27일 화요일

상황에 따라 적응하는 보안 구조(Adaptive Security Architecture)의 동향 분석


가트너는 2016년 10대 전략 기술 중 능동형 보안 아키텍처를 발표했다. 능동형 보안 아키텍처는 클라우드 환경에서 높아지는 보안 위협을 자체적으로 파악하여 대응한다. 공격이 있으면 대응하는 전통적인 방식에서 적극적으로 보안을 실행하는 것을 말한다. 유선에서 무선 네트워크로, PC에서 스마트폰으로 점차 사용자 환경이 변해가고, 일괄 서비스에서 클라우드나 마이크로 서비스로 운영 환경이 변해가고 있는 시점에 보안 문제는 시급히 반영해야 할 중요 문제이다. 이번 회에서는 상황에 따라 적응하는 보안 구조인 능동형 보안 아키텍처에 대해 살펴보기로 한다.


능동형 보안 구조의 산업 현황


가트너가 발표한 10대 전략 기술은 크게 3가지로 구분된다. 사용자 관점의 기술, 기계 관점의 기술, 그리고 기술 구조 관점에 대한 기술이다. 능동형 보안 구조는 기술 구조에 관점의 기술로 구분되어 있다(그림1). 구조 관점의 기술에는 보안 아키텍처, 시스템 아키텍처와 더불어 매쉬 구조의 앱과 서비스, 마지막으로 IoT 관련 아키텍처와 플랫폼을 들고 있다. 이 네 가지는 모두 다양한 서비스가 분산되어 서비스되는 것을 나타내는 것으로 분산, 클라우드 환경을 대비한 전략 기술로 구분할 수 있다.


<그림1> 가트너 2016년 10대 전략 기술


출처: 가트너


IoT(Internet of Things)로 다양한 사물이 네트워크로 연결되고, 빅데이터(Big Data)로 많은 정보가 이동하게 되면서 ICT 산업과 소프트웨어의 구조는 점점 복잡해지고 있다. 그리고, ICT를 반영한 디지털 비즈니스가 늘어나면서 보안 문제가 크게 대두되어 개방형 소프트웨어나 클라우드 서비스를 활용하는 기업은 위험에 노출되었다. 이에 대한 대응으로 ICT 관리자는 해커의 공격에 대한 방어와 예방을 준비해야 한다. 전통적인 방법과 시스템에 의존하는 보안과 경계선 방어만 믿고 있다면 큰 오산이다. 해커의 위협을 감지하고 적극적으로 대응해야 한다. 가트너는 어플리케이션(Application)의 자가 보호(self-protection)와 사용자와 기업활동 분석기능은 능동형 보안 아키텍처를 완성하는 데 도움이 될 것이라고 전했다. 어플리케이션 스스로 보호 기능이 장착되면 어플리케이션을 분석하여 보안 대응책을 수립할 필요가 없고, 기업의 비즈니스 활동에 대해 자세히 알고 있으면 보안 문제가 나타나는 곳을 집중해서 체크하면 되기 때문이다.

더보기        

포켓몬고를 성공시킨 증강현실 소프트웨어 분석


얼마 전부터 전 세계에 불어온 포켓몬고의 열풍을 기억할 것이다. 사실, 게임으로써 포켓몬고는 매우 단순한 기능만을 가지고 있지만 아이부터 어른까지 스마트폰을 보면서 포켓몬을 잡으러 다니는 진풍경을 연출했다. 증강현실에 대한 서비스는 이미 오래 전부터 알려져 있었지만 사용자 만족도가 높지 않아 발전이 더딘 것이 사실이었다. 이번 회에서는 증강현실을 이용한 포켓몬고가 성공한 방법과 이유에 대해 Elcies 이철승 대표를 만나 자세한 사항을 들어본다. 

Q: 본격적인 이야기 전에 증강현실에 대해 설명을 부탁드립니다.
증강현실은 물리적으로 존재하는 공간이나 환경에 정보나 특정 요소를 추가하는 기술을 말합니다. 다시 말하면, 사람이 눈으로 볼 수 있는 현실 세계에 가상의 정보나 이미지 같은 것을 겹쳐서 보여주는 것입니다. 현실 세계에 가상의 것을 입히는 것이기 때문에 주된 뼈대는 현실 세계로 봐야 합니다. 현실 세계를 중심으로 두고 관련된 정보나 이미지, 또 다른 가상의 세계를 만들어 입히는 것이지요. 가장 이해하기 쉬운 예가 다들 잘 아시는 만화 드래곤볼에 나오는 스카우터를 생각하면 됩니다. 스포츠 안경을 쓰고 보면, 상대방의 전투력을 볼 수 있도록 표시하는 것이지요(그림1).


<그림1> 가상현실이 반영된 드래곤볼의 스카우터



Q: 만화에서 나오는 것을 예로 드시니 재미있습니다. 영화 아이언맨에 나오는 주인공의 헬멧에 있는 기능도 증강현실로 볼 수 있겠네요?
과장된 얘기이기는 하지만, 증강현실이 소개 된지 한참 됐지만 많이 확산되지 못한 이유가 말씀하신 만화에서 나오는 것이니 ‘재미있네.’ 라는 생각도 한 몫을 했습니다. 물론, 기계적 장치가 못 따라간 이유가 가장 크겠지만 증강현실에 대한 기술 자체를 재미있는 정도로만 인식된 것도 사실입니다. 증강현실과는 조금 다르게, 가상현실은 많이 주목 받았던 것도 사실이고요.

더보기     

솔루션 개발 사례 연구 - IBM


글로벌 솔루션 개발 회사의 특징을 살펴보는 세 번째로 IBM을 살펴보도록 한다. IBM은 1900년도 초에 시작한 아주 오래된 ICT 기업 중 하나이다. 하드웨어 업체로 시작한 IBM은 전세계에서 가장 잘 알려진 ICT 기업으로 성장했고, 컨설팅, 소프트웨어 등 ICT의 거의 모든 분야를 서비스하고 있다. 이번 회에서는 IBM의 사업 분야 중 솔루션 개발에 대한 변화를 몇 가지 분야로 살펴보도록 한다. 획기적인 기술과 기획력으로도 어려움을 겪는 다른 솔루션 개발 회사와 비교해보며 솔루션 개발에 필요한 인사이트를 찾기를 기대한다.

IBM의 사업 분야 변화

IBM은 ICT 트렌드 변화에 가장 적극적으로 대응한 기업으로 알려져 있다. 컴퓨터라는 개념이 전혀 없던 시절에 하드웨어를 만들기 시작했고, 80년대에 들어 퍼스널 컴퓨터(Personal Computer)인 PC 시장에 진출하면서 IBM PC가 전세계 PC의 기준이 되는 계기가 되었다. 이후, 90년대 들어서면서 시스템 통합, 2000년 이후에는 컨설팅 사업 등을 확장하였다. IBM은 끊임없는 사업구조 변화를 통해 성공 스토리를 이어갔던 대표적인 기업이지만 대부분 인수합병을 통한 사업 변화가 이루어져 신기술 개발이나 투자는 인색한 기업으로도 평가되고 있다. 
IBM은 하드웨어를 주력 사업으로 했던 80년대 초 초우량 기업 1위로 선정되었지만 특별한 성장 동력 없이 사업을 이어오다 90년대 초에는 수십 억불의 적자를 내게 되었다. 이러한 위기는 IBM이 ICT 서비스와 솔루션 서비스 중심의 소프트웨어 업체로 변신하는 계기가 되었다. IBM이 컨설팅 분야가 성장한 것도 이 때다. 모든 것을 시장 중심으로 생각하고 고객이 요구사항을 최우선으로 대응한다는 원칙으로 2002년에는 총매출의 45%인 364억 달러를 서비스 부문에서 차지했다.
ICT 서비스 중심 사업은 역할과 프로세스의 중요성을 강조할 수 밖에 없다. 소프트웨어 개발은 물론이고 고객의 요구사항에 맞는 서비스를 제공해야 하기 때문에 체계적인 프로세스와 프로세스를 성실히 수행할 역할이 명확히 정의되고 운용되어야 했다. IBM이 다양한 ICT 회사의 벤치마킹 대상이 된 이유가 바로 여기에 있다. 이러한 경험의 축적은 2000년 전후로 IBM을 컨설팅 부문으로 진출시키는 계기가 되었고 ICT를 적용하기 위한 회사에서는 IBM의 컨설팅을 필요로 했다.
전세계 ICT 컨설팅 부문을 선도했던 IBM은 ICT 서비스 사업의 한계와 요소 기술을 반영한 소프트웨어가 요구되던 2000년 중반 이후 소프트웨어 중심 회사로 다시 변화를 시작하게 된다. 2010년의 소프트웨어 사업 비중은 전체의 44%에 달할 정도로 사업 변화(그림1)를 이루었고, 신기술에 대한 지속적인 연구를 통해 또 다른 변화를 시도하고 있다.

<그림1> 소프트웨어 사업에 집중하는 IBM의 사업 변화

출처: IBM

더보기                   

2016년 9월 26일 월요일

2016년 9월 23일 금요일

GUI 테스트 자동화

• Capture & Replay
- 테스트 수행 자동화
- 사용자의 GUI 를 통한 작업을 기록했다가 재생하는 방식

• GUI 테스트 자동화 기술의 진화
- 1세대 : Capture & replay raw events

• 마우스 클릭 이벤트와 좌표 기록했다가 재생
- 2세대 : Identify UI object

• MFC, Web 등의 object identification 기술 활용
- 3세대 : Identify graphical object

• Image identification and comparison
-> Test script 재사용성을 높이기 위한 다양한 시도


Sikuli(http://www.sikuli.org/)

•Automate anything you see on screen
-Screen 에보이는이미지를부분적으로캡쳐했다가찾는방식
-OpenCV엔진사용
-다양한Script 언어사용(Python, Ruby, JavaScript)


더보기       

SW 테스트자동화 기술및 산업분야별 적용사례

테스트 자동화 기술 개요

• 테스트 자동화의 목적
 - 반복적이고 시간이 오래 걸리는 일을 대신 해 주기
 - 귀찮은 일 덜어주기
• 테스트 자동화 분류 기준
 - 테스트 케이스는 무엇으로부터?
 - 테스트 구동은 어떻게?
• 테스트 자동화 기술
 - 코드 기반 테스트 자동화 기술
• 단위 테스트 자동화
• 커버리지 자동화
 - UI 기반 테스트 자동화 기술
• GUI Capture & replay


코드 기반 테스트 자동화 포인트
- 테스트 데이터 자동 생성
- 테스트 코드 자동 생성
- 테스트 자동 수행
- 테스트 결과 자동 검증



더보기      


모델 기반 개발의 장점과 방법


모델 기반 개발의 장점
-의사소통 원활
  •모델을 사용하므로 모호함이 줄어들고, 일관성이 좋아짐
-복잡성 관리 원활
  •모델링을 통해 복잡한 시스템을 추상화하고 분해하여 관리 가능
-설계 품질 향상
  •시스템에 대한 효율적이고 효과적인 탐구 가능
-재사용성 향상
  •통합된 모델 라이브러리를 구축하게 되어 재사용성 향상

모델 기반 개발 프로세스 적용의 효과
-모델링 가이드라인 / 코딩 가이드라인이 존재
-동일한 도구 및 기술을 적용하여 동일한 절차로 소프트웨어를 개발
-동일 개발 프로세스로 만들어진 산출물
  •누구나 해석/이해 가능, 재사용 가능
-개발 생산성 증대
  •재사용, 자동화에 의해 개발 시간 단축


더보기    

2016년 9월 22일 목요일

구글의 개발팀 구성



구글에는 수많은 소프트웨어 개발자가 있고 자유로운 개발 환경을 제공하고 있어 전세계 개발자의 부러움을 받고 있는 것이 사실이지만 구글에서 개발되는 모든 솔루션을 자체적으로 개발하지는 않는다. 구글에서 솔루션을 확보하는 방법은 크게 두가지로 인수합병과 오픈소스 프로그래밍이다. 트렌드를 앞서가는 신기술을 가진 회사를 가져오지만 인수합병 후에도 회사의 독립성을 지켜주며 개발 의지를 이어 나가도록 해주고, 널리 확산하고자 하는 신기술에 대해서는 오픈소스 프로그래밍으로 공개하여 전세계 개발자들이 참여하도록 유도한다.


<참고: 오픈소스 프로그래밍>

오픈소스 프로젝트는 일반적으로 급여를 받지 않고 미팅이나 정해진 매니저도 없다. 명세서, 혹은 설계서 마저 없다는 것도 전통적인 소프트웨어 개발 프로젝트와는 다른 특징 중의 하나 이다. 오픈소스 프로젝트에 참여하는 팀원은 개발의 순수한 즐거움과 경험치를 올리는 가치 상승을 목표로 하기 때문에 팀원의 흥미만 유발된다면 매우 만족스러운 결과를 얻을 수 있다는 장점이 있다. 오픈소스 프로젝트는 모든 것이 자율적으로 이루어지지만 높은 가치를 가지는 프로젝트는 기술 리딩이 가능한 몇 명의 팀원이 주도적으로 이끌어 가기도 한다. 이러한 리더들을 핵심 그룹(Core group)이라고 불리며, 핵심 그룹은 팀원들이 프로젝트에 공헌하고 있다고 느끼도록 확실한 동기를 지속적으로 부여해야 성공 확률이 높아진다. 최근 프로젝트는 오픈소스를 활용하는 경우가 많다. 일반적인 기업에서도 오픈소스 프로젝트를 통해 검증된 소프트웨어를 만들 수 있는 장점이 있지만 강제성이 없어 실패 확률이 높다는 단점도 있다.


구글은 인수합병이나 자유로운 분위기에서 창의적인 생각을 통해 솔루션 개발의 기획을 만들고, 필요한 경우 이 것을 더 발전시키기 위해 오픈소스 프로그래밍을 주도한다. 오픈소스 프로그래밍은 자신들의 아이디어나 기술이 외부에 오픈 되는 단점이 있지만 단기간에 많은 개발자가 참여할 수 있고 회사 밖의 시각을 반영하여 완성된 솔루션의 실패률을 낮출 수 있다.
구글은 제한된 기능을 제공하는 솔루션뿐만 아니라 앵귤러JS와 같은 웹 어플리케이션 프레임워크(그림9)를 제공하면서 사용자 수준이 아니라 개발자 수준까지 구글의 솔루션을 사용하도록 유도하고 있다. 이러한 유도는 개발자의 개발 환경까지 구글의 범주에 넣어둠으로써 구글 환경에 적합한 솔루션 개발이 자연스럽게 이루어지게 한다.

<그림9> 앵귤러JS 개발자 가이드


출처: https://angular.io/docs/ts/latest/guide/




구글의 솔루션 개발 과정 변화




초기의 구글은 웹 기반 솔루션 위주로 개발이 이루어졌다. 검색 사이트인 google.com이 시작이었으며, 이후 메일과 캘린더 서비스를 제공하며 개인 비서 솔루션을 제공하였고, 웹 드라이브, 유투브를 통해 멀티미디어 서비스, 사진과 버즈, 구글플러스 등을 통해 SNS 서비스를 출시하였다. 이러한 서비스는 당시에 마이크로소프트의 오피스처럼 반드시 구입해서 설치해야 하는 솔루션을 네트워크를 통해 제공하려는 전략을 앞세웠다. 이 외에 윈도우즈에 대항하기 위해 크롬 프로젝트를 통해 별다른 운영체제 없이 크롬 브라우저를 통해 위 서비스가 가능하도록 하는 오픈소스 프로젝트를 주도하기도 했다.


<그림6> 구글의 웹 기반 솔루션


모바일이 보급되면서 구글은 웹 기반으로 동작하던 모든 서비스를 모바일에서도 동작할 수 있게 전략을 수립한다. 모바일 용으로 별도 개발을 하는 것이 아니라 웹과 모바일 구분 없이 동작하게 함으로써 사용자 편의성을 추구한다. 구글의 이러한 노력은 안드로이드 사용자 확산으로 인해 더 체계적으로 구축할 수 있었다.



10년간 구글이 성사한 인수합병

구글은 웹 기반으로 서비스를 하던 것에서 안드로이드 적용으로 인해 모바일로 서비스가 점점 옮겨가는 것을 볼 수 있고, 더 나아가서는 웹과 모바일에서 동시에 사용이 가능한 형태로 솔루션과 서비스를 구성하게 된다. 애플은 독자적인 하드웨어에서 구동 되던 것에서 점차 다양한 디바이스에서 구동 되도록 공통 구성의 폭을 점차 늘려 나간 것을 볼 수 있다.
일반적인 관점으로, 구글의 사업 전략은 인수합병을 통해 사업 범위를 늘려가는 것으로 알려져 있다. 그림3은 구글의 10년 간 인수합병 결과를 나타내고 있고, 최근에는 그 빈도나 규모를 점점 더 늘려 나가고 있다. 이러한 전략은 빠르게 사업을 확장하고 중요 기술에 대한 확보가 편리하다.


<그림3> 10년간 구글이 성사한 인수합병


출처: 신한금융투자


보통의 ICT 인수합병의 경우, 특허나 사업의 합병을 통한 시장의 독점과 시너지 효과를 노리는 경우가 많다. 그런데, 그림4에서 보는 것처럼 구글은 현재의 사업과는 조금 다른, 특이한 인수합병을 하는 경우가 많고, 하드웨어보다는 소프트웨어 위주로 이루어졌다는 것을 확인할 수 있다.


<그림4> 구글 인수합병의 예


출처: 신한금융투자

더보기

2016년 9월 21일 수요일

Process Automation

»개발 프로세스가 존재한다는 것

모델링 가이드라인 / 코딩 가이드라인이 존재한다는 것
동일한 도구로 동일한 기술을 적용하여 동일한 절차로 소프트웨어를 개발한다는 것
동일 개발 프로세스로 만들어진 산출물은
  •누구나 해석/이해 가능
  •누구나 재사용 가능
(자동화 프로그램에 의해) 개발 시간을 단축
협업이 가능

»Systems & Software Process Engineering

Process 언어
 •Machine / Tool Readable Process (SPEM)
Process Engineering 도구
 •프로세스 정의 / 문서화 (Author)
 •프로젝트 특성에 따른 프로세스 조정 (Tailor)
 •Tailored 프로세스 공유 (Publish)
 •개발 진척상황, 산출물 상태, 위험/이슈 보고 (Report)
 •Tailored 프로세스 적용 (Deploy)
 •Tailored 프로세스 수행 측정 (Measure)
 •Tailored 프로세스를 기반으로 한 도구 연동 (Enact)
 •프로세스 수행 측정 결과를 기반으로 한 프로세스 개선 (Improve)



자세히 보기         


소프트웨어 테스트의 투입공수 산정을 위한 준비

불과 얼마 전까지도 소프트웨어 테스트는 개발자의 몫이었다. 소스 코드를 코딩하고 제대로 코딩 되었는지 확인하다 보니 가장 적합한 사람이 개발자였기 때문이다. 소프트웨어 테스트는 SI에서 산출물 테스트도 포함하기 시작하면서 범위가 점점 커져 갔지만 전통적이 테스트에 대한 체계적인 요구사항은 지속적으로 증가했다. 이러한 이유로 테스트 전문화에 대한 관심도가 늘어나고 있다. 이번 회에서는 소프트웨어 테스트의 적정한 투입공수 산정을 위해 필요한 사항이 무엇인지 국제대학교 김성철 교수를 만나 들어보기로 한다.


Q: 본격적인 이야기 전에 소프트웨어 테스트에 대한 간략한 설명을 부탁 드립니다.
소프트웨어 테스트는 전문가가 아니더라도 누구나 알고 있는 소프트웨어 개발의 한 분야입니다. 보통의 소프트웨어 테스트는 그림1과 같이 만들어 놓은 소프트웨어가 오류가 없는지는 확인하는 것입니다. 하지만, 최근의 소프트웨어 테스트는 소프트웨어가 정상적으로 동작하는 것은 당연한 것이고 해당 소프트웨어가 요구사항을 모두 만족 시키는지 확인하는 것입니다(그림1).


<그림1> 소프트웨어 품질 관점의 변화
출처: IBM - 요구사항에 기반한 테스팅


자세히 보기       

솔루션 개발 사례 연구 - Google

구글(Google)은 애플(Apple)과 함께 스마트폰의 발달로 가파르게 성장한 회사이다. 안드로이드 개발 후 애플을 제외한 전세계 스마트폰 제조 회사와 협력 관계를 유지할 정도로 이제 없어서는 안될 규모까지 성장해 있다. 구글이 수많은 글로벌 회사들이 손을 잡으려 하는 회사로 성장한 가장 큰 이유는 검색 서비스로 시작했지만 새로운 ICT 트렌드를 정확히 파악하고 선도해 왔기 때문이다. 이번 회에서는 구글의 솔루션 개발에 대한 관점과 방법에 대해 살펴보기로 한다. 획기적인 기술과 기획력으로도 어려움을 겪는 다른 솔루션 개발 회사와 비교해보며 솔루션 개발에 필요한 인사이트를 찾기를 기대한다.

구글의 사업 분야 변화

그림1은 모바일의 발전으로 인한 ICT 산업의 변화를 나타내고 있다. PC나 전화 등과 같이 한 곳에 비치된 상태로 사용되는 형태가 점점 줄어들고 핸드폰과 같이 들고 다니는 형태가 늘어나고 있다. 이러한 변화를 가능하게 한 것이 바로 디바이스와 네트워크의 변화다. PC나 전화는 네트워크를 이용하기 위해 벽에 있는 유선 네트워크를 사용해야 했고 원하는 기능을 위해서는 디바이스의 크기가 어느 정도 이상이 되어야 했다. 하지만, 무선 네트워크가 나오면서 이동성이 자유로워졌고 이동성을 위해 디바이스 크기는 점점 작게 변화되어 갔다. 네트워크 속도도 유선에 의존하지 않고 무선으로도 감당할 수 있게 되면서 집이나 사무실에서만 가능하던 것들이 모바일로도 가능하게 되었다. 이러한 현상은 모바일 사용자 증가를 이끌었고 그림1에서 보는 것처럼 2014년을 기준으로 웹을 사용하는 데스크탑을 추월하기 시작했다.


<그림1> 모바일 사용자 수치의 변화
출처: Comscore

자세히 보기          

2016년 9월 20일 화요일

Systems & Software Product Line


개요 

SSPL 체계에서의 Software Asset 개발 




MBD Methodology - Software Engineering Process

 MBD Methodology 특성

 Harmony Process + PLUS Process
 Agile
 Incremental
 Model-Based
 High-Quality
 Architecture-Centric
 Requirements-Driven
 Focused on QoS
 Safety- and Reliability-Directed
 Optimized for Real-Time & Embedded System

Software Engineering Process 



모델 기반 개발의 장점과 방법 - 모델 기반 개발의 개념

- 모델링을 통해 시스템 및 소프트웨어에 대한 요구사항 분석, 설계, 검증 및 확인 활동 등을 수행
- 풍부한 시각적 모델을 통해 제품, 제품 라인 및 복합 시스템 등에 대한 설계를 캡처하 고 커뮤니케이션 함




2016년 9월 19일 월요일

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


더보기      

[SW공학 동영상 27화] Java가 C보다 안전한가?



데이비드가 C 코딩 표준을 개발한 후, Java 코딩 표준도 개발하고 보니 Java가 더 안정적인 언어라는 예상과 달리 C 규칙은 100개인데 반해 Java 규칙은 170개가 넘었습니다. 단지 규칙이 더 많다는 이유로 Java가 더 불안한 언어는 아니라는 논쟁의 결론을 얻기 위해 더 심층적인 분석을 시도했습니다.

규칙에는 심각도 미터가 있는데 심각도 수치가 높을수록 보안 규칙의 중요도도 높습니다. 그런데 심각도가 높은 규칙의 수가 C와 Java에서 거의 비슷합니다. 사실 C에는 Java에 없는 종류의 취약점이 많기 때문에 이런 종류의 C 규칙이 Java에서 나타나서는 안 됩니다. 따라서 그 다음에는 심각도가 높은 규칙을 놓고 해당 규칙의 심각도가 높은 이유에 대해 다시 한번 검토했습니다. 심각도가 높은 규칙을 각 언어당 4 범주로 분류했습니다. C에서 가장 비중이 큰 범주는 메모리 변형이었고 Java에서는 내부 권한 상승이었습니다.

C와 Java의 차이점은 Java에는 애플릿과 같은 것들을 보호하기 위해 사용하는 고유의 권한 시스템이 있다는 점입니다. 익숙하거나 신뢰할 수 있는 코드가 없는 컴퓨터에서도 Java 애플릿을 실행할 수 있습니다. Java 애플릿은 Java의 내부 권한 시스템을 통해 보안을 유지합니다. C의 경우에는 내부 권한 시스템이 없습니다. 따라서 C 프로그램을 작성한 사람이 아닌 다른 사람이 해당 프로그램을 실행해도, 그 프로그램은 무엇이든 수행할 수 있습니다.

대부분의 운영체제는 외부 권한 시스템을 제공합니다. 프로그램을 실행하려 하거나 어떤 작업을 실행하려 하면 컴퓨터 팝업 창이 뜨고 암호를 입력하라고 합니다. 윈도우, 리눅스 등의 시스템에는 이러한 권한 시스템이 있지만 이들은 프로그래밍 언어가 아닙니다.

외부 권한 시스템에 대한 규칙은 C와 Java에 모두 적용됩니다. 그러나 C는 그 비중이 아주 작습니다. 이러한 규칙이 특별히 POSIX(Portable Operating System Interface)를 처리하는 C 보안 코딩 표준의 일부라는 이유만으로 이 규칙을 Java에 넣지는 않았습니다. Java의 경우, 내부 권한 시스템에 해당하는 규칙이 가장 큰 부분을 차지합니다.

두 언어 모두 권한 시스템에 대한 규칙을 갖고 있습니다. 이러한 권한 시스템을 무시하고 넘어간다 해도, 또 다른 규칙이 존재하는 두 번째 영역이 존재합니다. 하지만 두번째 영역부터는 심각도가 높은 규칙이 C에 비해 Java에서 갑자기 줄어듭니다. 즉 권한 시스템과 상호작용하는 프로그램을 실행하지 않는다면 권한 시스템 규칙에 대해서는 걱정할 필요가 없다는 뜻입니다. 걱정해야 할 심각도 규칙이 줄어든다는 뜻이지요.

최종 결론은 Java의 내부 권한 시스템을 사용하지 않는다면, 즉, Java 데스크톱 애플리케이션이나 모바일 애플리케이션 또는 애플릿을 실행한다면, 권한 규칙에 대해 걱정할 필요가 없다는 뜻입니다. 또한 심각도가 높은 규칙의 양도 C에서보다 훨씬 줄어든다는 뜻입니다.


2016년도 2차 SW컴퓨팅산업 원천기술개발사업(GCS : Global Creative SW) 신규과제 공고 안내



2016년 9월 13일 화요일

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


더보기       


정량적 SW공학 데이터관리

[ 사업내용 ]

SW공학수준 조사

SW공학수준 조사를 위한 표준측정 지표 개선

- SW기업의 SW공학기술 적용 수준을 파악하기 위해 표준 측정지표 개선을 통한 조사항목 도출
- SW공학수준에 따른 성과를 프로젝트의 성공 수준이 아니라 조직의 성과와 연계할 수 있는 지표 도출

SW공학수준 조사 대상업체 선정

- 전체 응답기업 수 : 국내 SW기업 220개 이상(전년대비 10% 증가)

SW공학수준 조사를 위한 설문조사

- SW기업의 SW공학수준 조사를 위한 설문조사 수행

SW공학수준조사 결과 분석

- 지표를 기반으로 전체/분류별 기업에 대한 설문결과 분석
- 각 지표의 의미 및 다른 지표와의 관계를 정의하고, 결과 분석 시 각 지표 및 문항과의 크로스 분석을 통해 결과분석
- 전체 산업 및 산업군별, 규모별, 인증여부별, 기업환경 등에 대하여 프로세스(Process), 인력(People), 기술(Technology) 각각의 측면에서 SW기업 수준 비교
- SW기업의 SW공학 수준이 실제 프로젝트 수행 시 미치는 연관관계 등을 파악하고, 향후 개선 방안을 도출
- 분류별 조사대상에 대한 현황, 문제점 및 핵심 개선방향 도출


더보기             
      

관련지침개발 - 클라우드 기반 SW개발연구

클라우드 기반 SW개발연구는 중소SW기업 웹서비스 개발자들의 역량 향상을 위해, 클라우드 컴퓨팅 기술의 확산과 보급을 목적으로 개발 기술들과 예제를 소개하고 실습 교육을 통하여 클라우드 환경에서의 웹서비스 개발을 쉽게 따라할 수 있는 가이드를 제공하는 연구입니다.
더보기         

2016년 9월 12일 월요일

품질이나 테스팅에 대한 전문적인 조직 출현 배경

Q. 품질이나 테스팅에 대한 전문적인 조직이 왜 생겨났는지 배경을 말씀해주셨네요. 그렇다면, 해당 인력을 어떻게 투입해야 하는지 말씀해주시죠.

해당 인력을 어느 정도 규모로 투입해야 한다는 것을 정해 놓는 것은 매우 어려운 부분입니다. 개발 프로젝트의 성격과 규모, 형태를 감안해 정해야 하기 때문이죠. 투입되는 인력의 경험이나 지식도 매우 중요한 부분 중에 하나 입니다. 개발 프로젝트에 걸려있는 전체적인 것을 점검해보면서 결정해야 하는 것이지요.


Q. 개발 프로젝트에 따라 다르게 투입하더라도 체크할 수 있는 부분들이 있을 것 같은데요?

맞습니다. 무작정 투입하면 전문 조직이 유지되기 어렵겠지요. 그렇다고 투입 규모를 일정하게 넣을 수도 없고요. 대부분 오랜 경험을 가진 전문가에 의존할 수 밖에 없는데 이것도 전적으로 따르기는 회사의 부담도 생각을 해야겠지요. 그런데, 경험 많은 전문가에 의존하는 방법이 주먹구구식 방법은 아닙니다. 소프트웨어공학에서도 제시하는 공수산정 방식의 중요한 방법 중에 하나 입니다.
방금 말씀드린 것처럼 공수산정을 위해서는 개발 프로젝트의 특성을 잘 파악하는 것도 중요하지만 회사에서 그동안 어떻게 투입했는지 경험치를 축적하는 것이 매우 중요한 포인트입니다. 먼저, 개발 프로젝트의 특성을 파악하는 것부터 하면, 표2와 같이 크게 구분할 수 있는 것부터 정리를 하고, 세부적인 항목으로 구분하면서 정리해 나가도록 해야 합니다. 이 때, 우리 회사와 비슷한 규모나 개발을 하는 다른 회사와 크게 차이가 나지 않도록 되도록 많은 정보를 수집하는 것이 좋습니다.


<표2> SI와 솔루션 개발 프로젝트의 구분



테스트 프로세스에 맞춘 테스트 조직

Q. 다들 테스트 전문화에 대한 필요성은 공감하지만 비용 측면에서 어려움이 있기는 합니다.

비용 적인 문제도 있지만 어느 정도의 기간을 투입하는가 하는 것도 고민거리입니다. 소프트웨어 개발에 필요한 공수 산정은 많은 경험과 연구로 어느 정도 일반화되어 있지만 테스트의 경우는 아직 초기 단계입니다. 대체로 테스팅 프로세스에 맞춰 투입 규모를 산정하는 경우가 많은 것이 사실입니다(그림2).


<그림2> 테스트 프로세스에 맞춘 테스트 조직
출처: 오픈소스컨설팅


그림2는 테스트를 위한 프로세스를 나타내고 있습니다. 프로세스를 바탕으로 테스팅 전문 조직을 구성하여 개발 프로젝트를 지원하게 되는데 테스팅 전문가를 어느 정도 투입할 것인지가 고민거리입니다. 특히, 앞에서 말했던 것처럼 최근에는 테스팅과 함께 품질 전체를 아우르고 있기 때문에 품질에 필요한 의사 결정을 해야 하는 것은 경험이 많은 고직급자, 단순 소프트웨어 오류 테스트는 경험이 적은 저직급자가 하는 경우가 많았습니다. 품질 비용의 경우, 개발 프로젝트에 직접적인 원가가 부가 되는 것은 아니기 때문에 비용에 대한 부담이 있는 것 같습니다. 하지만, 발생된 문제를 해결하기 위한 품질 비용이 경우, 시간이 흐를수록 기하급수적으로 늘어나기 때문에 예방 차원에서 반드시 준비를 해야 합니다(그림3).



소프트웨어 테스트와 품질 관점

Q: 본격적인 이야기 전에 소프트웨어 테스트에 대한 간략한 설명을 부탁 드립니다.
소프트웨어 테스트는 전문가가 아니더라도 누구나 알고 있는 소프트웨어 개발의 한 분야입니다. 보통의 소프트웨어 테스트는 그림1과 같이 만들어 놓은 소프트웨어가 오류가 없는지는 확인하는 것입니다. 하지만, 최근의 소프트웨어 테스트는 소프트웨어가 정상적으로 동작하는 것은 당연한 것이고 해당 소프트웨어가 요구사항을 모두 만족 시키는지 확인하는 것입니다(그림1).


<그림1> 소프트웨어 품질 관점의 변화
출처: IBM - 요구사항에 기반한 테스팅


그림1과 같은 이유로, 수작업으로 주로 이루어지던 테스트가 전문 도구나 기술이 도입되기 시작했고, 이를 운용하는 전문 팀이 구성되기 시작했습니다. 아직 범용적인 테스트 표준화 정도까지는 아니지만 대개의 회사에서는 자체적인 테스트 프로세스나 방법론 정도는 가지게 되었습니다.