2016년 1월 29일 금요일

PRINCE2 모델

PRINCE2 모델은 영국정부(OGC: Office of Government Commerce)에 의해 개발되어 전 세계적으로 사용되고 있는 관리방법론으로 주로 IT분야에서 많이 이용된다. PRINCE2는 다양한 산업계와 기초 환경으로부터 가장 잘 입증된 경험들을 활용하며 문서들에는 항상 템플릿이 제공되고, 명확한 의시결정시기가 있는 것이 특징이다.

PRINCE2는 프로세스 기반의 접근방법을 이용하여 각 프로세스들이 프로젝트 수행동안에 수행되어지는 관리활동을 정의하고 있다. 프로세스는 Starting up a Project(SU), Directing a Project(DP), Initiating a Project(IP), Managing Stage Boundaries(SB), Controlling a Stage(CS), Managing Product Delivery(MP), Closing a Project(CP), Planning(PL)로 구성된다.


프로세스와 별도로 Business Case, Organization Plans, Controls, Management of Risk, Quality, Configuration Management, Change Control이 구성되어 있다. 이들은 프로젝트 관리에 영향을 미치게 되며 이슈를 언제 어떻게 등록하는지에 대한 가이드를 제공하고 있다.

< PRINCE2모델 프레임워크 >
자료 : http://commons.wikimedia.org/wiki/File:PRINCE2_Process_Model

SPICE(Software Process Improvement and Capability dEtermination, ISO15504) 모델

SPICE(Software Process Improvement and Capability dEtermination, ISO15504) 모델은 여러 프로세스 개선모형을 국제표준으로 통합한 ISO(International Standardization Organization)의 SW프로세스 모델이다.

SW 프로세스에 대한 개선 및 능력 측정 기준이기도 하다. 기존 ISO9000-3이 SW분야 특성 및 프로세스적인 명을 개선하지 못해 등장했으며 기존 What만 있고 How가 없는 12207의 단점을 해결하고자 개발되었다.

SPICE는 SW프로세스 전반을 심사하여 조직의 SW개발 프로세스를 개선하고 개발자의 개발능력을 향상시킴으로서 개발위험을 통제하기 위한 목적으로 ISO에서 추진하는 SW품질 표준화심사평가 모형으로 SW프로세스 전반을 심사하고 그 결과에 따른 조직의 프로세스를 개선해 나가는 활동에 대한 표준화 방법이다.

< SPICE모델 단계 및 프레임워크 >
자료 : ISO15504(SPICE : Software Process Improvement Capability Determination)


자료 : http://www.itib.net

CMMI(Capability Maturity Model Integration)

CMMI(Capability Maturity Model Integration)란 미국방성의 요청에 의해 카네기멜론 대학의 SW공학연구소가 개발한 성숙도 평가모델을 기준으로 여러 CMM모델을 포함한 통합모델이다. 국제적 권위를 가진 인증을 통해 회사의 프로세스 및 제품에 대한 신뢰성을 보장하고 CMMI 심사를 통해 부족한 프로세스에 대해 외부검토를 수행하고 개선사항을 도출할 수 있는 모델이다.

< CMMI모델 프레임워크 >
자료 : http://www.dthomas.co.uk


주. Management = Mgt. 자료 : http://www.infotechconsulting.se

2016년 1월 28일 목요일

SW프로세스개선 컨설팅 모델

SW프로세스 개선을 위한 컨설팅 모델은 주로 CMMI, SPICE, PRINCE2 등이 있다. 또한 SP인증모델을 기준으로 프로세스 컨설팅을 추진하기도 한다. SW프로세스 개선 컨설팅을 받는 이유는 해당조직이 보다 이상적인 모습으로 발전하고 보다 안정적인 조직운영과 성공적인 SW개발을 하기 위해서이기 때문이다.

국내에서 가장 활발히 컨설팅을 추진하는 모델은 CMMI로 대기업을 중심으로 컨설팅이 추진·운영되고 있다. SW개발에 있어서 여타의 컨설팅보다도 가장 효율적이고 효과적인 컨설팅은 바로 프로세스 개선 컨설팅이다. SW와 관련된 컨설팅 중 현장에서 선호하는 분야는 테스트, 아키텍쳐, 도구도입 등 직접지원 컨설팅으로 컨설팅 중 또는 직후 단기적인 효과를 누릴 수 있지만 장기적으로 전사적 내재화가 발생하기에는 어려움이 많다. 컨설턴트가 빠지고 나면 경우에 따라 원래 상태로 회복되기도 한다.

SW프로세스개선 컨설팅의 경우 도입 시 많은 이슈와 충돌이 발생하기도 하지만 장기적 이행관점에서 봤을 때 해당 조직의 발전가능성이 가장 높다. 또한, 주먹구구식 개발을 하던 SW기업들이 논리적이고 구조적인 프로세스를 통해 보다 체계적인 개발을 할 수 있게 만들어 주어 조직의 안정성과 발전 가능성을 확보할 수 있는 기반이 되는 것이다. SW프로세스와 관련된 모델들은 다양하지만 다른 모델 또는 표준간의 관계를 통해 유기적으로 연관관계를 맺고 있으며 다양하게 확장되고 있다.

< SW프로세스 표준간 관계도 >

