CMMI (2) (프로젝트 성공률 1% 높이기)

CMMI 구조

CMMI는 이행과 내재화를 통해 운영된다. 수립된 프로세스에 따라 업무를 수행하고 이를 통해 내재화가 된 업무는 불특정 다수의 사람이 와서 수행하더라도 똑같은 방식으로 업무는 수행된다. 이런 방식이 가능한 이유는 모델 구조에 기안한다. 모델은 크게 성숙단계(단계적 표현 방법) 혹은 능력단계(연속적 표현 방법), 프로세스 영역, 일반/특정 목적, 공통 수행항목 그리고 일반/특정 프랙티스로 나뉜다. 다음은 단계적 표현 방법이다.
 
 

단계적 표현 방법의 모델 컴포넌트< 단계적 표현 방법의 모델 컴포넌트 >

 
✔️ 성숙 단계(Maturity Levels)
: 조직에서 해당 업무를 얼마나 체계적으로 수행하고 있는지를 나타내는 지표로서 단계1이면 조직은 임기응변으로 업무 수행, 단계2이면 기본적인 프로젝트 관리 활동을 수행하고 있음을 말한다.
 
✔️ 프로세스 영역(Process Area)
: 해당 프로세스를 위해서 수행되어야 하는 활동들의 집합으로 하나의 프로세스 영역은 반드시 성숙단계 2, 3, 4, 5중 하나에 포함된다.
 
✔️ 목적과 프랙티스
: 모든 프로세스 영역은 달성해야 할 몇 가지 목적을 갖는다. 이러한 목적은 해당 프로세스 영역이 조직 내에서 수행되고 있음을 판단하는 기준이 되며 추상적으로 정의된다. 그래서 목적들은 보다 구체적으로 기술된 프랙티스들과 연결된다.
  – 특정 목적(Specific Goal): 특정 프로세스 영역과 관련된 목적
  – 일반 목적(Generic Goal): 모든 프로세스 영역에서 공통으로 적용될 수 있는 목적 (조직 내재화 판단)
  – 특정 프랙티스(Specific Practice): 특정 목적을 충족시키기 위해 조직이 수행해야 할 활동
  – 일반 프랙티스(Generic Practice): 프로세스가 효율적으로 지속될 수 있도록 해당 프로세스를 내재화하는 활동
 
✔️ 공통 수행항목(Common Features)
: 프로세스 영역 내에서 일반 프랙티스들이 그 특성에 따라 그룹화한 것 (단계적 표현 방법에서만 사용)
  – 수행방침(Commitment to Perform): 경영진 참여나 문서화 정책 관련 활동
  – 수행 능력(Ability to Perform): 프로세스 수행계획수립, 자원 제공, 교육 등과 관련한 활동
  – 직접 이행(Directing Implementation): 형상 관리, 관련 이해당사자의 식별, 참여, 프로세스 모니터링, 통제, 개선정보 수집 관련 활동
  – 이행검증(Verifying Implementation): 표준 준수 여부의 객관적 평가, 상위 관리자 검토 등 관련 활동
 
 
다음은 연속적 표현 방법이다. 이는 기본적으로 단계적 표현 방법과 동일하나 일반 프랙티스를 공통 수행항목으로 구분하지 않고 특정 프랙티스를 기본 프랙티스(특정 프랙티스 중 능력 단계1에 해당하는 프랙티스들)와 고급 프랙티스(특정 프랙티스 중에서 능력 단계2 이상 해당하는 프랙티스들)로 구분하는 것이 다르다.
 

연속적 표현 방법의 모델 컴포넌트< 연속적 표현 방법의 모델 컴포넌트 >

 
 
단계적 표현 방법(성숙 단계)은 조직 내 체계적 업무 수행의 정도로 1단계에서 5단계까지 구분한다. 그래서 계단처럼 구성되어 있으며 각 단계 프로세스 영역이 만족하여야 다음 단계로 넘어갈 수 있다. 이에 반해 연속적 표현 방법(능력 단계)은 프로세스 영역 능력 수준을 측정하는, 해당 조직의 프로세스 영역에 대한 능력 정도를 나타낸다. 이를 통해 영역별 수준을 확인해서 어떤 영역이 잘되는지 어떤 영역이 떨어지는지 확인할 수 있다.
 
 

CMMI 표현

