24. 프로젝트 조직 & CMMI

 

DO-178B에서 기대하는 라이프사이클 프로세스와 데이터를 개발하는 것이 왜 그렇게 오래 걸리는 걸까? - 이 문서를 읽는 모든 사람들은 빠른 길을 찾으려고 하고. 프로젝트를 수행하는데 필요로 하는 네 가지 유형의 사람들이 있다. 그것을 개발하는 사람, 개발자들이 그것을 제대로 하고 있는지를 검증하고 정확성을 확인하는 사람, 표준을 따랐는지 그리고 모든 것이 정의되었는지를 질문하는 QA 사람들 그리고 마지막으로 DER이다. 그런 방식으로, 우리는 각각을 혼돈할 수 없다.

프로젝트 조직   DO-178B 프로젝트에 필요로 하는 사람의 최소 숫자는 얼마인가? 최적의 숫자는 얼마인가? 조직은 어떻게 보이는가? 형상관리는 별도의 사람이 필요한가?

 

형상관리는 별도의 사람이 필요한가? 만약 당신이 대규모의 프로젝트, 예를 들면 30명 이상의 엔지니어를 가지는 프로젝트를 진행한다면 한 명을 가지는 것을 추천한다. 왜냐하면 형상관리는 그 자체로 훈련이 필요한 일이기 때문이다. 오늘날 툴은 복잡하다. 소프트웨어의 빌드를 위해서 “형상관리 담당자”를 사용하는 것에 더해서 형상관리 시스템에 무엇이 저장되는지 그리고 보증되지 않는 변경이 없는지를 보장하는 매뉴얼 프로세스가 필요할 것이다.

 

형상관리에는 네 가지 주요 항목이 있다. 문제점 리포팅, 변경 컨트롤, 상태, 그리고 버전 구분이다. 형상관리는 특히 30명 이상의 사람이 포함된 거대한 프로그램에서는 반드시 형상관리 담당자를 지정해야 한다. 작은 규모의 소프트웨어를 개발하는 5명에서 7명의 팀조차도 얼마나 자주 시스템을 재빌드하고 재컴파일하게 되는가? 당신은 재빌드와 재컴파일을 수행하는 형상관리 담당자를 가지고 있어야 한다. 그래야 항상 동일한 방법으로 진행하게 된다. 그렇게 함으로써 누군가 한밤중에 충돌을 일으키는 체크아웃을 하고 변경을 했다는 것을 알게 된다. 그것은 추가 인력이지만 그 만한 가치가 있을 것이다.

역주) 형상관리는 어떤 방법으로 진행해야 한다는 원칙이 있는 것이 아니다. DO-178에서는 형상관리가 잘 이루어진다는 것을 다음과 같은 기준으로 판단한다.   -       인증과 관련된 산출물은 모두 형상관리에 등록되고 관리되고 있다. -       형상관리에 모든 변경 이력이 남고 허가되지 않은 변경이 발생하지 않는다. -       언제나 동일한 자료를 형상관리 시스템을 통해서 확인할 수 있다.   물론 이 외에도 여러가지가 있겠지만 DO-178에서의 핵심은 위의 내용으로 보면 된다. 그리고 이것을 달성할 수 있다면 형상관리 담당자가 1명이든 10명이든 관계가 없다.

 

전형적인 중간 규모에서 거대 규모의 프로젝트 팀은 어떤 모습일까? 아래 다이어그램은 아주 전형적이다. 하지만 기억하자. DO-178B는 프로젝트 팀, 예산 혹은 일정을 정의하지 않는다. 당신이 그것들을 정의한다.

프로젝트 조직 대부분의 항공전자 조직은 80% 유사성을 가진다.

 

CMM에 대해서 친숙하지 않을지 모르겠지만, 그것은 카네기 멜른 대학의 Software Engineering Institute(SEI)를 통해서 개발되었다. 책임자였던 Watts Humphrey는 1980년대에 미국방성으로부터 거대 규모의 소프트웨어 개발에서 판매자들을 평가하는 방법을 고안해 줄 것을 요청받았다. 미국방성은 시스템이 동작해야 하는 것을 말하는 것이 아니라 단지 특정 요구사항이 있다는 것으로 계약을 진행하고 있었다. 그들은 제대로 동작할 무엇인가를 만들어 낼 능력을 가진 회사를 어떻게 찾아낼 지 알아낼 필요가 있었다.