자료 : Adapted from[S.A. Sheard, Evolution of the Frameworks Quagmire. IEEE (Computer, July 2001)


프로젝트 관점에서의 프로세스 컨설팅은 프로젝트를 진행할 때 필요한 방법론을 정의하고 그에 따른 WBS를 작성하고 관리하게 된다. 또한 방법론에서 정의한 각 단계(요구사항, 분석, 설계, 구현, 시험, 배포)에 대한 가이드라인을 제공하고 작성된 산출물에 대해 리뷰와 인스펙션을 주관하며 개발자와 관리자간의 조화로운 커뮤니케이션을 할 수 있도록 지원하기도 한다. 프로젝트의 이해당사자들이 합리적으로 일할 수 있는 기반을 제공하는 것이 바로 프로젝트 관점에서의 프로세스 컨설팅이다.

Sonarqube 가이드

소나큐브(Sonarqube)는 코드품질 검사를 위한 공개 소프트웨어 플랫폼이다.
  • JAVA , C/C++ , Objective-C , C# , PHP , COBOL 등을 지원한다 (일부 언어는 상업용).
  • 중복코드 , 코딩 스탠다드 , 유닛테스트 , 코드 커버리지, 코드 복잡도, 잠재적 버그, 주석, 설계, 아키텍처에 대한 보고서를 생성한다.
  • 수치 통계를 저장하고 그래프를 제공한다.



Jenkins 가이드

젠킨스 (Jenkins)는 지속 빌드 및 배포 공개 소프트웨어 시스템이다. 소프트웨어 프로젝트를 지속적으 로 빌드 및 테스트 하도록 해주는 자동화 도구이며, 배포에 필요한 프로세스를 통합하여 제공한다.


  • 빌드 프로젝트의 구성, 관리
  • 프로젝트의 구축, 테스트, 배포 및 자동화를 지원하는 다양한 플러그인과 연동 제공
  • Linux , Windows OS 지원
  • war 파일로 간단하게 배포 및 간편한 Web GUI 제공

Jenkins 가이드를 목차를 확인하고 관련 자료를 다운받을 수 있다.
  1. 설치
  2. 기본 설정
  3. 플러그인 설정: gcov , cppcheck , xUnit, NSIQ , Sonarqube

2016년 1월 27일 수요일

SW 테스트 전략

품질은 결코 우연으로 얻어질 수 있는 결과가 아니다. 많은 노력과 공수, 지식의 축적과 스킬들의 집합체다. 높은 품질은 표준과 SW 프로세스, 철학과 의지의 결과물이기도 하다. 지속되는 개발은 소스코드 분석과 위험 기반의 테스트, 커버리지 측정에 따른 자동화 모듈, 통합테스트를 통해 얻게 된다.

애자일 등 오늘날의 SW개발은 점점 더 방법론 기반의 개발에 의존하고 있는 상황이다. 결과물은 품질보증의 새로운 도전에서 비롯된다. 고품질 제품은 역동적인 목표의 정의와 짧은 개발 사이클을 통해 만들어 지고 지속적인 테스트와 고객의 피드백을 통해 성공의 포인트를 확인할 수 있다.

애자일 방법론의 경우 테스트 가능한 SW는 단계이전에 반드시 수행도록 권고하고 있다. 이러한 지원을 통해 좀 더 낳은 통합 테스트를 프로세스 단계에 포함시킬 수 있게 되는 것이다. 납기가 충분하지 않을 경우 고객의 요구사항을 만족시키기 위해 고객과의 피드백 프로세스와 팀 능력을 통해 이를 해결하기도 한다.


< SW Quality 5seps to excellence >
자료 : Quality is never an Accident, ’13. 3


테스트 전략은 단기 및 장기 테스트 요구사항 및 비즈니스 위험을 프로파일링 하고 개발자와 리소스 등의 환경 요소와 조직적 요구를 포함하는 테스트 전략을 개발하고 다양한 관점에서 평가할 수 있도록 수립해야 한다.

< SW테스트 관점별 전략 개발 요소 >


웹기반 테스트 전략은 일반적으로 코드인스펙션, 유닛 테스트, 통합테스트, 시스템 테스트 등이 수행되며 각각의 테스트 기법들은 설계, 코딩, 품질보증, 제품의 관점에서 시행된다.

< 단계별 결함 해결 비용 >


애자일 테스트 전략의 경우 애자일 방법론과 프로젝트에서 주어진 다양한 상황에 맞추어 테스트를 추진해야 한다.

< 애자일 생명주기에서의 테스팅 전략 >


자료 : Scott W. Ambler, 2006-2009


< 애자일 결함관리 프로세스 >

자료 : Scott W. Ambler, 2006-2009


< 애자일 개발과정에서 테스트 비용과의 관계 >
자료 : Scott W. Ambler, 2006-2009

SW 품질보증

SW품질보증은 SW가 이미 정의된 요구사항과 일치하는가를 확인하는데 필요한 전반적인 계획과 체계적인 작업을 의미한다. SW품질보증 활동은 SW개발 초기에 SW의 특성과 요구사항을 파악하여 품질목표를 설정하고 개발단계에서는 정형기술 검토를 통하여 품질 목표의 충족 여부를 체크하고 테스트 과정을 거치게 된다.

대부분의 SW품질보증 활동은 테스트 계획, 절차, 범위, 방식, 방법 등에 대한 활동이 전부였다고 해도 과언이 아니다. 이러한 테스트 중심의 품질보증활동들은 SW개발 과정중 품질을 제한적으로만 확인할 수 있어 SW개발 과정 중에 품질을 추가하거나 강화하는데 여의치 않았던 것은 사실이다.

SW의 품질보증 활동은 최종결과물의 테스트나 확인을 통해서 수행되는 것이 아니라 SW개발 전단계에 적용해야 한다. 물론 SW의 결함을 제거하고 해결하는 일이 SW의 품질보증을 위해서 중요한 일이지만 이보다 중요한 것은 사전에 결함이 발생되지 않도록 예방하는 활동을 의미한다.

SW품질보증 활동은 조직의 목표와 특성이 반영되어야 한다. SW개발을 추진하는 조직은 SW를 이용하는 조직보다 설계와 테스트과정에 더 많은 공수를 투입해야 하며 SW를 활용하는 조직은 형상관리 및 코드관리, 시험기준 및 획득활동에 더 많은 노력을 해야 한다. SW품질보증의 본질은 결함을 사전에 방지, 제거를 통해 SW의 사용성과 유지보수성을 높이는데 있다.

SW품질 판단기준은 SW품질보증 프로세스와 활동에 따라 결정되며 품질목표가 없는 프로세스는 품질을 확보하기 어렵다. SW품질목표를 설정하기 위해서는 필요에 따라 리스크분석을 활용하여 리스크와 영향도의 관계에 따라 품질보증 항목을 결정하고 활동들을 정의하기도 한다. SW품질목표는 정의를 통해 측정가능하게 도출한 후 추진해야 한다. 품질의 측정은 크게 비용관점과 요구사항 적합성 관점에서 접근하게 된다.

SW비용측면의 관점은 예방비용, 평가비용, 실패비용으로 정의하여 도출하고 개발 전부터 고려하여 목표를 설정해야 한다. 예방비용의 경우 컨설팅 비용이나 계획수립비용, 방법론 도출비용, DB 계획수립, 표준과 요구사항의 정의 등을 포함하며 평가비용은 테스트 계획 수립, 테스트, 검토, 리뷰 등을 포함한다. 실패비용은 프로젝트 재작업 및 클레임, 유지보수 추가 작업 등을 포함하여 고려하여야 한다.

요구사항적합성 관점은 정의된 요구사항이 제대로 반영되었는지에 대한 부분으로 Correctness, Reliability, Efficiency, Integrity, Reusability, Usability, Maintainability, Testability, Potability, Inter-operability, Flexibility, Survivability 등 SW품질요소를 고려하여 추진하며 SW품질기준과의 조율을 통해 산출물의 품질을 확보하도록 추진하여야 한다.

< SW품질요소와 SW품질기준과의 관계 >

SW 품질비용

품질이란 경영자의 마인드 또는 잘못된 판단에 따라서도 좌우되고, 총무나 회계직원의 말 한마디에 의해서도 좌우된다. 구매되는 부품의 품질과 교육 주관부서에서의 교육계획, 그리고 설계 컨셉과 잘못된 설계서 등에서도 품질의 차이는 발생할 수 있다. 즉 품질의 70% 이상은 개발이 아닌 설계나 기타 부문에서 좌우된다는 것이다. 그렇기 때문에 전사적 활동이 되지 않는다면 품질을 확보할 수 없게 되는 것이다.

비용의 의미로 COPQ(Cost of Poor Quality)라는 단어를 제창하였던 QC 선구자 Juran 박사에 따르면 품질비용에서 실제 드러나 보이는 비용은 일부분이며 보이지 않는 부분(Hidden factor)인 숨겨진 품질비용 즉 기회손실비용을 찾아내 분석하고 줄이는 활동에 따라서 품질비용을 효과적으로 관리할 수 있다고 한다.

품질비용이라면 무조건 줄이려고만 하는 것은 위험한 생각이다. 좋은 SW를 만들려면 설계실수도 없애야 하고, 도구를 사용하고 개발자에 대한 교육비용도 투자해야만 한다. 무조건 줄이는 것이 아니라 예방비용을 적절히 투자하여 향후 발생되는 평가비용과 실패비용을 줄이고 나아가 보이지 않는 부분들도 줄여나가야 한다.

과거 전통적인 관점에서 보면‘품질을 높이려면 비용이 많이 든다’라는 개념이 있었다. 하지만 현대적인 관점에선‘품질을 높이면 비용이 줄어든다’라는 개념으로 바뀌고 있다.
“고객에 납품하는 제품에 결함이 없고, 조직 내에 특별한 품질활동이 없다면 품질비용은 사라질 것이다.”(Frank M Gryna) 바로 이 말의 의미인 것이다.

SW예산삭감은 비즈니스 분석가와 테스팅 그룹을 대상으로 하는 경우가 많다. 이러한 환경은 품질결과에 위험이 된다. SW개발 산출물이나 전사전반에 영향을 미치는 품질비용은 SW와 고객을 대상으로 한 예방비용임에도 불구하고 단순히 비용측면에서 접근하여 이를 이행하려고 한다.

SW조직이 프로젝트 품질을 높이기 위해 일정과 예산을 관리하는 것과 더불어 품질비용의 투입은 겉보기에 큰 초기투자로 판단하기 쉽다. 하지만, 적절한 기술, 비즈니스 요구사항이 만족될 수 있도록 지원하는 모든 품질관련 활동, 제어 및 측정을 안내하는 품질계획과 개발자, 효과적인 테스트 전략을 통해 품질을 강화시키고 일정과 예산을 유지할 수 있다.


< SW품질 비용 >

2016년 1월 26일 화요일

핀테크 보안

핀테크에서는 다양한 보안 기능을 추가하고 있지만 대부분은 새로 만드는 것이 아니라 기존의 보안 기술을 활용하는 것이 많다. 이러한 기술의 특징과 장단점을 잘 파악하여 핀테크와 무리 없이 연동되도록 해야 한다.

핀테크는 다른 서비스에 비해 정책적인 제약이 많기 때문에, 보안에 대해 기술적인 접근과 함께 비즈니스적인 접근을 병행해야 기술과 정책을 조화롭게 구성할 수 있다. 핀테크 보안 기술은 하드웨어적인 요소가 많기 때문에 이를 소프트웨어적으로 변환할 수 있는 방안도 필요하다.

핀테크에서 요구되는 세가지 보안 요소

완벽한 보안은 없다. 다만, "정보의 가치"보다 "정보를 해킹하는 비용"이 더 발생하도록 보안을 구축하는 것이 보안의 최종 목적으로 볼 수 있다.

보안의 3요소는 기밀성, 가용성, 무결성(표 1 참조)이다. 철저한 보안을 위해서는 기밀성과 무결성을 높이면 되지만, 이로 인해 가용성은 떨어지게 된다. 세가지 보안 요소에 중요도를 적절히 배분하는 것이 적정 보안을 유지하는 방법이다.

<표 1> 보안의 3요소

핀테크 보안의 3요소는 조금 다르게 정의된다. 효율성, 편의성, 안전성 등 3가지 요소로 볼 수 있다.(표 2 참조). 불과 몇 년 전만해도 금융은 우리나라만 생각하면 되었지만 금융 서비스가 온라인으로 옮겨가면서 글로벌 표준에 대한 인식이 확대 되었다.

<표 2> 핀테크 보안의 3요소

기존의 금융 서비스는 일관된 서비스만 제공하였지만 다양한 디바이스, 시스템과 연계해야 하는 핀테크는 비즈니스 흐름에 따라 소프트웨어를 구성해야 한다. 보안도 비즈니스 관점으로 접근하여 시스템의 효율성을 높일 필요가 있다.

핀테크는 이용자가 다양해지기 때문에 인증에 대한 보안이 강화되어야 한다. 하지만, 최종 사용자(End User)의 디바이스는 모바일처럼 이동성이 강할 수도 있어 편의성도 고려해야 한다. 더 보기 >>>

2016, 소프트웨어 개발 5대 핫 트렌드

2016년에도 IT 운영, 앱 개발, 데이터 관리가 지속적으로 관심 대상이 될 것으로 보인다. 특히 사물인터넷(IoT) 생태계 주도권 경쟁이 심화되고 이를 기반으로 한 디지털 트랜스포메이션 (Digital Transformation)이 가속화될 것으로 전망된다( IDC FutureScape 2016: Korea Top Predictions). 한국CA에서 바라보는 5대 이슈는 사물인터넷, 컨테이너에 의한 개발 가속, 애자일 보안, 애널리틱스 고객 경험, 블록체인이다. 

사물인터넷(IoT)의 애플리케이션 실용화: 사용자 계정처럼 기기에도 계정이 부여되어 인증과 신뢰를 갖게 하는 사물 계정(Identity of Things)이 확산될 것이다. 이를 위해 계정부여와 접근관리(IAM), 기기간 상호작용, IoT간 상호작용을 위한 소프트웨어 개발이 부상할 것이다. 

컨테이너를 통한 개발 가속화: 기업은 컨테이너와 마이크로서비스를 이용해 복잡한 아키텍처와 소프트웨어 개발을 유연하고 손쉽게 그리고 빠르게 진행할 수 있다. 이런 기술은 애플리케이션 개발·구축·업그레이드 방식을 변화시킬 것이고, 다양한 요구사항을 순발력 있게 처리할 수 있는 체계를 갖추게 될 것이다. 

애자일(Agile) 보안: 애자일 방식의 소프트웨어 개발은 증가하고 있고, 이는 시작 단계부터 보안을 고려해야 효과적인 프로젝트를 수행할 수 있음을 의미한다. 여기에는 자주 사용하는 API(Application Programming Interface)에 대한 보안이 강화되면서 신뢰 받는 고객 경험을 이끌어낼 것으로 본다. 

빅데이타와 애널리틱스를 통한 고객 경험 구현: 애널리틱스는 BI(Business Intelligence) 단계에서 최근에는 거래용 데이터와 빅데이터로 발전했다. 고객 경험을 향상 시켜주는 실시간 애널리틱스는 새로운 가치를 창출해줄 것이고 일정한 표준을 제시할 것이다. 특히, ‘1인 가구’ 증가에 따라 기업은 매우 다양한 개인별 맞춤 서비스를 제공해야 한다. 애널리틱스에 의한 의미 있는 인사이트 도출이 필요함을 의미하며 데이터 사이언스 중요성이 높아질 것이다. 

블록체인(Blockchain) 기술: P2P 네트워크을 통한 이중지불 방지에 쓰이던 기술이 바로 블록체인이다. 제3자가 거래를 보증하지 않아도 거래 당사자끼리 가치를 교환할 수 있다는 점이 핀테크와 결부되어 새로운 금융시대를 여는 화두가 되고 있다. 컴퓨터 네트워크 기반으로 하며 프라이버시가 핵심인 블록체인 기술은 고객 대응에서 매우 유연하고 민첩해서 사물인터넷과 결합되어 개인과 기업의 디지털 트랜스포메이션 실현에 매우 중요한 역할을 할 것이다. 

정적 분석과 코드 커버리지에 대한 이해

‘정적 프로그램 분석’ (Static program analysis)은 실제 실행 없이 컴퓨터 소프트웨어를 분석하는 것을 말한다. 다시 말해, 어떤 프로그램을 분석할 때 그 프로그램을 실행시키지 않고 ‘그 자체’를 분석하는 것이라고 해석할 수 있다. 프로그램에 내재한 논리적 오류는 일반적으로 프로그램을 실행하여 확인하지 않으면 찾기가 힘들지만, 정적 분석은 이러한 오류를 찾아내는 데 도움을 줄 수 있다.

대부분의 경우에 분석은 소스 코드의 버전 중 하나의 형태를 가지고 수행되며, 가끔은 최종 바이너리를 가지고 분석한다. 이에 반하여, 프로그램을 실행 하여 분석하는 것을 ‘동적 프로그램 분석’이라고 한다.  

정적 분석은 코드를 실행하지 않고도 모든 프로그램의 구성 요소를 검사하여 다양한 결함을 검출 할 수 있다는 장점이 있다. 또, 테스팅 도구들은 사용자의 적절한 가이드로 중요한 프로그램 구성 요소들을 실행해가면서 그 결과가 예상된 것 인지를 확인할 수 있는 메커니즘을 제공함으로써, 결함들을 검출 할 수 있도록 해준다. 이러한 정적분석이 ‘테스팅을 완전히 대신할 수 있는가’에 대한 의견이 분분한 가운데, 슈어소프트테크의 권민혁파트장을 만나  이에 대한 의견을 들어보았다. 





권민혁 파트장 (슈어소프트테크 시험자동화 연구소)


Q: 요즘 정적 분석기법이 적용된 도구들에 대한 관심이 높아지고 있는데, 이유가 뭘까요?

최근의 소프트웨어 개발 방법론의 흐름을 보면 과거 보다 소프트웨어 정적 분석 기술과 소프트웨어를 동적으로 테스트하는 테스트 자동화 도구에 대한 관심이 높습니다. 현대의 소프트웨어 는 너무나 크고 복잡해서 사람이 직접 프로그램의 모든 동작을 꼼꼼히 확인하기란 매우 어려운 일이기 때문일 텐데요. 소프트웨어의 품질이 중요시되는 경우, 개발자와 품질 관리자는 전문적인 도구들을 필요로 하게 됩니다. 정적 분석 기법이 적용된 도구와 자동화된 테스트 도구들은 이런 요구에 부합하는 도구들이라고 볼 수 있죠.하지만 산업계의 품질과 관련된 다양한 요구만큼, 도구를 도입하거나 사용할 때 발생할 수 있는 오해도 많이 있습니다. 더 읽기

2016년 1월 25일 월요일

SW 설계의 핵심 이슈

SW설계는 크게 아키텍처 설계와 상세설계로 나누어 볼 수 있다. SW아키텍처 설계(Software Architectural Design)는 상위레벨 설계로 일반적은 설계의 개념과 SW 관점에서의 설계의 역할을 이해하고 프로세스를 인지하여 설계의 다양한 접근방법과 개념을 이해할 수 있게 된다. SW상세설계(Software Detailed Design)는 모든 SW설계에서 다루어져야 하는 핵심이슈를 분별하여 효과적으로 설계의 산출물을 작성하는 것이다.

SW설계를 통해 얻을 수 있는 이점은 SW설계에 대한 기본지식의 이해다. 일반적인 설계의 개념과 SW관점에서의 설계역할을 이해하고 그 프로세스를 인지하여 설계의 다양한 접근방법과 개념을 이해할 수 있게 된다.

또한 설계시 다루어져야할 핵심이슈 인식을 위해 모든 SW설계에서 다루어져야 하는 핵심이슈를 분별하여 효과적으로 설계의 산출물을 작성할 수 있게 되는 것이다. 아울러 다양한 관점에서 SW구조와 아키텍처를 고려함으로서 뷰(View)와 아키텍처 스타일, 설계 패턴 그리고 프로그램 계열(Family of Programs)의 다양한 관점에서 설계를 고려하여 설계를 통해 SW품질을 향상시킬 수 있다. 마지막으로 SW설계에 사용되는 표기법 및 전략을 분류하고 선택하여 공유하기 용이하게 된다.


SW설계시 핵심이슈는 병행성, 이벤트의 통제와 처리, 컴포넌트의 분배, 오류/예외처리/장애의 허용 등 아래의 표와 같다.


아키텍처 구조와 관점 중 뷰(View)라는 것은 SW시스템의 특정 특성들을 보여주는 SW아키텍처의 부분적인 면들을 묘사하는 것으로 특정한 뷰는 SW설계와 관련 있는 특정한 이슈와 연관이 있다. 특정한 뷰는 기능적 요구사항을 표현할 수 있는 논리적 뷰(Logical view), Concurrency 이슈를 표현한 프로세스 뷰(Process view), 분배이슈를 표현한 물리적인 뷰(Physical view), 설계의 구현단위를 표현한 개발 뷰(Development view), 행동적(Behavioral) 뷰, 기능적(Functional) 뷰, 구조적(Structural) 뷰, 데이터 모델링(Dat Modeling) 뷰로 나눌 수 있다.


SW설계는 설계 프로세스로 생성되는 다양한 면(Multi-faceted)들을 가진 산출물(Artifact)이며, 각각 비교적 독립적이며 다른 측에서 바라보는(Orthogonal) 뷰로 이루어진다.
SW아키텍처 구조와 관점은 특정 아키텍처에 대한 제약사항(Constraints)의 집합을 의미하며 SW의 상위 레벨의 구성(Macro-architecture)을 규정 지을수 있는 메타모델이다. 주요 아키텍처 스타일은 아래와 같다.


설계패턴(Micro-architecture patterns)은 아키텍처 스타일이 상위레벨 구성을 설명한다.
패턴이란 주어진 상황 속에서 공통된 문제에 대한 공통된 솔루션을 의미하며, 설계 패턴이란 SW의 하위 또는 조금 더 로컬수준에서 세부사항을 설명하는데 사용한다.

주요 설계패턴은 Creational 패턴, Structural 패턴, Behavioral 패턴으로 나눌 수 있다.

프로그램의 계통과 프레임워크(Families of Programs and Frameworks)는 계통의 구성요소 사이의 공통성을 파악하고 다양성(Variability)을 처리한다. 또한 재사용 가능(Reusable)하고 맞춤 가능(Customizable)한 컴포넌트 사용을 통해 이루어진다.

프레임워크는 객체지향 프로그래밍에서 재사용설계에 관련된 핵심 개념으로 특정 플러그인을 적절하게 인스턴스 생성하여 확장할 수 있는 부분적으로 완성된 SW서브시스템을 의미한다.

프레임워크는 비즈니스 프레임워크와 어플리케이션 프레임워크로 나뉘며 비즈니스 프레임워크는 특정 비즈니스 도메인의 지식을 포착하여 재사용 가능한 비즈니스 클래스와 비즈니스 프로세스를 프레임워크 형태로 가공하여 제공한다.

어플리케이션 프레임워크는 어플리케이션 개발과정에 공통으로 사용되는 기술적인 서비스, 패턴, 아키텍처 등을 기반으로 구성하여 제공하는 것을 의미한다. SW설계와 컴포넌트를 재사용할 수 있도록 접근하는 방법은 SW Product-Line의 설계를 의미하기도 한다.

SW설계의 품질분석과 평가(SW Design Quality Analysis and Evaluation)를 위한 품질속성은(Quality Attributes) 목적의 적합성, 유지보수성(Maintainability), 이식성(Portability), 테스트 가능성(Testability), 추적가능성(Traceability), 정확성(Correctness), 강건성(Robustness)을 의미하며, 운영시점에서 관련된 품질속성은 성능(Performance), 보안성(Security), 가용성(Availability), 기능성(Functionality), 사용성(Usability)이 있다. 개발 시점에 관련된 품질속성은 수정가용성(Modifiability),이식성(Portability), 재사용성(Reusability), 통합성(Integrability), 테스트가능성(Testability)이 있다.

또한 아키텍처에 내재된 품질속성은 개념적 무결성(Conceptual Integrity), 정확성(Correctness), 완전성(Completeness), 구축 용이성(Buildability)이 있다.

SW 요구사항과 설계의 적용 방향

요구사항이란 이용자가 어떤 문제를 해결하거나 목표를 달성하기 위해 필요로 하는 조건이나 능력을 의미하며 계약을 수행하거나 표준에 맞추거나 산출물을 만족하기 위해 시스템의 전체 혹은 일부가 갖추어야 하는 조건이나 능력, 요구의 총체를 의미하기도 한다.

이러한 요구사항을 구조적, 이론적, 논리적으로 접근하고 최종산출물에 보다 가깝게 구현할 수 있도록 지원하는 것이 바로 SW요구공학이다. 요구사항의 획득, 분석, 명세, 검증 및 변경관리 등에 대한 제반활동과 원칙, 요구사항 생성 및 관리를 체계적, 반복적으로 수행하고, 요구사항 관리에 포함되는 모든 생명주기활동과 이를 지원하는 프로세스, 시스템 요구사항 문서를 생성, 검증, 관리하기 위하여 수행되는 구조화된 활동의 집합이기도 하다. 아울러 요구사항 명세를 최종 산출물로 생성한다.

< SW요구사항 관련 지식체계 및 국제표준 >


요구공학은 이해관계자 사이에 효과적인 커뮤니케이션 수단을 제공하고 요구사항에 대한 공통 이해를 설정한다. 요구사항에 대한 손실을 방지하고 에러 감지로 불필요한 비용을 절감하고 구조화된 요구사항으로 요구사항 변경 추적을 가능하게 하는 것이다.

요구사항의 개발은 이해관계자와 개발자가 함께 이해관계자의 니즈와 시스템 개발시 제약사항을 발견하여 검토하고 명확화 하는 이해과정인 요구사항 추출단계에서부터 추출된 요구사항을 분석하고 요구사항을 구조화하여 각종 대안들을 결정하는 피드백 역할을 수행하는 분석단계를 지나 분석과정에서 선별된 기능을 기반으로 요구사항을 명세화하고 요구사항의 승인기준(문서화, 명확성, 간결성, 이해성, 시험성, 사용성, 추적성, 검증성 등)을 정의하여 요구사항을 확인하고 검증하는 단계로 이루어져 있다.

요구사항 기법은 가장 전통적인 방식으로 분석과 고객간의 인터뷰 내용을 바탕으로 요구를 추출하는 Interview가 있으나 이해관계자들의 비협조, 애매모호성 단어, 과장, 누락의 위험이 있다. 또한 What과 How에 대한 프레임을 작성하여 고객으로부터의 요구사항에 대한 스토리를 작성하는 시나리오방식이 있다. 유즈케이스가 대표적이며 이해관계자들이 제시하는 프레임을 이해하거나 시나리오를 작성해야 하는 추가 작업이 뒤따른다. 추가적으로 프로토타입(구체적이지 못한 요구사항에 대해 UI 또는 MOCKUP 등을 통해 고객과의 피드백으로 요구추출), Facilitated Meeting(이해관계자들의 모임을 구성하여 브레인스토밍을 통해 요구추출), Obervation(WBS를 통해 각 분석가별 분석대상 업무의 할당, 사용자의 비즈니스 수행, 현행시스템 이용 관찰 등을 통해 요구추출), JAD(PROTO를 통한 고객과 개발자간 밀접한 관계로 서로간 의사소통의 결과를 제시) 등이 있다.

요구사항의 관리기법은 시나리오/Goal 기반 요구사항 획득, 유즈케이스를 이용한 요구사항 모델링, 품질요구사항을 위한 자동분류, 유사도 측정을 이용한 요구사항 변경관리 등이 있다.


Business concern, critical success factor로 불리기도 하는 목표(goal)는 용어적으로 SW에 대한 전반적이고 상위레벨의 목적(objectives)들을 말한다. 목표는 SW에 대한 동기를 부여하지만, 간혹 체계적이지 않은 경우도 있다. SW 엔지니어는 목표의 가치(상대적인 우선순위)와 목표에 드는 비용을 평가하는데 많은 노력을 기울여야 한다.

SW 엔지니어는 어플리케이션 도메인에 대한 지식을 습득하거나 이해할 필요가 있다. 이것은 SW 엔지니어가 이해관계자가 표현하지 않는 암묵적인 지식이나 상충되는 요구사항 간의 필요한 조정을 하거나, 필요시 사용자의 대변자로서의 역할을 수행할 수 있게 한다.

특정 그룹만의 요구사항을 강조하려다 보면 다른 그룹의 요구사항은 희생되어 많은 SW들이 불만족스러운 주요 원인이 되기도 한다. 결국 사용하기 어렵거나 고객 조직의 문화적 또는 정치적 구조를 배제한 SW가 고객에게 인도 되었다면 SW 엔지니어는 다양한 타입의 이해관계자들의 관점을 인지하고 나타나며 다룰 필요가 있다.

요구사항은 SW가 구현되는 환경에서 발생할 수도 있다. 예를 들어 실시간 시스템의 경우 시간의 제약이 발생할 수도 있다. 이러한 제약조건들은 SW 운용성과 비용에 큰 영향을 미칠 수 있으며 계획에 대한 선택을 제한할 수 있기 때문에 반드시 능동적인 노력이 필요하다.

SW는 종종 조직의 문화, 구조, 내부 정책에 따른 선택과 같은 업무프로세스를 지원하기도 한다. 새로운 SW가 업무 프로세스 상에서 계획하지 않은 변화를 강요하지 않아야 함으로 SW 엔지니어는 이런 것에 영향을 받고 신경을 써야할 필요가 있다.

요구사항의 정의에 있어서 이슈가 될 수 있는 것은 기능적 요구사항(Functional Requirement)과 비기능적 요구사항(Non-functional Requirement)의 구분이다. 기능적 요구사항은 고객 요구사항중에 수행될 기능과 관련되어 있는 입력과 출력 및 그들 사이의 처리과정이나 목표로 하는 제품의 구현을 위해 SW가 가져야하는 기능적 속성을 의미한다.

비기능적 요구사항이란 제품의 품질 기준 등을 만족시키기 위해 SW가 가져야 하는 성능(응답시간, 처리량 등), 사용의 용이성, 신뢰도, 보안성, 운용상의 제약, 안정성, 유지보수성 등과 같은 행위적 특성으로 시스템의 기능에 관련되지 않는 요구사항들을 의미한다.

요구사항의 정의는 요구사항 분석단계의 비즈니스 모델링을 통해 수집된 사용자의 기능적 요구사항을 정형화하고 비기능 요구사항에 대해 체계적으로 분류하고 명세화 해야 한다. 또한 구축할 시스템의 범위와 개발 우선순위를 정해야 한다.

요구사항 분석단계에서 가장 중요한 산출물은 요구사항 정의서다. 요구사항 정의서는 프로젝트의 생명주기 내내 사용됨으로 시스템의 목표에 대한 구체적인 내용이 기술되어야 한다. 또한 요구사항 정의서는 사용자와 프로젝트 팀의 중요한 의사소통도구로 사용됨으로 최대한 쉬운 용어로 기술되고 기술된 내용은 서로 합의 되어야 한다.


아울러, SWEBOK(Software Engineering Body of Knowledge)에 따르면 요구사항은 프로세스를 통해 추출되고 분석되어 명세한 후 확인한다고 되어 있다. 기본적으로 요구사항에 대한 정의와 제품과 프로세스에 대한 정의 기능과 비기능의 구분, 창발성 속성(Emergent Properties), 정량화, 시스템 요구사항과 SW요구사항의 분리를 정의한 후 요구사항의 단계를 밟아 나간다.

프로세스단계에서는 모델과 역할을 분배하고 지원과 관리에 대한 부분 그리고 품질 및 향상에 관한부분을 정의한 후 추출과 분석, 명세, 확인 단계를 거치게 되며, 프로세스 반복에 대한 부분이나 변화관리, 속성, 추적, 측정과 관련된 부분은 전체적인 고려사항에 포함시켜 도출해야한다.


SW프로세스 인증제도(이하 SP인증)

우리나라는 SW프로세스의 중요성이 인지되고 확대됨에 따라 정보통신산업진흥원 SW공학센터를 중심으로 한국형 중소기업 대상의 SW프로세스 인증제도(이하 SP인증)를 추진하고 있다.

SP인증은 SW기업과 개발조직을 대상으로 SW개발 프로세스 품질역량 수준을 심사해 등급을 판정하는 제도로 2009년부터 추진되어 왔다. 한국형 SW프로세스품질인증모델은 미국 카네기멜론에서 개발한 CMMI의 25% 비용으로 인증을 받을 수 있지만 영세 SW기업을 대상으로 하기엔 비용부담이 컸던게 사실이다. 심사비용은 저렴하지만 인증 획득을 준비하는 필요한 컨설팅 등 추가적인 비용들이 발생하기 때문이다. 또한 인증 획득율도 69% 수준으로 중소SW기업이 SP인증을 획득하기란 쉽지 않은 일이었다.

< SP인증 획득 기업 수(2013년 9월말 기준) >



2013년부터 정부(정보통신산업진흥원 SW공학센터)에서 인증을 획득한 기업을 대상으로 심사비의 50%를 되돌려 주겠다고 하자 인증 신청기업이 늘어났다. 이는 그동안 심사비용 문제로 SW기업들이 고민을 했다는 방증이기도 하다.

올해부터 SP인증을 기업의 관점이 아닌 발주자의 관점에서 가점을 주기로 결정함에 따라 안전행정부가 기술평가항목에 SP인증 획득여부를 반영했고, 방위사업청이 무기체계 연구개발사업 제안서에 SP인증 기업을 우대한다는 내용을 명시했다.

한국형 SW프로세스품질인증모델은 2006년 개발되어 시범사업을 통해 검증하고 SW산업진흥법 개정을 통해 SW프로세스 품질인증제도로 발전하게 되었다. SW가 타산업과 융복합화되며 보다 복잡해지고 있어 SW품질이 각종 제품이나 서비스의 경쟁력을 좌우하는 핵심요소로 부각되었기 때문이다.

SP인증모델은 프로젝트와 조직의 관점으로 구성되어 국내 SW기업의 환경특성에 적합한 SW프로세스 역량수준의 심사체계를 마련하고 프로세스 기반의 SW프로젝트 완성도 제고에 중점을 두고 있다. SP인증은 SW프로젝트의 효율적인 개발, 관리 능력을 심사(2등급)하고 조직 프로세스 표준화 및 관리, 프로세스 개선능력을 심사(3등급)하는 구조로 구성되어 있다.

< SP인증 등급별 평가요소 >

1등급은 SW프로세스 개선이 필요한 단계, 2등급은 개별 프로젝트를 수행하기 위해 필요한 프로젝트 차원의 프로세스가 수립되고, 이를 기반으로 프로젝트를 통하여 성공적으로 프로젝트를 수행 할 수 있는 역량수준으로 정의되며, 3등급은 조직의 프로세스 체계를 정의하고 정량적인 데이터 관리를 통해 조직 차원의 프로세스를 개선하고 발생되는 문제의 근본원인을 해결함으로써 일관된 품질수준의 프로젝트 수행이 가능하며 지속적으로 프로세스를 개선 할 수 있는 역량수준으로 정의되고 있다.

< SP인증모델 프레임워크 >


< SP인증모델의 주요내용 >

2016년 1월 22일 금요일

회원정보 업데이트 이벤, 1/21(목)~2/15(월)

SW공학이 필요한 근본적인 현상

프로젝트 성공에 대한 고민_SW프로젝트가 항상 요구하는 것은 비용의 증가 없이 적시에 끝나는 것이다. 하지만 현실에선 이 부분을 달성하기 어렵다는 것을 통계나 상황을 통해 인지할 수 있다.

프로젝트가 실패하는 것은 드문 일이 아니기 때문에 예산과 일정이 충족된 경우에도 품질에 대한 궁금증은 남는다. 프로젝트의 성공은 세가지 구성요소(비용, 납기, 품질)를 평가해야 한다. 그렇지 않다면 프로젝트는 실패할 수도 있다.

프로젝트의 실패 이유는 여러 가지가 있지만 원인은 무한할 수도 있다. 80/20법칙(파레토법칙)을 적용할 경우 실패의 가장 일반적인 이유는 아래의 표에서 찾을 수 있다.


프로젝트 관리자는 여러 자원과 관점에서 활동들을 모니터링 해야 하고 그 구성원들도 프로젝트의 성공을 위해 여러 가지 활동들을 추진해야만 한다. 하지만 그들만의 방식으로 또는 경험으로만 프로젝트를 진행시킨다면 프로젝트의 성공을 보장할 수 없게 된다.

웹개발 저널지인 ‘codediesel’에 따르면 SW프로젝트가 실패하는 10가지 이유는

① 불완전한 요구사항
② 불명확한 커뮤니케이션
③ 자원부족
④ 비현실적인 목표
⑤ 요구사항의 변화
⑥ 잘못된 계획
⑦ 엉성한 개발사례
⑧ 형편없는 보고
⑨ 미숙한 기술의 사용
⑩ 출시 압력이라고 한다.

이러한 상황들을 해결할 수 있는 것이 바로 SW공학이다. 물론 기업정책상의 개선 또는 엔지니어의 능력 향상이 표면위로 부상할 수 있지만 프로젝트의 성공적 추진을 위한 전제가 바로 SW공학이다.

개발과정에서의 고민_또한 SW프로젝트를 잘 이끌어 나가기 위해서는 상대 또는 자신과 신뢰가 중요하다. 불신이란 공포와 무지에 뿌리를 두고 있지만 다르게 생각하는 것의 시작이 바로 불신일수도 있다. 이러한 불신을 없애는 방법, SW개발 프로젝트를 추진하기 위한 불신을 상쇄시키고 불신의 단계에서 흐름을 타고 프로젝트를 마무리 할 수 있게 믿음을 주는 바로 그것이 SW공학이 필요한 이유다.


자료 : http://abdulazeem.wordpress.com/2010/02/21/software-developer-life-cycle/

2016년 기업용 소프트웨어에 대한 예측

디지털 시대에 IT의 중심인 소프트웨어는 기업경영에 있어서 매우 중요한 역할을 담당하고 있다. 그렇다면, 기업용 소프트웨어에 대해 전문가들은 어떤 변화를 예측하고 있을까? 기업현장에 있는 전문가와 경영자의 의견은 5가지로 요약되고 있다.

  1. 소프트웨어 기반의 보안 솔루션은 이제 안녕을 고할 것이다. 소프트웨어에 의한 보안 시스템은 2가지 큰 취약성을 드러내고 있다. 우선, 많은 보안 소프트웨어들이 서로 연동되어 작동되기 보다는 독립적으로 움직이다 보니 상호 충돌을 피할 수 없고, 최신 보안 문제에 대해서는 해결 능력이 떨어지는 경향이 있다. 이런 이유로 소프트웨어 정의 보안 솔루션은 변화가 필요하다.
  2. 소프트웨어에 문제가 생기면 이제는 모두의 문제가 된다. 이제 소프트웨어는 CIO, CTO의 문제만으로 귀결되지 않으며, 경영 리더십 전반에 걸친 문제로 이어진다. 즉, CEO를 비롯한 고위 경영진(C-suite: CFO, CMO, COO 등) 모두의 책임으로 이어진다.
  3. 기업의 대규모 프로젝트에서 Agile development transformation이 실현될 것이다. 75%의 기업이(미국의 경우) Agile 방법론을 도입했다고 하지만 그간 규모 있는 프로젝트에서 주시할 만한 성과는 만들어지지 않았다. 2016년은 기업 전반에 영향을 주는 프로젝트에서 Agile 방법론이 적용된 사례를 만날 수 있을 것이다.
  4. 소프트웨어 개발자 수급 부족은 지속될 것이다. Google, Uber, Amazon 같은 기업으로는 SW Engineers가 블랙홀처럼 빨려들어가겠지만, 그렇지 않은 규모의 개발 회사와 Non-IT 부문에서의 소프트웨어 개발 인력 수급은 용이하지 않다. 
  5. 소프트웨어 개발은 Cloud를 향하고 있다. 웹 기반 어플리케이션 부터 소프트웨어 유지보수, 패칭, 업데이트 등 부가가치 사업까지 비용절감과 유집보수 편리성 측면에서 Cloud를 이용하지 않을 이유가 없다. 

이상에서 소프트웨어의 중요성이 기업에서 더욱 커져가는 것을 느낄 수 있다. 그리고, Agile 기반 개발 성숙도의 향상과 함께 우수 소프트웨어 개발 인력의 수급이 필요함을 알 수 있다.

2016년 1월 21일 목요일

SW개발자가 선택할 수 있는 미래의 직군


2016년도 SW컴퓨팅산업원천기술개발사업(GCS:Global Creative SW)



□ 사업목적: 글로벌 Top 수준의 잠재성이 있는 SW전문 중소‧중견기업 주관의  R&D과제를 지원하고 글로벌 시장 성과창출 유도


□ 지원대상 분야: 소프트웨어 관련 전분야


1. 지원내용


  • 과제주제는 SW 관련 전분야로 신청기관이 자유롭게 선택
  • 제출한 사업계획서가 상기 내용(과제별 정부출연금 10억 이하 등)을 만족하지 못하는 경우 접수 취소 또는 사전지원제외 될 수 있음
  • 과제별 지원금액은 연간 10억원 이상(1차년도 신청한도 : 1088)으로 신청 가능하며 평가결과에 따라 지원금액은 조정 될 수 있음. (총 정부출연금 175억원 내외 / 2)
  • 1차년도 사업비예산(88)16년 예산 편성 심의결과에 따라 일부 조정될 수 있음


2. 주관기관과 참여기관의 신청 자격

주관기관 : 중소 ‧ 중견기업


  • 주관기관으로 신청하는 기업은 접수마감일 현재 기업부설연구소 또는 연구전담부서*를 보유(접수마감일 기준)하고 있는 법인사업자이어야 함.
  • 기존 R&D 참여제한 조건 외에 다음 각 항목 중 하나 이상 만족
      • SW관련 최근 3년간 평균 매출액 30억원 이상 또는 수출 3억원 이상
      • SW관련 전년도 매출액 30억원 이상 또는 수출 3억원 이상

    참여기관 : 기업, 대학, 연구기관, 연구조합, 사업자단체 등 관련 규정*에 해당되는 기관

    • 외국 소재 기관(기업, 대학, 연구소 등)의 경우 참여기관으로만 사업 참여 가능함



    Globalization Process Infographics

    글로벌화 프로세스에 대한 개요도를 제시합니다.


    글로벌화(Globalization ,G11n) & Global Test _ Infographics



    현지화(Localization, L10N) Information Design



    현지화(Localization, L10N) Information Design_ SW공학기반상세가이드



    국제화(Internationalization, i18N) Information Design



    자세한 이미지는 포털에서 다운받으시기 바랍니다.

    2016년 1월 20일 수요일

    핀테크 SW기술 투자 동향

    금융 관련 산업 영역에 따라서 핀테크 사업을 4가지 분야로 정리 할 수 있습니다.

    사업영역
    내용
    세부영역
    송금 · 결제
    이용이 간편하면서도 수수료가 저렴한 지급결제 서비스를 제공함으로써 고객의 편의성을 제공 · Infrastructure
     · Online Payment
     · Foreign Exchange
    금융 데이터 분석
    개인 또는 기업 고객과 관련된 다양한 데이터를 수집하여 분석함으로써 새로운 부가가치를 창출
     · Credit Reference
     · Capital Markets
     · Insurance
    금융 소프트웨어
    보다 진화된 스마트기술을 활용하여 기존 방식보다 효율적이고 혁신적인 금융업무 및 서비스 관련 SW 제공
     · Risk Management
     · Asset Managment
     · Accounting
    플랫폼
    전 세계기업과 고객들이 금융기관의 개입 없이 자유롭게 금융거래를 할 수 있는 다양한 거래 기반 제공
     · P2P Lending
     ˙ Trading Platform
     · Personal Finance Management
    자료: 영국투자무역청

    핀테크의 여러 분야가 활발하게 발전하고 있는데, 금융 관련 정책, 서비스 개발, IT 기술 지원의 3박자가 잘 맞아가는 국가와 기업은 무서운 속도로 세계 핀테크 시장을 선점하고 있습니다. 그리고, 투자는 그 속도에 가속을 붙이고 있는데, 우리나라 통계청 자료에 의하면 2013년 1분기 1조 1,270억원 이었던 모바일 결제 시장 규모는 2014년 2분기 3조 1,930억 원으로 집계되어 전년 1분기 대비 283% 성장한 것으로 나타났습니다. 

    시장조사업체 가트너(Gartner)의 모바일 결제 시장에 관한 전망에 따르면, 2015년에 4,311억 달러를, 그리고 2017년에는 4억 5,000만 명이 7,213억 달러 규모의 시장을 만들어 낼 것으로 전망하고 있습니다. 주요 국가별 핀테크 특징과 투자현황 보기 >>>

    핀테크는 내부 뿐만 아니라 외부에서 만들어지는 다양한 금융 서비스를 수시로 추가할 수 있도록 아키텍처를 설계하는 것이 중요

    금융 서비스뿐만 아니고 대부분의 아키텍처 설계에는 강건성이 강조됩니다. 강건성이란, 모델에 여러 가지 변화를 가해도 모델이 계속 비슷한 결과를 산출하는지 나타내는 정도를 말합니다.

    강건성이 낮은 아키텍처의 수정은 오류가 없던 시스템에 회귀 결함을 발생시 킬 수 있기 때문에 외부 요인으로 인한 변경에도 기존에 구성된 아키텍처에는 영향이 없도록 설계해야 합니다.

    핀테크는 내부 뿐만 아니라 외부에서 만들어지는 다양한 금융 서비스를 수시로 추가할 수 있도록 설계하는 것이 중요합니다. 높은 강건성을 위해 기존 금융 시스템에 영향이 없는 독립적이고 확장성이 좋은 핀테크 아키텍처 구성이 필요합니다.

    핀테크 아키텍처 구성


    위 그림을 보면, 핀테크 서비스를 위한 UI와 기존 금융 시스템과 핀테크 사이에 프레임워크가 추가된 것을 발견할 수 있고, 2가지 중요 포인트를 찾아낼 수 있습니다.
    • 외부 핀테크 서비스를 받아들여야 한다.
    • 오픈 프레임워크가 필요하다.


    핀테크 서비스는 다양한 외부 업체의 서비스를 활용해야 하기 때문에 이 부분이 아키텍처에 반드시 포함되어야 하고, 기존 금융 시스템에 영향을 줘서는 안되기 때문에 핀테크 서비스와 기존 금융 시스템을 이어주는 프레임워크가 필요합니다.

    프레임워크는 외부 핀테크 업체도 구성을 알아야 하기 때문에 오픈 프레임워크의 연결자(Broker)역할을 하게 됩니다. 한국은행에서 제시하는 포스트 금융 시스템의 아키텍처를 살펴보면, 외부 비즈니스까지 받아들여 처리되도록 설계되어 있습니다. 더 보기 >>>

    데이터 경쟁력인 시대! 데이터가 돈 되는 시대! 의 데이터 품질관리의 중요성

    우리가 서비스 받고 있는 정보에 대해 그 품질을 고려한다면 몇 가지 질문을 할 수 있습니다. 정확하게 저장되고 활용에 용이하게 저장, 관리되고 있는가? 믿을 수 있는가? 등입니다. 

    통상 품질이 SW(제품)의 품질을 말한다면, SW가 제공하는 모든 서비스의 기반은 데이터이며, 이에 대한 고품질을 확보하는 것이 곧 좋은 서비스를 제공하고 활용가치를 높이는 것이 됩니다. 더 나은 데이터 품질관리에 대한 심도 있는 이야기를 이해곤 이사(비투엔)의 현장 중심 인터뷰를 통해 살펴보는 시간을 갖겠습니다.


    이해곤 기술이사 (비투엔컨설팅)

    데이터의 확보를 위한 4가지 관점으로 데이터 값, 데이터 모델 구조, 데이터 품질관리 체계, SW(프로그램)이 있는데요. 하나씩 짚어가보겠습니다.

    Q: 실질적으로 데이터 품질을 높이기 위한 품질활동에는 어떤 것들이 있을까요 ?

    첫 번째로 '데이터 값'에 대한 품질활동이 있습니다. 데이터 값은 데이터베이스에 저장되어 있는 데이터(record) 또는 서비스 시점에 변환, 가공되어 제공되는 데이터라 할 수 있습니다. 예를 들자면 주민등록번호, 계좌번호, 보험료, 수도요금, 카톡의 문자 내용, 전화통화 내용 등이죠.

    이러한 데이터가 데이터베이스에 저장될 때는 "언제, 누가, 어떤 방식, 어느 곳에서 들어왔는지 등의 정보를 관리하게 됩니다. 이 때, 실제 값과 관리 정보가 정확히 정의된 표준에 맞게, 지정된 저장소에 누락 또는 변형되지 않게 저장되어야 하는 것이 중요합니다. 우리는 '이러한 과정이 당연히 잘 관리되고 있겠지' 라고 보고 있지만, 실제 데이터베이스를 진단해보면 데이터표준에 대한 정의가 없거나, 이중 잣대가 존재하여 동일 값이나 형태로 저장되고, 데이터가 원천 테이블에서 타겟 테이블로 이동함에 따라 누락 현상들이 존재하는 경우를 많이 볼 수 있었는데요. 여러분들의 이해를 돕기 위해 값을 진단하는 방법과 사례를 자세히 보여 드리겠습니다. 인터뷰 내용 더 보기 >>>


    2016년 1월 19일 화요일

    국내 SW공학수준 현황(2014년 조사 기준)

    SW프로젝트는 여러 가지 원인에 영향을 받는다. 일반적으로 프로젝트를 수행하는 참여 인력들의 SW공학에 대한 인식 및 현장적용의 경험이 가장 큰 원인으로 볼 수 있다. SW공학수준등급을 3등급(Absent, Average, Advanced)으로 구분하여 성과비교 시 활용하며, 각 등급을 구성하는 항목들은 아래의 표와 같이 정의했다.


    SW 공학수준은 체계적이고 효율적인 SW 개발을 위하여 필요한 사항들이 국내 SW 기업 내에서 얼마나 잘 구성되고 적용되고 있는지를 파악하기 위한 것으로, 체계적이고 효율적인 SW 개발이 이루어지기 위해서 SW 기업이 갖추어야 하는 요소로 체계적 업무 방식과 흐름의 정의 및 이에 대한 적용, 필요 조직구성 및 인력 육성, 정의된 업무 방식과 조직 및 인력이 효율적으로 운영되기 위하여 필요한 기반 인프라의 3가지로 정의하였으며, 각각 프로세스(Process), 인력(People), 기술(Technology)로 그 수준을 정의하도록 하였다.

    SW 공학수준점수는 체계적이며 효율적인 SW개발을 위하여 갖추어져야 하는 요소에 대한 수준을 점수화한 것으로 프로세스(Process), 인력(People), 기술(Technology) 각각의 3가지 수준의 점수를 반영하여 산정된다. 앞에서 설명한 SW 공학수준과 SW 공학수준을 구성하는 프로세스(Process), 인력(People), 기술(Technology) 측면의 평균 점수를 살펴보면, 프로세스(Process) 수준 점수가 69.6점, 인력(People) 수준 점수가 62.0점, 기술(Technology) 수준 점수가 63.9점이며, 이를 종합한 SW 공학수준점수는 65.7점을 보여주고 있다.




    프로세스 수준 및 기술 수준에 비해 인력(People) 수준 점수가 특히 낮은 것은 조직 체계, 사내 전문가 보유, 조직원 역량강화 등 조직의 안정성 개선을 위한 기본적인 준비 없이 프로세스 개선 활동이 이루어지고 있다고 이해할 수도 있다. 이러한 이유로 SW 공학수준 개선의 중장기 성과에 큰 장애가 될 수 있음을 예상할 수 있다.

    일의 방식(Process), 일을 위한 조직 구성 및 인력 육성(People), 인프라 및 기술 기반 마련(Technology)이 동시에 균형을 이루며 갖추어져야 실질적인 SW공학 수준의 향상 효과를 볼 수 있다. 하지만 조사 결과는 국내 SW 기업들이 다른 영역에 비하여 프로세스 개선에 보다 치중하고 있으며, 프로세스 개선만을 통해 전반적인 SW 공학수준을 향상시킬 수 있다
    는 오해를 가지고 있는 것을 간접적으로 보여주고 있다.

    국내 SW 기업들의 SW 공학수준을 실질적으로 향상시키기 위해서는 프로세스(Process) 수준뿐만이 아니라 인력(People) 수준 및 기술(Technology) 측면에 대한 균형적인 개선이 시급하다는 것을 보여주고 있다.

    SW개발 방법론, MDA(Model Driven Architecture)와 Agile

    SW프로세스란 SW를 개발하기 위해 수행하는 일련의 활동을 의미한다. SW를 만들기 위해 필요한 활동들을 명확히 하고 품질확보와 납기를 지키기 위한 방법으로서 SW프로세스를 정립해야 한다.

    효과적인 SW프로세스를 만들기 위해서는 프로세스를 정의하고, 필요한 도구를 결정하여 프로세스를 실행해야 한다. 그리고 지속적인 개선을 통해 SW기술변화를 프로세스에 반영하고 수행자들에게 책임과 교육을 추진하여 결과를 피드백 하는 것이 해당 조직의 SW프로세스를 최적화하는 것이다.

    SW프로세스는 일반적으로 요구사항 수집 및 분석, 설계, 구현, 시험의 단계를 가지고 조직의 특성에 따라 활동이 정의된다.

    SW프로세스의 구조적 특징, 특성, 역할을 가지고 집합된 형태를 SW생명주기라고 부른다. SW생명주기는 SW개발 단계에 SW개발전략이나 전사적 정책을 통합시킨 것으로 개발방법, 개발환경에 대한 도구, SW 개발의 시작부터 끝까지 효과적으로 관리하기 위해 만들어진다.

    SW프로세스 모델의 유형 결정요소는 문제유형, 관점, 개발 방침에 따라 결정되며 일반적으로 SW개발 기본 프로세스 모델(생명주기 모델, ISO 12207)을 많이 참조하고 있다.

    SW개발 프로세스가 정립되면 SW개발 방법론과 함께 적용하여 SW개발을 추진하게 된다. SW개발방법론은 과거 고전적 방법론에서 애자일 방법론으로 유행이 전이되는 상황이다.
    ※ 고전적 방법론: 구조적 방법론 〉 정보공학방법론 〉 객체지향 방법론 〉 CBD 〉 SOA

    개발 패러다임의 변화와 과거 미시적 접근방법에서 거시적 방법으로 변화됨에 따라 객체 〉 컴포넌트재사용 〉 아키텍처 재사용 〉 프레임워크 〉 엔터프라이즈 아키텍처(EA)로 변화하고 있다.


    근래에는 SW개발 방법론으로 MDA(Model Driven Architecture)Agile이 주목받고 있다. MDA는 새로운 플랫폼과 기술을 도입하거나 환경적 변경요구에 따른 상호운영상 문제를 해결하기 위해 OMG가 제정한 기존의 모델링 표준들을 이용하는 개발적인 SW개발 기술이다. MDA의 특징은 모든 컴포넌트 기술 요소들에 대한 표준 메타모델을 정의하고 표준 메타모델을 기반으로 각 구성요소를 정의함으로 모든 컴포넌트 기술 요소들에 대한 호환성과 상호 운영성을 보장할 수 있다.


    Agile 프로세스는 변화하는 비즈니스 가치에 맞는 품질 좋은 SW를 계속해서 전달하는 것으로 1990년대 중반부터 폭포수 모델로 대표되는 전통적인 방식에 반대의 움직임을 보여 왔다. 급변하는 e비지니스 환경에서 SW개발 분야의 다양한 변화를 수용하고 대응할 수 있는 여러 방법론의 통칭이기도 하다.



    기존의 고전적 프로세스가 절차와 산출물을 중시하는데 반해 Agile은 협력과 수행 가능한 SW, 현장고객, 테스트 기법을 중시하고 있다.

    [SW공학 동영상 12화] Framework Distilled

    SW개발현장의 전문가 유민혁 이사로부터 Framework 소개, Framework 정의, Framework 등장배경, Framework 종류, Framework 사례와 적용 시 고려사항을 들어보시기 바랍니다.
    소프트웨어공학센터 회원 여러분의 업무에 꿀팁이 되길 기대합니다. 





    2016년 1월 18일 월요일

    2014 Software Engineering in brief

    2014년 SW공학백서(2015년 1월 발간)는 SW와 SW공학의 연계를 위해 현장에 다가가는 SW공학이라는 주제로 프로세스, 요구사항과 설계, 품질, 관리, 이슈에 대한 내용들을 담으려 노력했습니다. 아울러 SW공학에 대한 정량적 접근을 위해 SW공학 데이터에 대한 구조모델을 원인, 성과, 환경으로 정의하고 해당분야에 대한 내용을 정리 기술했습니다.

    SW프로젝트는 원인, 환경을 통해 성과를 창출하고 성장합니다. SW프로젝트의 성과를 도출하는 원인은 SW공학수준으로 파악할 수 있으며, 그 외의 다른 변수들은 수행전 상황, 수행의지 등 프로젝트 수행환경에 따라 결정되어 성과로 이어지게 됩니다.



    2014년도 SW공학백서에는 396개 기업, 451개 프로젝트로 패키지SW, IT서비스, 임베디드SW기업군이 참여했습니다. 그 세부 내용을 다운받아 업무에 참고하시기 바랍니다.


    형상관리 효과와 도입사례(LG전자)

    형상관리 효과는 경영, 개발, 관리의 3가지 측면에서 언급할 수 있습니다. 경영 측면에서는 SW 품질관리와 그에 따른 생산성 향상을 기대할 수 있습니다. 개발에서는 재사용성이 높아지고 동시 작업 편의성과 안전성이 향상됩니다. 또한, 관리 측면에서는 투명성이 확보됩니다.

    형상관리를 도입한 LG전자의 사례를 살펴보겠습니다. “형상관리 적용 후 단위 프로젝트에서 2∼3시간 소요해 전송해야 했던 소스를 실시간으로 공유하게 됐다. 또 미국, 브라질 등 해외에 분산된 연구개발(R&D) 센터에서 동시에 소프트웨어를 병렬방식으로 개발할 수 있게 돼 개발 생산성을 크게 높였다.” 라고 합니다.




    한신상호저축은행에서도 2005년 형상관리 도입 후, "소스코드 재사용 및 이전 버전의 롤백이 가능해져 문제 발생시 원인을 찾고 해결하는 시간이 대폭 단축됐다”라고 합니다.  또한, “문제 원인을 즉각적으로 확인하고 문제 해결에서 재발 방지까지의 활동을 단시간에 실시해 일정 지연요소를 제거하고 품질을 향상시켰다.”, “소스 통합 자동화 및 병렬 개발이 가능해져 개발 생산성을 향상시켰다.”, “도구 도입 후 하나의 개발 프로젝트에서 상당한 시간을 잡아먹던 소스 통합작업이 불필요해졌다.” 등의 반응을 얻었습니다.

    형상관리가 부족할 경우, 프로젝트 납기지연으로 인한 손실이 커지고, 품질저하, 변경이력 파악불가, 인증되지 않은 변경, 재작업율 증가 등의 악순환이 발생합니다. CMMI 에서도 형상관리 중요성을 강조하고 있는데요. 그 중요성과 접근 방법에 대해 자세히 알아보실 수 있습니다.