앞선 구조처럼 조직의 프로세스 개선 활동의 우선순위가 CMMI에서 정의한 프로세스 영역들과 유사한 경우라면 단계적 표현 방법을 선택하면 훨씬 더 체계적일 수 있고 그렇지 않고 조금 특이한 경우라면 연속적 표현 방법을 적용하면 더 효율적일 수 있다. 이이 각 표현 방법들이 어떤 것인지 살펴본다.
 
🚩 단계적 표현 방법
:조직에서 프로세스 개선 활동을 수행할 때 하나의 로드맵을 제시하는 데 중점을 둔다. 이는 한 조직의 프로세스 능력이 발전되는 과정을 몇 가지 성숙 단계로 정의하고 상위 성숙 단계로 도달하기 위해서는 반드시 그 하위의 모든 성숙 단계들을 충족시켜야 한다.
 
✔️ 성숙 1단계: 초기(Initial)
  – 조직은 구조화된 프로세스가 없다. 모든 것이 임기응변적이다. 아무런 활동을 요구하지도 않는다.
 
✔️ 성숙 2단계: 관리됨(Managed)
  – 기본적인 프로젝트 관리 프로세스들이 있으며 그것에 따라 업무가 수행되고 있다. 기본적인 활동들이 있다.
 
✔️ 성숙 3단계: 정의됨(Defined)
  – 해당 조직에서 따라야 하는 조직 차원의 표준 프로세스가 있다. 훨씬 구체적이고 정교한 프로세스가 관리된다.
 
✔️ 성숙 4단계: 정량적으로 관리됨(Quantitatively Managed)
  – 모든 프로세스가 통계적이고 정량적이다. 의사결정이나 개선 여부 파악을 위해 메트릭을 활용한다.
 
✔️ 성숙 5단계: 최적화(Optimizing)
  – 프로세스 성과 변동 중 일반적인 원인에 대한 분석을 통해 지속 개선한다. 아주 이상적인 조직의 상태이다.
 
🚩 연속적 표현 방법
: 프로세스 영역들이 프로세스 관리, 프로젝트 관리, 엔지니어링, 지원의 4가지이다. 이는 개별 프로세스 영역 내에서의 프로세스 개선 활동에 초점을 두고 개별 프로세스 영역별로 능력 단계를 부여할 수 있기 때문이다.
 
✔️ 능력 0단계: 불완전함(Incomplete)
  – 요구되는 대부분의 활동이 수행되지 않는다. 
 
✔️ 능력 1단계:수행됨(Performed) 
  – 정의된 기본 프랙티스들이 기본적으로 수행되고 있다. 다만 확신할 수는 없다.
 
✔️ 능력 2단계: 관리됨(Managed)
  – 하나의 프로세스가 개별 프로젝트나 팀별로 계획, 수행, 추적 및 통제되고 있다. 이 단계부터 기본적 메트릭을 수집해야 한다.
 
✔️ 능력 3단계: 정의됨(Defined)
  – 표준 프로세스를 tailoring 가이드에 따라 조정하여 적합한 프로세스를 개발하고 활동을 관리한다.
 
✔️ 능력 4단계: 정량적으로 관리됨(Quantitatively Managed)
  – 정의된 프로세스가 통계적 기법이나 다른 정량적인 방법 등을 통해 관리되고 있다.
 
✔️ 능력 5단계: 최적화(Optimizing)
  – 하나의 프로세스를 반복 수행한 결과가 가지는 변동의 일반적 원인에 대해 분석, 개선하여 변동의 범위를 지속 줄여나간다.
 

CMMI 비교

이와 같이 두가지로 구분된 모델은 어떻게 비교가 될까? 각가의 특장점이 있어서 무엇을 추천한다기 보다는 현장상황에 따라서 모델을 선택해야 한다. 단계적 표현(Staged Representation) 모델은 구조화된 로드맵을 제공하고 조직 간 벤치마킹이 용이하다. SW-CMM과의 호환성도 좋고 평가결과가 간결하여 규정 준수 등이 필수적인 분야나 체계적인 프로세스 기반이 부족한 초기개선조직에 어울린다. 반면 연속적 표현(Continuous Representation) 모델은 프로세스 영역을 선택집중할 수 있어 유연하고 역량 수준에 따른 점진적 개선을 할 수 있다. 또한 복잡한 프로젝트 환경에 더 어울려서 기 성숙한 조직 또는 맞춤형 개선이 필요할 때 더 많이 쓰인다.
 
구분 단계적 표현 모델 연속적 표현 모델
선호도 높음(특히 국내) 낮음(해외, 고도화된 조직)
장점