카네기 멜른 대학 Software Engineering Institute(SEI)   소프트웨어 조직을 평가하고 등급을 매기는 방법을 고안 “Capability Maturity Model”(CMM: 비록 의도한 것은 아니지만 대학교의 초성과 비슷한) 왜 그 약어를 사용하는가?

 

카네기 멜른 대학에서 Watts는 소프트웨어 조직에 대한 평가방법과 등급을 정하는 방법을 개발할 것을 요청받았는데 그 결과가 Capability Maturity Model(약어인 CMM은 암묵적으로는 관련된 연구소인, 예를 들면 카네기 멜른 모델(Carnegie Mellon Model)로도 알려져 있다) 이었다.

SEI의 조사결과   소프트웨어는 창조적인 예술이지만 프로세스에 기반한다. 좋은 조직은 더 나은 소프트웨어를 생산한다. 소프트웨어 조직은 많은 목표 기준을 가지고 있다. 조직 성숙도는 평가되고 등수가 매겨질 수 있다.

 

그 연구소는 소프트웨어가 창조적인 예술이지만 프로세스 기반이라는 것을 발견했다. 그래서 우리들 소프트웨어 엔지니어들은 예술을 창조하지만 그 예술을 컨트롤하고 예상하기 위해 프로세스에 두게 된다.

 

다음은 무엇이 좋은 조직이냐에 대한 질문이다. CMM 모델은 정량적인 용어로 그것을 기술하려고 노력한다. 일부 정성적인 리뷰와 평가가 수행되지만 좋은 조직을 정의하려고 노력한다. 그러한 기술과 성숙도 사이에는 상관관계가 있고 소프트웨어의 품질이 거기에서 나온다. 품질에 대해서 미국방성이 의미하는 것은 그것이 제대로 동작하고 예산과 일정을 잘 지키는 것이다. 그것은 또한 DO-178B가 달성하려고 노력하는 것이자 FAA가 달성하려고 노력하는 것인가?

SEI가 고안한 CMM   Capability Maturity Model: CMM 소프트웨어 조직을 1 ~ 5로 등급을 매김(5 = 가장 높은) 진화하는: 한 번에 한 레벨 씩 개선됨 당신이 성장하면서 어떤 레벨을 건너뛰는 것은 불가능

 

CMM 모델에 대해서 도달하게 되는 서열은 1 ~ 5이다. 5가 가장 높고 1이 가장 낮다. 당신은 어떻게 “1”이 될 수 있을까? 만약 당신이 소프트웨어를 개발한다면 당신은 1이다!

 

일반적으로, 조직은 1로 시작한다. 그것은 임시 방편이고 일반적으로는 직원들이 따를 수 있고 따라야 하는 계획을 가지고 있다면 레벨 2로 가게 된다. 조금 더 배우게 되고 그들의 프로세스가 좀 더 반복 가능하게 된다. 레벨 3에서는 회사가 관리되고 일관성 있게 반복 가능하며 그런 다음에는 지속적인 프로세스 개선과 측정 기준을 포함하는 4와 5로 가게 된다.

SEI CMM 성숙도 레벨   시작단계 반복가능(훈련된) 정의된(지속적인) 관리되는(예측가능한) 최적화(지속적인 개선)   각 레벨은 선행하는 레벨의 완전한 상위집합이다

 

레벨 3은 지속적이다. 반복가능하고 훈련을 가지고 있을 뿐만 아니라 지속적으로 동일한 결과를 얻게 되고 관리된다. 레벨 4는 예측가능하다.

 

최적화(지속적인 개선). 만약 당신이 CMM 모델에서 그것을 읽는다면 그것은 당신이 그것을 개선하기 위해서 함께 작업하고 있다는 것을 의미한다. 그 시스템에서는 모든 사람들이 그 프로세스를 따르고 있는지를 확인하라. 만약 당신이 모든 것을 개선하고 있고 최적화하고 있다면 당신은 그것을 체크할 다른 누군가가 필요하다. 레벨 5에서는 당신은 QA 조직을 가져야만 한다. 레벨 1에서는 가장 하위의 프로세스들이 정의되고 거기에는 독립성이 필요하지 않다.

