2016년 2월 4일 목요일

프로세스와 프로젝트 매트릭스

SW프로세스와 프로젝트 지표는 SW프로세스 프레임워크 프로세스를 활용하여 수행하는 프로젝트에 대한 효과와 통찰력을 얻을 수 있도록 지원하는 정량적인 측정방법으로 기본적인 품질과 생산성 데이터를 수집하고 이 데이터에 대한 경험치 평균과 비교 분석하여 품질과 생산성이 향상했는지 여부를 결정하기 위해 진행된다. 또한, 측정을 통해 SW프로세스를 개선할 수 있도록 현황을 파악하는데 활용된다.

SW의 측정과 분석은 SW관리자에 의해 평가되고 SW개발자를 통해 데이터를 수집하게 된다. SW프로세스와 프로젝트를 측정하지 않는다면 결과는 주관적인 평가만을 통해 도출될 수밖에 없다. 측정을 통해 미래에 대한 준비 즉, 예측을 할 수 없게 되는 것이다.

프로세스 매트릭스를 구성하기 위한 측정은 모든 프로젝트 기간 동안 수집된다. 진행 중인 프로젝트의 상태를 평가하고 잠재적인 위험을 추적하고 중요한 문제 영역을 발견하거나 작업흐름 또는 작업을 조정하고 프로젝트 팀을 평가하는 등 프로젝트 매트릭스를 기반으로 SW프로젝트 관리가 가능하게 된다. 또한 프로젝트 팀에 의해 수집된 데이터들은 개선결과와 더불어 SW프로세스 개선에 영향을 미치게 된다.

< SW품질 및 조직의 효율성에 대한 결정 >




전략적 목적을 위해 사용되는 SW프로세스 측정과는 달리 SW프로젝트의 조치는 전술이다. 즉, 프로젝트 지표이며 이로 인해 파생되는 지표는 프로젝트 관리자 및 프로젝트 워크플로우, 기술 활동을 적용하는 SW개발팀에서 활용하게 된다.

대부분의 SW프로젝트의 프로젝트 지표는 SW를 개발하는 동안 발생한다. 과거 프로젝트에서 수집된 매트릭스의 노력과 납기 데이터들은 현재 SW개발을 위한 기초자료로 활용되는 것이다.

프로젝트 진행, 노력, 비용, 시간의 측정은 기존 추정치와 비교될 때 모니터링되고 이러한 데이터를 관리 가능하게 해주는 것이다. SW기술작업이 시작될 때 다른 프로젝트 매트릭스들은 의미를 가지고 시작하게 된다. 모델 도출, 검토시간, 기능점수 및 소스코드의 측면에서 생산성이 측정된다. 또한 각 SW개발 작업 중에 발견된 오류들이 추적되기도 한다.


SW의 발전으로 설계시 요구사항은 기술 매트릭스를 통해 설계품질을 평가하고 소스코드 및 테스트에 소요되는 방식에 영향을 미치게 된다. 프로젝트 매트릭스의 목표는 두가지다. 첫째는 프로젝트의 지연을 방지하고 잠재적인 문제 및 위험을 완화시키고 일정을 최소화하는데 활용된다. 둘째는 지속적으로 제품의 품질을 평가하는데 사용하고 필요시 품질향상을 위한 기술방식을 수정할 수 있게 되는 것이다. 결함 측정을 통해 결함을 최소화 시키면 개발품질의 향상을 통해 프로젝트 기간 동안 필요한 재작업의 양 또한 감소하게 되고 이는 전체 프로젝트 비용의 감소로 이어지게 된다.


SW공학의 최우선 목표는 적시에 높은 품질의 시스템 또는 SW제품을 생산해 내는 것이다. 이 목표를 달성하기 위해서는 검증된 SW프로세스 내에서 현대적인 도구와 효과적인 결합을 통해 적용해야 한다. 매트릭스는 요구사항의 품질과 설계모델, 소스코드, 테스트 케이스를 평가하기 위해 활용될 수 있다.



< SW매트릭스 수집 프로세스 >

OPM3(Organizational Project Management Maturity Model)