구조화된 단계별 접근
벤치마킹 용이

유연한 개선
특정 PA 집중 최적회

단점

유연성 부족
모든 PA 강제 적용 필요

평가 결과 복잡
초기 조직 적용 어려움

적합 조직

규제 준수 필요
초기/중소 조직

성숙 조직
복잡한 프로젝트 환경

 
이런 특징들로 국내에서는 어떤 모델이 더 선호대상인가? 국내는 단계적 표현모델이 더 인기가 있다. 그 이유는 여러 배경들이 있겠지만 우선 숫자로 명확하게 표현되는 등급체계가 인증을 우선 시 하는 문화와도 결부되어 있고 SW-CMM기반의 기존 개선모델에 대한 경험, 그리고 평가가 간소하다는 것이 실무자들에게 더 높은 평가를 받는 면이 있지 않나 싶다.
 
 
 
 
※ 무슨 말인지는 알겠으나
CMMI를 도입하고자 결정이 나면 해야 할 일이긴 하지만도 지금 일도 많고 바빠 죽겠는데 또 하나의 혹이 달린 것 같아 현장에선 뜨미지근하다 못해 험한 말도 나온다. 그래서 전담조직을 만들고 선단에서 정리를 해나가며 현업들을 설득하는 자리를 빼놓지 않는다. 그러다 보면 일이 힘든 것이 아니라 사람이 힘들다는 것을 뼈저리게 느낀다. 으…. 정말 사람이 전부다. 언제부터인가 사람은 고쳐 쓰는 것이 아니라는 말이 유행처럼 나돌기는 하는데 이 말이 정말인가 다시 한 번 곱씹어보게 된다. 그리고, 나를 돌아보게 된다. 나는?

CMMI (1) (프로젝트 성공률 1% 높이기)

CMMI: Capability Maturity Model Integration

프로세스 개선을 위한 접근방법인 CMMI. 한마디로 말해 조직의 프로세스 개선 활동을 효율적으로 지원하기 위한 모델이다. 좀더 살펴본다면 기존의 CMM은 조직의 프로세스 능력을 어떠한 방향으로 발전시켜 나가야 하는지에 대한 비전을 단계적으로 제시하는 것이라 한다면 통합(Integration)은 기존 여러가지의 CMM모델들을 하나로 정리했다는 것을 의미한다.
 
그동안 SEI(Software Engineering Institute: 소프트웨어 엔지니어링 연구소)에서는 소프트웨어 엔지니어링이나 시스템, 소프트웨어 획등 등에 관한 많은 CMM 모델을 개발해왔고 이를 많은 기업과 프로젝트에서 적용하여 활용했다. 그러나 대부분은 복잡하고 관리가 힘든 여러 모델 대신 하나의 모델로 프로세스를 관리하길 원했고 그 결과로 CMMI가 만들어진 것이다. 
 
CMMI는 단순히 모델을 통합했다는 것 이상의 의미를 갖는다. 그 이유는 여러 모델들에서 다르게 사용되던 용어들을 하나로 통일했다는 것과 개별 모델의 프로세스들이 서로 어떤 형태로 관계를 맺고 있는지를 확인하고 일관된 관점에서 재정립했기 때문이다.
 
 

CMMI 적용 이유

조직과 프로젝트 현장에서 CMMI를 필요로 하는 경우는 많이 접한다. 그들이 이야기를 가만히 들어보면 여러 이유가 있는데 수긍이 가는 측면이 많다.
 
♾️ 고객이 원한다.
♾️ 지금까지 CMM를 적용해봤지만 이젠 CMMI고 더 적합하다고 생각한다.
♾️ 프로세스 개선에서 앞서가고자 한다.
♾️ CMMI가 엔지니어링, 소프트웨어 획득, 통합 제품 팀개발 활동 등에 대한 구체적인 방법을 제시한다.
♾️ 그동안 서로 다른 프로세스 평가 및 개선 프로그램을 도입했으나 중복작업에 대한 비용과 혼선이 많다.
 
이런 이유들로 CMMI를 적용해보고 싶은 조직과 프로젝트 현장의 상황은 어느 정도 파악이 되는데 막상 CMMI를 도입하려는 입장에서는 이 또한 매우 어려운 일로 여긴다는 것도 안다. 이를 실제 현장에 적용하기 위해서는 제일 먼저 조직이 준비가 되어 있어야 하며 잘 받아들기 위한 지원체계 또한 제대로 구축이 되어 있어야 하기 때문이다. 타 조직이나 프로젝트에서 성공했다고 해서 섣불리 일을 진행하기가 쉽지 않은 것이다.
 
 