SEI CMM 레벨 1   가장 하위 레벨 기본적인 프로세스가 정의됨 독립성이 거의 없음 일관성이 거의 없음 임시 방편의

 

레벨 1은 대개 코드를 작성하는 사람이 또한 그 코드를 검증하고 형상관리도 하는(그리고 아마도 창고를 청소할) 상업적인 개발 조직이다. 거기에는 하나의 프로그램에서 다른 프로그램으로 이어지는 일관성이 거의 없다. 그리고 거기에는 많은 취약점이 있지만 당신은 그것이 전부 어디인지조차도 모른다. 매우 임시방편적이다.

 

SEI CMM 레벨 2   레벨 1의 상위집합 완전하게 정의된 프로세스들 일반적인 일관성 비공식적 리뷰 약한 형상관리 지속적이지 않은 훈련 임시방편의 시험

 

레벨 2는 ISO에 의해서 완전하게 정의된 소프트웨어 개발 프로세스를 가지고 있다. 당신은 그것을 따를 필요는 없지만 ISO는 그것을 정의하며 어느 정도는 프로젝트에 적용된다.

 

일반적인 일관성은 프로그램에서 프로그램으로 전이되는 것으로 모든 사람이 동일한 언어로 이야기하는지를 확인하는 것이고 동일한 절차와 프로세스를 사용하는 것이다. 거기에는 비공식적인 리뷰, 비공식적인 분석과 방법론이 있다. 누군가는 말한다. “우리는 문서에 대한 리뷰를 가지고 있습니다. 그래요, 우리는 모두 그 수준에 있는 것이죠. 우리는 아주 양호하다고 생각합니다.” 그것은 취약한 프로세스이지만 실제로 소프트웨어를 개발하는 덜 성숙한 회사들에게 상당히 전형적인 형태이다. 일반적으로 우리는 초보적인 형상관리 시스템과 어느 정도 단정하게 정의된 프로세스와 체크리스트를 가지고 있다. 개발자들은 코드를 체크인, 체크아웃하고 변경하는 등의 작업을 수행한다. 변경이 적절한지 않은지에 대해서는 아무도 체크하지 않는다. 1년 후에 다시 돌아와서 VSS(Visual Source Safe) 시스템을 조사해보면 저장된 데이터의 반도 찾을 수 없다. 혹은 제대로 된 버전을 가지고 있지 않을 수 있다. 아마도 빌드 스크립트도 없을 것이다. 실행파일은 소스를 컴파일 하더라도 일치하지 않을 것이다. 형상관리와 품질보증의 일부가 있겠지만 일관성이 없을 것이다.

 

일관성없는 훈련(만약에 조금이라도 있다면). 제대로 된 훈련은 중요하다. 주로 베타테스트로 수행되는 임시방편의 시험은 디버깅을 해서 시스템을 빌드한 후에 누군가에게 전달해서 이런 저런 형태로 사용해 보도록 하거나 기본적인 사용자 중심의 시험을 수행하는 것이다. 당신의 PC상에서 실행하는 소프트웨어의 상당 부분은 이런 식으로 개발되었다. 하지만 그것은 여전히 임시방편이고 실제로 컨트롤되는 것이 아니다.

역주) 느낌이 올 지 모르겠지만 여기서 저자가 이야기하는 레벨 중 레벨 3을 획득하기도 상당히 어려운 것이 사실이다. 물론 제대로 시스템이 갖춰진 회사도 있겠지만 그런 회사들 조차도 DO-178이 요구하는 수준으로 진행하고 있다고 보기 어려운 것이 사실이다. 아마도 이 글을 보고 있는 대부분의 사람들에게는 레벨 2가 현실적인 수준이라고 할 수 있다. 중요한 것은 이런 현실을 인식하고 개선을 할 수 있느냐이다. 실제로 DO-178을 제대로 수행하려고 노력하게 되면 레벨 3 이상으로 충분히 레벨업 할 수 있다.

 

SEI CMM 레벨 3   레벨 2의 상위집합 완전한 일관성 독립성 완전한 리뷰 훈련 반복가능한 베이스라인 확실한 형상관리

 

