소프트웨어 프로세스 평가

소프트웨어 프로세스 평가는 프로세스 모델을 기반으로 조직에서 사용하는 소프트웨어 프로세스에 대한 체계적인 검사입니다. 평가에는 현재 관행의 식별 및 특성화, 강점과 약점의 영역 식별, 불량 (소프트웨어) 품질, 비용 및 일정의 중요한 원인을 제어하거나 방지하는 현재 관행의 능력이 포함됩니다.

소프트웨어 평가 (또는 감사)는 세 가지 유형이 있습니다.

ㅏ self-assessment (first-party assessment) 조직의 자체 직원이 내부적으로 수행합니다.
ㅏ second-party assessment 외부 평가 팀에 의해 수행되거나 조직이 고객에 의해 평가됩니다.
ㅏ third-party assessment 외부 당사자가 수행하거나 (예 : 고객과 계약을 체결 할 수 있는지 확인하기 위해 제 3자가 평가하는 공급 업체).

소프트웨어 프로세스 평가는 개방적이고 협업적인 환경에서 수행됩니다. 이는 조직이 소프트웨어 프로세스를 개선하는 데 사용되며 결과는 조직에 기밀로 유지됩니다. 평가 대상 조직에는 평가 팀 구성원이 있어야합니다.

소프트웨어 프로세스 성숙도 평가

소프트웨어 프로세스 평가의 범위는 조직의 모든 프로세스, 소프트웨어 프로세스의 선택된 하위 집합 또는 특정 프로젝트를 포함 할 수 있습니다. 대부분의 표준 기반 프로세스 평가 접근 방식은 항상 프로세스 성숙도의 개념을 기반으로합니다.

평가 대상이 조직인 경우 동일한 방법을 연속적으로 적용하더라도 프로세스 평가의 결과가 다를 수 있습니다. 다른 결과에는 두 가지 이유가 있습니다. 그들은,

조사중인 조직이 결정되어야합니다. 대기업의 경우 조직에 대한 여러 정의가 가능하므로 실제 평가 범위는 연속적인 평가에서 다를 수 있습니다.
동일한 조직으로 보이는 경우에도 조직을 대표하기 위해 선택된 프로젝트 샘플이 범위와 결과에 영향을 미칠 수 있습니다.

평가 대상 단위가 프로젝트 수준에있을 때 평가에는 프로젝트의 성공 또는 실패에 기여하는 모든 의미있는 요소가 포함되어야합니다. 주어진 프로세스 성숙도 모델의 확립 된 차원에 의해 제한되어서는 안됩니다. 여기에서 프로젝트 데이터로 입증 된 구현 정도와 그 효과를 평가합니다.

프로세스 성숙도는 조직이 전반적인 장기 개선 전략에 착수하려는 경우 관련이 있습니다. 소프트웨어 프로젝트 평가는 객관적이기 위해 독립적 인 평가 여야합니다.

소프트웨어 프로세스 평가주기

Paulk 및 동료 (1995)에 따르면 CMM 기반 평가 접근 방식은 6 단계주기를 사용합니다. 그들은-

팀 선택-팀 구성원은 소프트웨어 엔지니어링 및 관리에 정통한 전문가 여야합니다.
평가할 사이트의 대표자가 표준 프로세스 성숙도 설문지를 작성합니다.
평가 팀은 설문 응답을 분석하고 CMM 핵심 프로세스 영역에 따라 추가 탐색이 필요한 영역을 식별합니다.
평가 팀은 사이트 방문을 수행하여 사이트가 따르는 소프트웨어 프로세스를 이해합니다.
평가 팀은 조직의 소프트웨어 프로세스의 강점과 약점을 식별하는 결과 목록을 생성합니다.
평가 팀은 KPA (핵심 프로세스 영역) 프로필 분석을 준비하고 결과를 적절한 청중에게 제공합니다.

예를 들어 평가 팀은 공인 SEI 수석 평가자가 이끌어야합니다. 팀은 4-10 명의 팀원으로 구성되어야합니다. 최소한 한 명의 팀원이 평가 대상 조직 출신이어야하며 모든 팀원은 SEI의 CMM 소개 과정 (또는 이에 상응하는 과정) 및 SEI의 CBA IPI 팀 교육 과정을 이수해야합니다. 팀원도 몇 가지 선택 지침을 충족해야합니다.

데이터 수집과 관련하여 CBA IPI는 네 가지 방법에 의존합니다.

표준 성숙도 설문지
개인 및 그룹 인터뷰
문서 검토
평가 참가자와 함께 결과 초안 검토를 통한 피드백

사기

프로세스 개선을위한 표준 CMMI 평가 방법 (SCAMPI)은 CMMI 모델 요구 사항을 충족하기 위해 개발되었습니다 (Software Engineering Institute, 2000). 또한 CBA IPI를 기반으로합니다. CBA IPI와 SCAMPI는 모두 세 단계로 구성됩니다.