용어 먼저

항상 강조하지만 용어가 최우선이다. 여러 이해관계자들이 모여 하나의 목표를 설정하고 나아가고자 한다면 반드시 서로 합의하고 사용할 용어를 정의해야 한다. 특히 CMMI는 기존의 포괄적인 개념이 아닌 하나의 통합된 환경과 목표를 가지기 때문에 더욱 그러하다. 그럼 가장 중요한 용어 몇가지를 정의해 보자.
 
🚩 모델
: 조직의 프로세스에서 어떤 부분이 잘못되었는지 확인시켜주는 가이드라인. 단순하게 프로세스를 가져와 그대로 적용하는 것이 아니며 어떻게 업무를 수행하는가 보다는 무슨 일을 수행하는가에 대한 사례로 정의된다. 이는 다른 말로 수행했던 여러 성공사례의 모음집으로 말할 수 있다.
 
🚩 조직
: 프로세스 개선 활동을 수행하는 가변적 단위. 가변적인 단위는 퍼즐 조각처럼 더 이상 바꿀 수 없는 개념이 아닌, 레고 블록처럼 다양한 조합을 통해 여러 가지 모양을 만들 수 있는 개념이다. 그러므로 전사 차원에서 프로세스 개선 활동을 수행할 경우 조직은 회사 전체를, 사업부나 부서 차원에서 프로세스 개선 활동을 추진할 경우에는 해당 사업부나 부서를 말한다. 또한 한 사람만으로 구성된 조직도 조직으로 구성할 수 있다.
 
🚩 프로세스
: 하나의 문제를 해결하기 위한 일련의 작업모음. 이 작업들은 수행하는 사람들이 쉽게 이해할 수 있어야 하고 이를 사용하는 모든 사람들이 하나의 일관된 행동을 할 수 있도록 명확하게 정의되어야 한다. 이를 통해 조직에서 발생하는 모든 중복작업을 제거하고 최소화해야 한다. 
 
🚩 CMM
: 능력 성숙도 모델. 소프트웨어를 개발하는 조직을 관리하기 위한 체계로 조직의 프로세스 능력에 대한 목표와 비전을 제시하며 수많은 조직의 여러 활동 중 의미있는 316개의 핵심활동(Key Practice)을 정리하고 이를 다시 그룹화하여 18개의 핵심 프로세스 영역(Key Process Area)으로 구성되어 있다.
 
🚩 프로젝트
: 고객에게 제품, 서비스를 제공하기 위해 요구되는 모든 활동과 자원. 여러 프로젝트가 모여 하나의 프로젝트가 될 수도 있다. 프로젝트는 명확한 목표와 목적을 가지고 반드시 시작일과 종료일이 있어야 한다. 반복되지 않고 유일하며 매우 치밀하고 구체적이어야 한다.
 
🚩이행(Implementation)
: CMMI 개별 프로세스 영역에서 정의하고 있는 활동을 조직 내부에서 수행하는 것으로 하나의 프로세스를 수립한 이후 그에 따라 업무를 수행한다. 내재화로 가기 위한 시작점이자 반복행위이다.
 
🚩내재화(Institutionalization)
: 하나의 프로세스가 조직 문화로 스며들어 모든 사람들이 아주 당연하게 해당 활동을 수행하는 것. 이를 통해 특정 업무를 다른 사람이 와서 수행하더라도 똑같은 방식으로 수행한다면 내재화는 성공한 것이다.
 




 

준비

CMMI는 조직의 프로세스 개선 활동을 지원하기 위한 여러 모델 중 하나이며 기존 모델들의 통합으로 조직의 많은 영역에서 도움을 줄 수 있다. 하지만 다양한 조직과 프로젝트에 적용할 수 있도록 하기 위해서는 포괄적인 개념이나 용어를 사용하고 있기 때문에 이를 적용하기 위하여 충분한 학습과 이해가 반드시 전제되어야 한다.
 