레벨 3(레벨 1부터 레벨 2를 거쳐 개선된 후의)은 완전히 일관적이다. 프로그램에서 프로그램으로 전이되면서 동일한 프로세스와 리뷰 기술, 방법론이 일관성을 가진다. 독립성은 완전하게 정의된다. 테스터는 모든 코드를 일관성있게 시험하며 QA가 존재한다. 대부분의 주요 산출물들에 대한 리뷰가 수행되고 일관성있는 표준과 체크리스트가 적용된다. 이 지점에서 당신은 개발자가 리뷰어가 되는 것을 원하지 않는다. 무언가가 올바르다는 것을 확인하기 위한 두 쌍의 눈이 필요하다.

 

체크리스트와 관련된 완전한 리뷰는 레벨 3에 존재한다. 레벨 3의 회사는 QA 뿐만 아니라 개발자, 관리자 그리고 검증자에 대한 완전한 훈련을 수행한다.

 

반복가능한 베이스라인 – 훌륭한 형상관리. 당신은 1년 후에 다시 돌아와서도 완전히 동일한 코드를 반복하고 빌드할 수 있다. 코드와 함께하는 모든 문서와 개발 사이클을 찾을 수 있다. 형상관리는 확실하다. 당신은 역으로 추적할 수 있고 모든 정보를 발견할 수 있다.

SEI CMM 레벨 4   레벨 3의 상위집합 지속적인 프로세스 개선을 위한 피드백 프로세스 측정 기준

 

레벨 4는 피드백 프로세스, 지속적인 프로세스 개선 그리고 측정 기준을 추가한다. 당신은 관리, 추적성, 소프트웨어 품질, 일정이 얼마나 효율적인지, 당신이 얼마나 예측가능한지, 번다운 비율과 번다운 차트를 얼마나 빨리 만들어 낼 수 있는지, 그리고 얼마나 많은 요구사항이 얼마나 많은 시간을 소요하게 되는지를 체크하기 시작한다.

SEI CMM 레벨 5   레벨 4의 상위집합 치밀하고 철저한 조사 여러 레벨의 리뷰 완전하고 성숙한 프로젝트 관리 완벽에 가까움 하지만 어느 정도의 비용으로?

 

레벨 5(우리는 열반에 도달했다!) 는 치밀하고 철저한 조사가 이루어 진다. 모든 단계와 전이 기준에서 여러 레벨의 리뷰를 가진 프로세스 관점에서는 모든 것이 거의 완벽에 가깝다. 완전하고 성숙한 프로젝트 관리이다.

 

프로젝트 관리에 대한 모든 훈련을 수행하며 모든 케이스를 어떻게 해야 하는지를 알고 있다. 거의 완벽에 가까우며 수행하기에는 비용이 많이 든다. 어떤 회사들은 그들이 레벨 5를 달성했다고 말하지만 그것은 단지 마케팅적인 해석일 뿐일 지 모른다. 만약 어떤 회사에서 어떤 영역이 레벨 5로 평가를 받는다면 그것은 일반적으로 몇 년 동안 함께 일하고 자신들을 위해 진행하는 훌륭한 프로세스를 가진 시너지 효과를 가진 그룹이다.

 

이것이 기본적인 CMM에 대한 설명이다. 하지만 항공전자 소프트웨어에 대한 책에서 설명하는 CMM은 무엇인가? DO-178B가 필요로 하거나 혹은 CMM이나 이제는 CMMI를 암시하기라도 하는가? 기억하자. DO-178B와 DO-254는 특정한 개발 방법론을 규정하지 않으며 거기에는 CMM/CMMI를 절대 언급하지 않는다. 하지만 사실상 상관관계는 있다. 항공전자 개발자들은 프로세스가 필요하며 그것들은 정의되고 따라야 한다. 그리고 핵심 관계자들(QA, DER, 그리고 FAA)은 그런 프로세스들이 오랜 시간에 걸쳐서 개선되는 결과를 보여줄 정도로 충분하다는 것을 확인해야 한다. 따라서 “항공전자 개발자는 어떤 레벨에 도달해야 하는가?”라는 질문에 대한 대답으로 우리의 의견으로는 그 답은 분명하게 정의되고 일관성있게 준수하는 프로세스인 레벨 3이다. 왜 레벨 4 혹은 5가 아닌가? 확실히 받아들여질 만한 동안에는 당신의 프로세스가 지속적으로 개선될 필요는 없다. 왜냐하면 분명히 출발시점에서, 처음부터 DO-178B/DO-254를 만족하기 충분할 만큼 훌륭할 것이기 때문이다. 결국 만약 당신의 프로세스를 지속적으로 개선해야만 한다면 그런 개선에 앞서서 진행되는 개발에 대해서는 어떤가? 다시 해야 하는가?