프로젝트의 관리는 OPM3(Organizational Project Management Maturity Model)을 통해 수준을 알 수 있는데 체계적으로 포트폴리오, 프로그램, 프로젝트를 관리하는 PMI 표준이며 조직 목표와 연계하여 향상시킬 수 있다. 또한 OPM3는 현재의 성숙도 평가를 지원하고 이상적인 성숙도를 결정하여 향상을 위한 단계를 추적하게 된다.

< OPM3의 구성요소 >

조직의 프로젝트 관리 성숙도를 향상시키기 위해서는 전사적 프로젝트관리를 지원할 수 있는 기반 체계 구축하고 프로젝트 관리에 대한 지속적인 훈련과 체계를 제공하는 것이 중요하다. 효율적인 전사 프로젝트 관리를 위한 기반 체계로 포트폴리오 관리와 프로그램 관리가 필요하고 이를 수행하고 관리하기 위한 프로젝트 관리조직이 정착될 필요가 있다.

전사적 프로젝트 관리를 위하여 먼저, 프로젝트를 조직의 전략적 목표를 달성하기 위하여 그룹핑(grouping)하고 우선순위를 평가해야 한다. 프로그램이란 조직의 전략적 목표달성을 위하여 묶은 프로젝트 집합으로, 일반적으로 사업부(business unit)의 제품 단위별로 프로젝트를 묶어 구성하게 된다. 프로그램 관리는 성과를 만들어내는 전략적인 운영에 초점을 둔다면, 포트폴리오 관리는 프로젝트의 우선 순위를 평가하고 이에 따른 자원투입과 같은 계획 과정을 주로 다루게 된다.

< 전사적 프로젝트 관리체계 >

전사적 프로젝트 관리는 단순한 트렌드가 아닌 기업의 경쟁력을 향상시킬 수 있는 중요한 요인이 되어가고 있다. 하나하나의 프로젝트는 별문제가 없는데 기업의 전체성과는 별반 향상을 가져오지 못하고 있다면 이는 조직의 목표와 프로젝트 관리가 한 방향으로 정렬되지 못했기 때문일 수 있다.

2가지 프로젝트 관리 개념

프로젝트 관리란 SW개발을 하나의 프로젝트로 정의하고 개발과정에서 발생하는 상황들을 정기적으로 점검하고 개발 생명주기에 걸쳐서 작업계획이나 일정계획, 진척상황 등을 문서로 정리하여 리뷰 하는 것을 의미한다. SW프로젝트 관리에서는 개발 계획의 수립이나 진도관리, 품질관리, 환경구축 등에 SW공학적 기법을 사용해 관리하게 된다.

프로젝트 관리는 개별적 프로젝트 관리도 중요하지만 전사적 차원의 프로젝트 관리가 매우 중요하다. 일반적으로 프로젝트 관리하고 하면 개별적으로 프로젝트 관리를 대상으로 착수부터 종료에 이르는 과정을 관리하는 것으로 생각한다. 개별 프로젝트를 관리하는 것이 효율적으로 하나의 프로젝트를 수행하는 지에 대한 방법이라면 전사적 프로젝트 관리는 동시 다발적으로 진행되는 복수의 프로젝트 환경에서 비즈니스 적응력과 대응력을 높여 수익성을 높이고 위험을 줄이는 방안을 마련하는 것이다.

현장에서 약 70% 이상의 조직이 전사적 프로젝트 관리 방법을 적용하고 있으며, 주로 전사적 관점에서의 우선순위와 프로젝트에 대한 표준화된 접근방법을 수행하기 위해 전사적 프로젝트 관리 조직을 운영하고 있다.

전사적 프로젝트 관리 조직을 운영하는 조직들은 2000년 48%에서 2012년 87%로 증가하였으며, 프로젝트 목표 달성과 고객만족도 향상, 예산 및 납기 준수 그리고 생산성 개선에서 직접적인 기여를 하고 있다고 제시하고 있다.

