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

자료 다운로드 >>>

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품질 비용 >

핀테크 보안

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

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

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

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

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

<표 1> 보안의 3요소

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

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

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

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