그 이후 해당 조직과 프로젝트의 구체적인 적용 방법에 대해서 한번 더 심사숙고하고 의사결정을 내려야 한다. 물론 단계과 범위에 따라 다르기는 하지만 여기엔 많은 시간과 비용이 들어가며 특히 경영진의 관심 여하에 따라 이 프로젝트도 성공과 실패로 나뉘기 때문이다. 무엇보다도 경영진의 지속적인 관심이 프로젝트 성공의 관건이다. 남들이 했다고 따라할 것은 절대 아니다.
 
 
 
 
※ 주요국 CMMI 인증 현황
SWSTAT에 따르면 2024년 5월 기준으로, 전 세계에서 CMMI를 인증받은 국가 1위는 중국(11,101건, 레벨5(2,273건), 레벨3(8,783건)), 2위는 미국(1,330건, 레벨5(40건), 레벨3(1,185건)), 3위는 인도(552건, 레벨5(182건), 레벨3(465건))이고 한국은 7위(48건, 레벨5(9건), 레벨3(27건))으로 아시아에서는 중상위권이다. 이렇게 보면 상당히 적게 보이지만 CMMI 인증 유효기간은 3년으로 이를 감안해서 보면 된다. 

품질 (프로젝트 성공률 1% 높이기)

품질!

품질은 제품의 가치를 나타내는 척도로 제품/서비스가 그 목적을 만족시키는가의 여부를 결정하기 위한 평가의 대상이 되는 고유한 특성을 말한다. 이에 대한 정의들이 꽤 많은 편인데 IEEE에서는 주어진 요구사항을 만족시킬 수 있는 SW의 기능과 특성을, ISO/IEC 9126에서는 명시적이나 묵시적인 필요를 만족시키는 능력과 관련된 소프트웨어 특성 및 특징을 말한다. 
 
그래서 품질 또한 관리의 대상으로 정책을 가동하고 있으며 측정과 더불어 명확한 목표를 가지고 제시된다. 이러한 품질목표는 제품과 프로세스에 대한 의미가 모두 내포되어 있다. 제품 측면에서는 고객의 제품 품질 요구사항을 식별하고 프로세스 측면에서는 프로젝트에 적합한 수행 공정을 정의한다. 
 
 
🚩소프트웨어 품질
 :  소프트웨어 프로젝트에서는 수명주기에 따라 개발 초기 프로젝트의 특성과 품질 요구사항을 철저히 파악하여 품질목표를 설정하고, 개발단계에서는 이 충족 여부를 그리고 운영단계에서는 사용 중 품질을 점검하게 된다. 이는 개발 완료 상태에서의 평가만으로는 소프트웨어의 신뢰성과 안정성을 보장할 수 없고 개발이 완료된 상태에서의 개선은 개발에 투입된 것 이상의 시간과 비용이 발생하기 때문이다.
 
소프트웨어는 수명주기와 맞물려 품질을 다룬다. 구현단계에서는 디버깅을 통한 증명을, 상세설계/시험 단계에선 테스트를 통한 검증(Verification)을, 기본설계/통합테스트 단계에서는 품질관리를 통한 확인(Validation)을, 요구분석/인수테스트 단계에서는 품질보증을 통한 인증(Certification)을 한다.
 
이러한 활동에는 비용이 발생하기 마련이다. 이 품질비용은 사용자 요구사항 수준을 고려하여 적정 비용 선을 설정하며 크게 예방비용, 평가비용, 실패비용으로 분류하고 관리한다. 이를 통해 총 품질비용과 최적의 품질수준을 찾아낸다.
 
🚩프로세스 품질
:  제품에만 집중되어 있던 품질은 프로세스 관점에서 높은 품질 수준을 유지하기 위한 중요성을 인식하면서 관심이 높다. 제대로 된 프로세스는 높은 품질의 제품생산 확률이 증가한다는 것은 알기 때문이다. 이에 대한 연구는 CMM/i, SPICE, Bootstrap 기법 등 여러 가지며 프로세스 품질에서 중요한 개발 방법, 도구 적정 여부, 표준 적용 및 관리과정의 적정성을 상세히 다루고 있다.
 
♾️ ISO9000 시리즈: ISO9000-1(품질경영/품질보증 표준), ISO9001(설계/개발/생산/서비스 품질보증), ISO9002(생산/설치 품질보증), ISO9003(최종 검사/시험 품질보증)
 