전사적 프로젝트 관리(Enterprise Project Management)라는 것은 새로운 이론이나 개념은 아니다. 90년대 말부터 해외 논문과 방법들이 소개되어 왔고 이를 위한 다양한 방법론들이 제시되어 왔다. 전사적 프로젝트 관리는 전통적으로 크게 다음과 같은 두 가지 개념으로 구분할 수 있다.


  1. 조직적인 관점: 전사적 프로젝트 관리의 주창자로 알려져 있는 Paul Dinsmore는 전사적 프로젝트 관리를 조직의 목표가 서로 연관을 갖는 다수의 프로젝트에 의하여 달성될 수 있다는 원칙에 기반을 둔 조직적 경영철학으로 정의하고 있다.
  2. 시스템적인 관점: 오랫동안 프로젝트관리 도구에 관심을 가져 온 Harvey Levine은 전사적 프로젝트 관리를 프로젝트 관리 실무와 도구를 전사적으로 적용하는 것으로 보고 있다.

    이러한 두 가지 접근 방법은 그 집중하는 주제에서도 서로 상이하게 되는데, Paul Dinsmore는 성숙도 모델, 프로젝트 오피스, 프로젝트의 전략적 관리 및 역량 모델 등을 주로 주제로 하고 있으며, Harvey Levine은 시스템 통합, 연계성, 프로젝트의 재무적 집계, 데이터 통합과 전사적 자원관리 등을 주로 다루고 있다. 

    비록 두 가지 개념이 다루는 주제는 차이가 나지만 전사적 프로젝트 관리하는 관점에서 공통된 목표를 가지고 있어 이 두 가지 개념이 조화를 이룰 때 전사적 프로젝트 관리가 조직에서 성공적으로 구현될 수 있다.

    2016년 2월 3일 수요일

    SW아키텍처 설계 산출물 관계도(예시)


    제품 매트릭스

    모든 공학 프로세스의 핵심요소는 측정이다. 보다 낳은 제품을 만들고 개발할 때 산출물의 품질을 평가하는 모델을 이용하기 위해서는 측정을 해야만 한다. 다른 공학분야와 달리 SW공학은 측정이 쉽지는 않다. SW공학에서 측정을 하는 사람들은 SW의 설계 및 구축에 대한 통찰력을 갖출 수 있도록 SW공학적 작업의 산출물인 제품의 측정 속성에 대해 고려해야 한다.

    언제나 어떠한 제품이라도 질적인 평가는 충분하지 않다. 데이터 구조, 인터페이스 및 구성요서의 설계를 살펴보고 도움이 될 수 있는 객관적인 기준이 필요하다. 또한, 테스트시 테스트케이스와 테스트 방법의 선택에 도움이 되기 위해 정량적인 가이드라인이 필요하게 된다. 데이터에서 도출되는 제품의 매트릭스는 요구사항과 설계 모델, 소스코드, 테스트케이스를 통해 연계되며 수집을 위해 목표를 설정하고 매트릭스를 정의해야 한다. 매트릭스의 정의는 SW개발 제품의 품질에 대한 통찰력을 얻기 위해 수행하게 된다.

    제품 매트릭스를 위해서는 측정과 매트릭스 그리고 측정인자를 도출해야 한다. 또한 제품 매트릭스의 도출을 위해 여러 가지를 고려하고 추진해야 하지만 SW의 복잡성에 대한 포괄적인 측정이 쉽지만은 않은 상황이다. 측정자의 필요에 따라 해당 도메인과 제품을 평가하기 위한 매트릭스를 고려해야 한다. 제품 매트릭스는 분석 및 설계모델의 평가에 도움이 되고, 디자인과 소스코드에 대한 절차의 복잡성에 관한 표식을 제공하며 효과적인 테스트 설계를 용이하게 해줄 수 있다.


    요구사항 모델을 위한 매트릭스를 구성하기 위해서는 기능점수(FP)를 도출하여 SW데이터의 흐름을 확인하는 기능점수기반-매트릭스가 필요하다. SW제품에 대한 정량화를 위해 기능점수로 표현한 후 이를 통제하고 점검할 수 있는 기반을 마련하는 것이다. 아울러 품질요구사항에 대한 매트릭스를 추가로 구성하여 이를 고려해야 한다.



    일반적인 설계모델을 위한 매트릭스는 설계 지표를 중심으로 매트릭스를 구성하게 된다. 객체지향 설계에 대한 매트릭스는 규모와 복잡도, 커플링(디자인 요소사이의 물리적 연결), 적합성, 완전성, 결합성, 원시성, 유사성, 변동성을 고려하여 매트릭스를 구성하게 된다.



    소스코드를 위한 매트릭스를 위해 측정할 대상은 프로그램 인터페이스에 표기된 별개의 카운트 또는 고유한 피연산자 카운트, 오퍼레이트 카운트, 전체 프로그램 길이, 알고리즘에 잠재적인 볼륨 등 도메인과 상황에 따라 변경되어 측정할 수 있다. 또한 테스트를 위한 매트릭스 구성은 분석, 설계 및 구현 매트릭스에 의존하여 실행되며 최종 제품에 영향을 미치기 때문에 여러가지 상황과 현실을 고려해야 한다. SW 매트릭스는 제품을 만들기 전에 품질을 예상하고 검토할 수 있도록 제품 특성품질을 평가하는 방법을 도출할 수도 있다.


    형상관리

    오늘날의 SW개발에서 형상관리는 다양한 방식의 접근과 도구의 활용을 통해 이루어진다. 일반적으로 SW형상관리의 범위를 소스코드의 버전관리가 주된 활동들이라고 생각하는 경향이 있다. 소스코드의 버전관리에 대한 메타 태그와 인덱스를 정리하는 활동들이 형상관리라고 생각하고 이행되고 있다.

    하지만 실제 개발에 사용되는 것들과 표준화적인 요소를 반영하고 있는 CMMI, SPICE, SP인증, ITIL 등 SW공학관점의 형상관리의 기능은 단순한 소스코드 버전관리를 넘어서 변경되는 내용과 이슈에 대한 관리, 릴리즈를 포함한 그 이상의 범위를 대상으로 하고 있다. 실질적으로 변경관리가 된 것 들을 빌드하고 테스트한 후에 배포까지의 전체 프로세스 수행상황에 대해 정리하고 관리하는 것이 바로 형상관리의 목표인 것이다.

    형상관리를 공학적으로 어떻게 표현하든 SW개발과 관련된 산출물 및 과정 그리고 기타 활동들은 기록되고 관리되어 지며 검토를 통해 승인되고 저장되어 향후 발생할 수 있는 상황에 대해 대응하고 문제점과 개선점을 도출하여 보다 발전된 형태로 SW개발을 할 수 있는 기반을 마련하는 것이다.


    < ISO/IEC 15504(SPICE)의 Best Practice >

    < CMMI의 Support Area>

    < SP인증에서의 형상관리 >

    다양한 표준들에서 형상관리항목을 중요하게 생각하고 형상관리를 잘 이행할 수 있도록 또는 점검할 수 있도록 관련 프로세스와 활동들을 정의하고 있으나 이러한 표준들은 현장에서 발생하는 활동들을 관점에 따라 다시 정리한 것으로 이미 현장에서 형상관리를 잘하고 있는 조직은 발전의 기회로 삼으면 될 것이다.

    하지만 그렇지 않은 조직이라면 기 검증된 SP인증, CMMI, SPICE 등 표준들을 기반으로 전사적인 형상관리 체계를 구축하고 이행을 위한 기반을 마련하는 것도 하나의 방법일수 있다.

    < 현장에서 생각하는 형상관리 범주 >


    형상항목을 식별하여 체계적으로 형상의 변경을 통제하고 프로젝트 생명주기 전방에 형상의 추적성과 통합성을 유지하는 것은 매우 중요하다. 형상관리의 영역은 버전관리, 변경관리, 빌드관리, 릴리즈 관리, 워크스페이스관리를 모두 포함한다.

    형상관리를 통해 산출물의 무결성을 확보하여 유지하고 불필요한 변경요청을 제어할 수 있고 모든 산출물을 프로젝트 팀원이 공유함으로써 커뮤니케이션이 원활해진다. 또한 객관적인 자료와 정보들을 통해 정량적인 진척관리가 가능해 지는 것이다.