전형적인 항공전자 조직   미국 항공전자팀의 평균 레벨은 무엇인가? 당신 팀의 레벨은 무엇인가? 항공전자팀은 어떤 레벨이 되어야 하는가?

 

항공전자팀은 어떤 레벨이 되어야 하는가? 레벨 3? 엄격한 형상관리, 독립성 그리고 리뷰는 DO-178B를 시작하는 데 충분하다는 것을 기억하라. 만약 당신이 엄격한 레벨 3 CMM 조직이라면 당신은 아마도 DO-178B가 원하는 것의 70 ~ 80%를 만족할 것이다. 하지만 우리의 의견으로는 평균적인 항공전자팀은 레벨 2이다. 이 책의 저자들은 전세계 최고 수준의 100여개 항공전자 회사들과 일해왔고 이 의견에 대한 준비가 되어 있다. 레벨 2가 좋지 않은 상태인가? 절대 그렇지 않다. 오늘날 대부분의 항공기들은 레벨 2 조직에 의해서 개발된 정교한 소프트웨어로 완벽하게 비행하고 있다. 그럼 그 의미는 무엇인가? 솔직히 말하면 레벨 2 조직은 아주 불충분하며 예산과 일정을 충족하는 것에 실패할 것이 거의 확실하다. 하지만 어쨌든 예산과 일정 관리는 일반적으로 레벨 2 조직의 일부는 아니다. 따라서 그들이 얼마나 불충분한지를 인식조차 하지 못한다.

 

레벨 2 조직은 최종 결과를 달성하기 위해 더 많은 힘이 필요하다. 영구적으로 브레이크가 걸려있는 자동차의 경우 더 큰 엔진으로 추가된 브레이크 영향을 극복할 수 있다. 하지만 그 엔진은 더 비싸고 연료를 더 많이 소비한다. 레벨 2 회사들은 그들의 작업을 다시 수행하고 인증에 도달하는 과정에서 반복하는데 더 많은 에너지가 필요하다.

 

기회는 당신이 경쟁자들을 가지고 있다는 것이고 장기간의 시장 성공은 경쟁에 달려있다. 레벨 3은 레벨 4의 특성을 일부 가지고 있는(훈련, 품질 기준, 등의 증명), 당신이 도달하고자 하는 곳이다.

역주) CMM에 대한 장황한 설명이 이어졌지만 허무하게도(?) DO-178에서는 그것이 있든 없든 전혀 신경쓰지 않는다. 결국 DO-178 기준을 따르느냐 따르지 않느냐가 중요할 뿐이다. 워낙 CMM/CMMI가 유명하다 보니 그리고 실제로 관련해서 질문이 많다 보니 이렇게 연관성을 보여주는 것이다. 역자의 판단으로는 굳이 CMM/CMMI를 받아야 하는 상황이 아니라면 그냥 DO-178을 진행하면 된다. 그리고 장담하건데 DO-178을 제대로 수행하게 되면 자연스럽게 여기서 말하는 CMM 레벨 3 이상은 충분히 얻을 수 있는 자격을 갖출 수 있을 것이다.   저자가 설명하는 내용 중에 중요한 부분이 하나 있다. DO-178 인증을 받고자 하는 관점에서는 레벨 4 혹은 레벨 5까지 도달할 필요는 없다는 점이다. 저자의 요지는 레벨 4, 5는 그야말로 완벽을 추구하는 단계이고 그 말은 현실적으로 돈과 시간이 엄청나게 들게 된다는 것인데 완벽한 개발 조직을 만들면 당연히 좋겠지만 그걸 위해서 무한정 돈과 시간을 들이지는 말라는 것이다. 굳이 그렇게 완벽하지 않아도 DO-178 인증을 받을 수 있다. 혹시라도 CMM/CMMI를 계획하고 있다면, 그리고 DO-178도 고려하고 있다면 이 점을 참고하시기 바란다.