♾️ ISO/IEC 12207: 소프트웨어 생명주기 내 품질 활동을 5가지 기본 프로세스와 8가지 지원프로세스, 4가지 조직 프로세스로 구성
♾️ CMM/i: 소프트웨어 프로세스 실행 수준을 성숙시키기 위한 능력 심사와 결과에 따른 프로세스 개선 도구로 활용하며 초기 – 관리 – 정의 – 정량적 관리 – 최적화 5단계로 성숙도를 관리
♾️ ISO/ICE 15504(SPICE): ISO9000에서 프로세스 개선 활동과 성숙도 기반의 평가지침을 보완하기 위해 개발
 
🚩프로덕트 품질
: 구현된 제품의 품질로 소프트웨어 제품의 품질이 기술되고 평가될 때 적용되는 속성과 품질을 나타내는 변수들을 품질특성이라고 한다. 이를 다루기 위한 표준은 ISO/IEC 9126, ISO/IEC 14598에서 자세히 다룬다.
 




 

품질관리 프로세스

품질관리 프로세스는 품질계획 프로세스, 품질보증(QA) 프로세스, 품질통제(QC) 프로세스로 구성되며 품질시스템에서 이러한 프로세스를 거쳐 품질정책, 목표, 책임 그리고 그것의 구현을 결정을 총괄하는 관리기능 활동이다.
 
🚩품질 계획
 : 품질 표준이 프로젝트에 적절한지 식별하고 그것을 어떻게 만족시켜야 하는지를 결정한다. 이는 프로젝트 계획에서 매우 중요한 단계이며 프로젝트 계획의 다른 활동들과 병행되어 정기적으로 진행한다. 
 
🚩품질보증
: 프로젝트의 프로세스 및 산출물에 대해 검증, 확인, 검토, 감리 및 품질보증 활동을 개선하여 프로젝트 요구사항을 충족하도록 관리한다. 이는 프로젝트 품질 표준을 충족한다는 확신을 고객에게 제공하기 위해 품질시스템에서 정의된 체계적인 품질보증 활동을 하기 위함이다. 
 
🚩품질통제
:  프로젝트 작업 결과가 품질 표준에 부합하기 위해 작업 결과물이 품질 표준에 적합한지를 감시하고 불만족스러운 결과에 대해서는 원인을 제거하는 방법을 제시한다. 이때 쓰이는 도구나 기술은 보통 inspection, Pareto diagram, 표본추출검사, 원인 결과분석 등이 있다.
 
 

CMMI(Capability Maturity Model Integration)

CMMI는 2000년 미국 국방성의 지원으로 산업계와 정부, 카네기멜론대학의 소프트웨어공학 연구소(SEI)가 공동으로 개발한 CMM의 후속 모델이다. 이는 CMM의 종류가 너무 많이 생긴 문제점을 개선하기 위해 개발되었는데 여러 입장에서 각각의 모델별로 별개 적용하는 것이 아닌 전체 관점에서 적용하기 위한 툴로 보면 된다. 즉, 기존 CMM이 소프트웨어 개발모델에 한정된 것과 달리 시스템과 소프트웨어 영역을 통합하여 기업의 프로세스 개선 활동을 광범위하게 지원하는 것이 주된 특징이다. 
 
CMMI는 모델이다. 이것은 과정이 아니며 소프트웨어 개발 및 시스템 엔지니어링에서 사용 중인 것으로 입증된 일련의 조직 동작을 제공한다. 이런 방법에 모델을 사용하는 이유는 프로세스 개선 작업에는 조직 작동 방식, 필요한 기능 및 해당 기능이 상호 작용하는 방식이 필요하며 모델은 이를 충족하고 지원할 수 있기 때문이다. 이러한 모델을 사용할 때 이점이라면 의사소통에 도움이 되는 공통 프레임워크 및 언어를 제공하는 것이 가장 크다 할 수 있고 합의된 표준 제공으로 여러 불일치를 해결하는 데 도움을 줄 수 있기 때문이다.
 
 
 
 
※ 품질 책임!
얼마 전 복지시스템을 신규시스템인 차세대 사회보장 정보시스템 “행복e음”으로 교체하면서 발생한 오류로 여러 유관기관의 업무가 마비된 사건이 있었다. 그 실상이 낱낱이 밝혀지며 특정 누구 한 사람의 잘못이 아닌 이 프로젝트 참여한, 정부를 비롯한 모든 이해당사자의 안일함과 무책임함에, 한마디로 총체적 난국인 상황에 모두가 말을 잃었다. 과연 이러한 저품질 산출물은 어떻게 만들어졌고 왜 오픈을 강행했던 것인가? 정말 아무도 이 품질 상태를 보지 못한 것이었을까?