소프트웨어 품질 관리-빠른 가이드

품질 소프트웨어는 합리적으로 버그 나 결함이없고 정해진 예산 내에서 제때에 제공되고 요구 사항 및 / 또는 기대를 충족하며 유지 관리 할 수있는 소프트웨어를 의미합니다. 소프트웨어 엔지니어링 맥락에서 소프트웨어 품질은functional quality 만큼 잘 structural quality.

  • Software Functional Quality − 기능적 요구 사항 또는 사양에 따라 주어진 설계를 얼마나 잘 충족하는지 반영합니다.

  • Software Structural Quality − 견고성 또는 유지 보수 가능성과 같은 기능적 요구 사항의 전달을 지원하는 비 기능적 요구 사항의 처리 및 소프트웨어가 올바르게 생산 된 정도를 다룹니다.

  • Software Quality Assurance− SQA (Software Quality Assurance)는 궁극적으로 고품질 소프트웨어 제품을 만드는 소프트웨어 엔지니어링 프로세스의 품질을 보장하기위한 일련의 활동입니다. 활동은 제품을 생산하는 프로세스를 설정하고 평가합니다. 프로세스 중심의 행동이 포함됩니다.

  • Software Quality Control− 소프트웨어 품질 관리 (SQC)는 소프트웨어 제품의 품질을 보장하기위한 일련의 활동입니다. 이러한 활동은 생산 된 실제 제품의 결함을 결정하는 데 중점을 둡니다. 제품 중심의 행동이 포함됩니다.

소프트웨어 품질 문제

소프트웨어 산업에서 개발자는 다른 산업 제품 제조업체가 일반적으로하는 것과 달리 소프트웨어에 결함이 없다고 선언하지 않습니다. 이 차이는 다음과 같은 이유 때문입니다.

제품 복잡성

제품이 허용하는 작동 모드의 수입니다. 일반적으로 산업용 제품은 기계 설정의 다양한 조합으로 수천 가지 미만의 작동 모드 만 허용합니다. 그러나 소프트웨어 패키지는 수백만 개의 운영 가능성을 허용합니다. 따라서 이러한 모든 운영 가능성을 올바르게 보장하는 것은 소프트웨어 산업의 주요 과제입니다.

제품 가시성

산업 제품이 눈에 잘 띄기 때문에 대부분의 결함은 제조 과정에서 감지 될 수 있습니다. 또한 산업용 제품에 부품이 없음을 제품에서 쉽게 감지 할 수 있습니다. 그러나 디스켓이나 CD에 저장된 소프트웨어 제품의 결함은 보이지 않습니다.

제품 개발 및 생산 프로세스

산업용 제품에서 결함은 다음 단계에서 감지 될 수 있습니다.

  • Product development −이 단계에서 설계자와 QA (품질 보증) 직원은 제품 프로토 타입을 확인하고 테스트하여 결함을 감지합니다.

  • Product production planning−이 단계에서 생산 공정과 도구를 설계하고 준비합니다. 이 단계는 또한 제품을 검사하여 개발 단계에서 발견되지 않은 결함을 감지 할 수있는 기회를 제공합니다.

  • Manufacturing−이 단계에서는 제품 자체의 고장을 감지하기 위해 QA 절차가 적용됩니다. 제조 첫 번째 기간에서 발견 된 제품의 결함은 일반적으로 향후 제조되는 제품의 결함을 제거하는 방식으로 제품의 디자인이나 재료 또는 생산 도구의 변경으로 수정할 수 있습니다.

그러나 소프트웨어의 경우 결함을 감지 할 수있는 유일한 단계는 개발 단계입니다. 소프트웨어의 경우 소프트웨어 사본 제작 및 소프트웨어 매뉴얼 인쇄가 자동으로 수행되므로 제품 생산 계획 및 제조 단계가 필요하지 않습니다.

소프트웨어 제품과 다른 산업용 제품의 결함 감지에 영향을 미치는 요소는 다음 표에 나와 있습니다.

특성 소프트웨어 제품 기타 산업 제품
복잡성 수백만 가지 운영 옵션 수천 가지 운영 옵션
제품 가시성 보이지 않는 제품 육안으로 결함을 감지하기 어려움 가시적 제품 육안으로 효과적인 결함 감지
개발 및 생산 과정의 특성 단 한 단계에서 결함 결함 다음 모든 단계에서 결함을 감지 할 수 있습니다.
  • 제품 개발
  • 제품 생산 계획
  • Manufacturing

복잡성 및 투명성과 같은 소프트웨어의 이러한 특성은 소프트웨어 품질 보증 방법론의 개발과 성공적인 구현을 매우 전문적인 과제로 만듭니다.

소프트웨어에 영향을 미치는 다양한 요인을 소프트웨어 요인이라고합니다. 크게 두 가지 범주로 나눌 수 있습니다. 요소의 첫 번째 범주는 논리적 오류 수와 같이 직접 측정 할 수있는 요소이고 두 번째 범주는 간접적으로 만 측정 할 수있는 요소를 분류합니다. 예를 들어 유지 보수성이지만 각 요소를 측정하여 내용물 및 품질 관리를 확인합니다.

소프트웨어 품질 요인의 여러 모델과 그 분류가 수년에 걸쳐 제안되었습니다. McCall이 제안한 소프트웨어 품질 요인의 고전적인 모델은 11 개의 요인으로 구성됩니다 (McCall et al., 1977). 마찬가지로, 12 ~ 15 개의 요소로 구성된 모델은 Deutsch와 Willis (1988)와 Evans와 Marciniak (1987)에 의해 제안되었습니다.

이 모든 모델은 McCall의 모델과 크게 다르지 않습니다. McCall 요인 모델은 소프트웨어 요구 사항을 분류하기위한 실용적인 최신 방법을 제공합니다 (Pressman, 2000).

McCall의 요인 모형

이 모델은 모든 소프트웨어 요구 사항을 11 가지 소프트웨어 품질 요소로 분류합니다. 11 가지 요소는 제품 운영, 제품 개정 및 제품 전환 요소의 세 가지 범주로 분류됩니다.

  • Product operation factors − 정확성, 신뢰성, 효율성, 무결성, 유용성.

  • Product revision factors − 유지 보수성, 유연성, 테스트 가능성.

  • Product transition factors − 이식성, 재사용 성, 상호 운용성.

제품 운영 소프트웨어 품질 요인

McCall의 모델에 따르면 제품 운영 범주에는 소프트웨어의 일상적인 운영에 직접적인 영향을 미치는 요구 사항을 다루는 5 가지 소프트웨어 품질 요소가 포함됩니다. 그들은 다음과 같습니다-

단정

이러한 요구 사항은 소프트웨어 시스템 출력의 정확성을 다룹니다. 그들은 포함합니다-

  • 출력 임무

  • 부정확 한 데이터 또는 부정확 한 계산으로 인해 부정적인 영향을받을 수있는 필요한 출력 정확도.

  • 불완전한 데이터의 영향을받을 수있는 출력 정보의 완전성.

  • 이벤트와 소프트웨어 시스템의 응답 사이의 시간으로 정의 된 정보의 최신 상태입니다.

  • 정보의 가용성.

  • 소프트웨어 시스템을 코딩하고 문서화하기위한 표준입니다.

신뢰할 수 있음

안정성 요구 사항은 서비스 실패를 처리합니다. 이들은 소프트웨어 시스템의 최대 허용 실패율을 결정하고 전체 시스템 또는 하나 이상의 개별 기능을 참조 할 수 있습니다.

능률

소프트웨어 시스템의 다양한 기능을 수행하는 데 필요한 하드웨어 리소스를 다룹니다. 여기에는 처리 기능 (MHz 단위), 저장 용량 (MB 또는 GB 단위) 및 데이터 통신 기능 (MBPS 또는 GBPS 단위)이 포함됩니다.

또한 휴대용 컴퓨터에있는 정보 시스템 장치 또는 실외에있는 기상 장치와 같은 시스템의 휴대용 장치의 재충전 사이의 시간을 다룹니다.

청렴

이 요소는 소프트웨어 시스템 보안을 다룹니다. 즉, 권한이없는 사람에 대한 액세스를 방지하고 읽기 및 쓰기 권한을 부여 할 사람 그룹을 구분합니다.

유용성

사용성 요구 사항은 신입 직원을 교육하고 소프트웨어 시스템을 운영하는 데 필요한 직원 리소스를 다룹니다.

제품 개정 품질 요인

McCall의 모델에 따르면 세 가지 소프트웨어 품질 요소가 제품 개정 범주에 포함됩니다. 이러한 요소는 다음과 같습니다-

유지 보수성

이 요소는 소프트웨어 오류의 원인을 식별하고 오류를 수정하며 수정의 성공 여부를 확인하기 위해 사용자 및 유지 관리 담당자가 필요한 노력을 고려합니다.

적응성

이 요소는 소프트웨어의 적응 형 유지 관리 활동을 지원하는 데 필요한 기능과 노력을 다룹니다. 여기에는 소프트웨어를 변경하지 않고 현재 소프트웨어를 추가 환경 및 고객에 맞게 조정하는 것이 포함됩니다. 이 요소의 요구 사항은 서비스를 개선하고 회사의 기술 또는 상업적 환경의 변화에 ​​적응하기 위해 소프트웨어 변경 및 추가와 같은 완벽한 유지 관리 활동도 지원합니다.

테스트 가능성

테스트 가능성 요구 사항은 소프트웨어 시스템의 테스트 및 작동을 다룹니다. 여기에는 사전 정의 된 중간 결과, 로그 파일 및 시스템을 시작하기 전에 소프트웨어 시스템에서 수행 한 자동 진단이 포함되어 시스템의 모든 구성 요소가 제대로 작동하는지 확인하고 감지 된 오류에 대한 보고서를 얻습니다. 이러한 요구 사항의 또 다른 유형은 소프트웨어 오류의 원인을 감지하기 위해 유지 관리 기술자가 적용하는 자동 진단 검사를 다룹니다.

제품 전환 소프트웨어 품질 요소

McCall의 모델에 따르면 소프트웨어를 다른 환경에 적용하고 다른 소프트웨어 시스템과의 상호 작용을 다루는 세 가지 소프트웨어 품질 요소가 제품 전환 범주에 포함됩니다. 이러한 요소는 다음과 같습니다-

휴대 성

이식성 요구 사항은 소프트웨어 시스템을 다른 하드웨어, 다른 운영 체제 등으로 구성된 다른 환경에 적용하는 경향이 있습니다. 소프트웨어는 다양한 상황에서 동일한 기본 소프트웨어를 계속 사용할 수 있어야합니다.

재사용 성

이 요소는 현재 개발중인 새로운 소프트웨어 프로젝트의 한 프로젝트를 위해 원래 설계된 소프트웨어 모듈의 사용을 다룹니다. 또한 향후 프로젝트에서 주어진 모듈 또는 현재 개발 된 소프트웨어의 모듈 그룹을 사용할 수 있습니다. 소프트웨어 재사용은 개발 자원을 절약하고 개발 기간을 단축하며 고품질 모듈을 제공 할 것으로 예상됩니다.

상호 운용성

상호 운용성 요구 사항은 다른 소프트웨어 시스템 또는 다른 장비 펌웨어와의 인터페이스 생성에 중점을 둡니다. 예를 들어, 생산 기계 및 테스트 장비의 펌웨어는 생산 제어 소프트웨어와 인터페이스합니다.

Software Quality Assurance(SQA)는 소프트웨어 엔지니어링 프로세스의 품질을 보장하기위한 일련의 활동입니다. 개발 된 소프트웨어가 정의되거나 표준화 된 품질 사양을 충족하고 준수하는지 확인합니다. SQA는 SDLC (Software Development Life Cycle) 내에서 진행중인 프로세스로, 개발 된 소프트웨어가 원하는 품질 측정 기준을 충족하는지 정기적으로 확인합니다.

SQA 관행은 사용되는 기본 소프트웨어 개발 모델에 관계없이 대부분의 소프트웨어 개발 유형에서 구현됩니다. SQA는 소프트웨어 테스트 방법론을 통합하고 구현하여 소프트웨어를 테스트합니다. 완료 후 품질을 확인하는 대신 SQA는 소프트웨어가 완료 될 때까지 각 개발 단계에서 품질 테스트를 처리합니다. SQA를 사용하면 현재 / 이전 단계가 필요한 품질 표준을 준수 할 때만 소프트웨어 개발 프로세스가 다음 단계로 이동합니다. SQA는 일반적으로 소프트웨어 품질 지침 및 구현 전략을 구축하는 데 도움이되는 하나 이상의 산업 표준에 따라 작동합니다.

다음 활동이 포함됩니다.

  • 프로세스 정의 및 구현
  • Auditing
  • Training

프로세스는-

  • 소프트웨어 개발 방법론
  • 프로젝트 관리
  • 구성 관리
  • 요구 사항 개발 / 관리
  • Estimation
  • 소프트웨어 디자인
  • 테스트 등

프로세스가 정의되고 구현되면 품질 보증은 다음과 같은 책임이 있습니다.

  • 프로세스의 약점 식별
  • 프로세스를 지속적으로 개선하기 위해 이러한 약점을 수정합니다.

SQA 시스템의 구성 요소

SQA 시스템은 항상 광범위한 SQA 구성 요소를 결합합니다. 이러한 구성 요소는 다음 6 가지 클래스로 분류 할 수 있습니다.

사전 프로젝트 구성 요소

이는 필요한 자원, 일정 및 예산을 고려하여 프로젝트 약속이 명확하게 정의되었음을 보장합니다. 개발 및 품질 계획이 올바르게 결정되었습니다.

프로젝트 라이프 사이클 활동 평가의 구성 요소

프로젝트 라이프 사이클은 개발 라이프 사이클 단계와 운영-유지 보수 단계의 두 단계로 구성됩니다.

개발 라이프 사이클 단계 구성 요소는 설계 및 프로그래밍 오류를 감지합니다. 구성 요소는 리뷰, 전문가 의견 및 소프트웨어 테스트와 같은 하위 클래스로 나뉩니다.

운영-유지 보수 단계에서 사용되는 SQA 구성 요소에는 주로 유지 보수 작업을 개선하기위한 기능에 적용되는 개발 라이프 사이클 구성 요소뿐만 아니라 특수 유지 보수 구성 요소가 포함됩니다.

인프라 오류 방지 및 개선의 구성 요소

조직 전체에 적용되는 이러한 구성 요소의 주요 목표는 조직의 축적 된 SQA 경험을 기반으로 오류 비율을 제거하거나 최소한 줄이는 것입니다.

소프트웨어 품질 관리의 구성 요소

이 구성 요소 클래스는 개발 및 유지 관리 활동의 제어, 주로 일정 및 예산 실패와 그 결과를 예방하거나 최소화하는 조기 관리 지원 조치 도입과 같은 여러 목표를 다룹니다.

표준화, 인증 및 SQA 시스템 평가의 구성 요소

이러한 구성 요소는 조직 내에서 국제 전문 및 관리 표준을 구현합니다. 이 수업의 주요 목표는 국제 전문 지식의 활용, 다른 조직과의 조직 품질 시스템의 조정 개선, 공통 척도에 따른 품질 시스템의 성과 평가입니다. 다양한 표준은 품질 관리 표준과 프로젝트 프로세스 표준의 두 가지 주요 그룹으로 분류 될 수 있습니다.

SQA 조직 – 인간 구성 요소

SQA 조직 기반에는 관리자, 테스트 담당자, SQA 부서 및 SQA 수탁자, SQA위원회 구성원 및 SQA 포럼 구성원과 같은 소프트웨어 품질에 관심이있는 사람이 포함됩니다. 주요 목표는 SQA 구성 요소의 구현을 시작 및 지원하고, SQA 절차 및 방법론의 편차를 감지하고, 개선 사항을 제안하는 것입니다.

사전 프로젝트 소프트웨어 품질 구성 요소

이러한 구성 요소는 프로젝트를 시작하기 전에 취한 예비 단계를 개선하는 데 도움이됩니다. 그것은 포함합니다-

  • 계약 검토
  • 개발 및 품질 계획

계약 검토

일반적으로 소프트웨어는 고객과 협상 된 계약 또는 하드웨어 제품에 내장 될 펌웨어를 개발하기위한 내부 주문을 위해 개발됩니다. 이러한 모든 경우에 개발 단위는 합의 된 기능 사양, 예산 및 일정에 전념합니다. 따라서 계약 검토 활동에는 프로젝트 제안 초안과 계약 초안에 대한 자세한 검토가 포함되어야합니다.

특히 계약 검토 활동에는 다음이 포함됩니다.

  • 고객의 요구 사항에 대한 설명

  • 프로젝트 일정 및 리소스 요구 사항 추정 검토

  • 제안 된 프로젝트를 수행하기위한 전문 직원의 능력 평가

  • 고객의 의무 이행 능력 평가

  • 개발 위험 평가

개발 및 품질 계획

동일한 조직의 조직 또는 내부 부서와 소프트웨어 개발 계약을 체결 한 후 프로젝트 개발 계획 및 통합 품질 보증 활동을 준비합니다. 이러한 계획에는 현재 제안 및 계약의 기초를 제공 한 이전 계획에 따라 추가 세부 정보와 필요한 수정 사항이 포함됩니다.

대부분의 경우 입찰 제출과 계약 체결 사이에 몇 개월이 걸립니다. 이 기간 동안 직원 가용성, 전문 역량과 같은 리소스가 변경 될 수 있습니다. 그런 다음 계획은 중간에 발생한 변경 사항을 반영하도록 수정됩니다.

프로젝트 개발 계획에서 다루는 주요 문제는 다음과 같습니다.

  • Schedules
  • 필요한 인력 및 하드웨어 리소스
  • 위험 평가
  • 조직 문제 : 팀원, 하청 업체 및 파트너십
  • 프로젝트 방법론, 개발 도구 등
  • 소프트웨어 재사용 계획

프로젝트의 품질 계획에서 다루는 주요 문제는 다음과 같습니다.

  • 적절한 측정 가능한 용어로 표현 된 품질 목표

  • 각 프로젝트 단계 시작 및 종료 기준

  • 검토, 테스트 및 기타 예정된 검증 및 검증 활동 목록

소프트웨어 메트릭은 세 가지 범주로 분류 할 수 있습니다-

  • Product metrics − 크기, 복잡성, 디자인 기능, 성능 및 품질 수준과 같은 제품의 특성을 설명합니다.

  • Process metrics − 이러한 특성은 소프트웨어의 개발 및 유지 관리 활동을 개선하는 데 사용될 수 있습니다.

  • Project metrics−이 메트릭은 프로젝트 특성 및 실행을 설명합니다. 예를 들어 소프트웨어 개발자 수, 소프트웨어 수명주기 동안의 인력 패턴, 비용, 일정 및 생산성이 있습니다.

일부 메트릭은 여러 범주에 속합니다. 예를 들어 프로젝트의 프로세스 중 품질 메트릭은 프로세스 메트릭과 프로젝트 메트릭입니다.

Software quality metrics제품, 프로세스 및 프로젝트의 품질 측면에 초점을 맞춘 소프트웨어 메트릭의 하위 집합입니다. 이는 프로젝트 메트릭보다 프로세스 및 제품 메트릭과 더 밀접하게 관련됩니다.

소프트웨어 품질 메트릭은 세 가지 범주로 더 나눌 수 있습니다.

  • 제품 품질 메트릭
  • 공정 중 품질 메트릭
  • 유지 관리 품질 메트릭

제품 품질 메트릭

이 메트릭에는 다음이 포함됩니다.

  • 평균 고장 시간
  • 결함 밀도
  • 고객 문제
  • 고객 만족

평균 고장 시간

실패 사이의 시간입니다. 이 측정 항목은 주로 항공 교통 제어 시스템, 항공 전자 공학 및 무기와 같은 안전에 중요한 시스템에 사용됩니다.

결함 밀도

코드 라인 또는 기능 포인트 등으로 표현되는 소프트웨어 크기에 대한 결함을 측정합니다. 즉, 단위당 코드 품질을 측정합니다. 이 메트릭은 많은 상용 소프트웨어 시스템에서 사용됩니다.

고객 문제

고객이 제품 사용시 발생하는 문제점을 측정합니다. 여기에는 결함 문제와 함께 비결 함 지향 문제를 포함하는 소프트웨어의 문제 공간에 대한 고객의 관점이 포함됩니다.

문제 측정 항목은 일반적으로 다음과 같이 표현됩니다. Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

어디,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

PUM은 일반적으로 소프트웨어가 시장에 출시 된 후 매월 계산되며 연도 별 월 평균도 계산됩니다.

고객 만족

고객 만족도는 종종 5 점 척도로 고객 설문 조사 데이터로 측정됩니다.

  • 매우 만족
  • Satisfied
  • Neutral
  • Dissatisfied
  • 매우 불만족 하였다

제품의 전반적인 품질 및 특정 치수에 대한 만족도는 일반적으로 다양한 고객 설문 조사 방법을 통해 얻습니다. 5 점 척도 데이터를 기반으로 분석 목적에 따라 약간의 변동이있는 여러 메트릭을 구성하고 사용할 수 있습니다. 예를 들면-

  • 완전히 만족 한 고객 비율
  • 만족 한 고객 비율
  • 불만족 한 고객 비율
  • 만족하지 못한 고객 비율

일반적으로이 만족도 비율이 사용됩니다.

공정 중 품질 지표

In-process 품질 메트릭은 일부 조직의 공식 머신 테스트 중에 결함 도착 추적을 처리합니다. 이 측정 항목에는 다음이 포함됩니다.

  • 기계 테스트 중 결함 밀도
  • 기계 테스트 중 결함 도착 패턴
  • 위상 기반 결함 제거 패턴
  • 결함 제거 효과

기계 테스트 중 결함 밀도

공식적인 기계 테스트 (코드가 시스템 라이브러리에 통합 된 후 테스트) 중 결함률은 현장의 결함률과 상관 관계가 있습니다. 테스트 중에 발견 된 더 높은 결함률은 더 높은 테스트 결함률이 특별한 테스트 노력으로 인한 것이 아니라면 소프트웨어가 개발 프로세스 중에 더 높은 오류 주입을 경험했음을 나타냅니다.

KLOC 또는 기능 포인트 당이 간단한 결함 메트릭은 소프트웨어가 아직 테스트되는 동안 품질을 나타내는 좋은 지표입니다. 동일한 개발 조직에서 제품의 후속 릴리스를 모니터링하는 데 특히 유용합니다.

기계 테스트 중 결함 도착 패턴

테스트 중 전체 결함 밀도는 결함 요약 만 제공합니다. 결함 도착 패턴은 현장의 다양한 품질 수준에 대한 자세한 정보를 제공합니다. 그것은 다음을 포함합니다-

  • 시간 간격 (예 : 주)별로 테스트 단계 동안보고 된 결함 도착 또는 결함. 여기에서 모두 유효한 결함이 아닙니다.

  • 보고 된 문제점에서 문제점 판별이 수행 될 때 유효한 결함 도착 패턴입니다. 이것이 진정한 결함 패턴입니다.

  • 결함 백 로그 초과 근무 패턴입니다. 이 메트릭은 개발 조직이보고 된 모든 문제를 즉시 조사하고 수정할 수 없기 때문에 필요합니다. 이것은 작업량 설명이자 품질 설명입니다. 개발주기가 끝날 때 결함 백 로그가 크고 많은 수정 사항이 아직 시스템에 통합되지 않은 경우 시스템의 안정성 (따라서 품질)에 영향을 미칩니다. 목표 제품 품질 수준에 도달했는지 확인하려면 재 테스트 (회귀 테스트)가 필요합니다.

위상 기반 결함 제거 패턴

이는 테스트 중 결함 밀도 메트릭의 확장입니다. 테스트 외에도 설계 검토, 코드 검사 및 테스트 전 공식 검증을 포함하여 개발주기의 모든 단계에서 결함을 추적합니다.

프로그래밍 결함의 상당 부분이 설계 문제와 관련이 있기 때문에, 공식적인 검토를 수행하거나 프런트 엔드에서 프로세스의 결함 제거 기능을 향상시키기위한 기능 검증을 수행하면 소프트웨어의 오류가 줄어 듭니다. 위상 기반 결함 제거 패턴은 개발 프로세스의 전체 결함 제거 능력을 반영합니다.

설계 및 코딩 단계에 대한 메트릭과 관련하여 결함률 외에도 많은 개발 조직은 프로세스 내 품질 관리를 위해 검사 범위 및 검사 노력과 같은 메트릭을 사용합니다.

결함 제거 효과

다음과 같이 정의 할 수 있습니다-

$$DRE = \frac{Defect \: removed \: during \: a \: development\:phase }{Defects\: latent \: in \: the\: product} \times 100\%$$

이 메트릭은 전체 개발 프로세스, 코드 통합 전 프런트 엔드 및 각 단계에 대해 계산할 수 있습니다. 그것은이라고early defect removal 프런트 엔드 및 phase effectiveness특정 단계에 대해. 메트릭 값이 높을수록 개발 프로세스가 더 효과적이며 다음 단계 또는 현장으로 전달되는 결함이 줄어 듭니다. 이 메트릭은 소프트웨어 개발을위한 결함 제거 모델의 핵심 개념입니다.

유지 관리 품질 메트릭

이 단계에서 제품의 품질을 변경하기 위해 할 수있는 일은 많지 않지만, 다음은 우수한 수정 품질로 가능한 한 빨리 결함을 제거하기 위해 수행 할 수있는 수정입니다.

  • 백 로그 및 백 로그 관리 인덱스 수정
  • 응답 시간 수정 및 응답 성 수정
  • 불량 수정 비율
  • 품질 수정

백 로그 및 백 로그 관리 인덱스 수정

수정 백로 그는 결함 도착 비율 및보고 된 문제에 대한 수정 사항이 사용 가능한 비율과 관련이 있습니다. 매월 말 또는 매주 남아있는보고 된 문제의 간단한 개수입니다. 이 메트릭을 추세 차트 형식으로 사용하면 유지 관리 프로세스를 관리하는 데 의미있는 정보를 제공 할 수 있습니다.

백 로그 관리 인덱스 (BMI)는 미해결 문제와 미해결 문제의 백 로그를 관리하는 데 사용됩니다.

$$BMI = \frac{Number \: of \: problems \: closed \: during \:the \:month }{Number \: of \: problems \: arrived \: during \:the \:month} \times 100\%$$

BMI가 100보다 크면 백 로그가 줄어든다는 의미입니다. BMI가 100 미만이면 백 로그가 증가합니다.

응답 시간 수정 및 응답 성 수정

수정 응답 시간 메트릭은 일반적으로 시작에서 종료까지 모든 문제의 평균 시간으로 계산됩니다. 짧은 수리 응답 시간은 고객 만족으로 이어집니다.

수리 대응 성의 중요한 요소는 고객 기대치, 합의 된 수리 시간 및 고객에 대한 약속을 충족 할 수있는 능력입니다.

불량 수정 비율

다음과 같이 계산됩니다-

$Percent \:Delinquent\: Fixes =$

$\frac{Number \: of \: fixes \: that\: exceeded \: the \:response \:time\:criteria\:by\:ceverity\:level}{Number \: of \: fixes \: delivered \: in \:a \:specified \:time} \times 100\%$

품질 수정

수정 품질 또는 결함 수정 수는 유지 관리 단계의 또 다른 중요한 품질 메트릭입니다. 보고 된 문제를 수정하지 않았거나 원래 문제를 수정했지만 새로운 결함을 주입 한 경우 수정에 결함이있는 것입니다. 미션 크리티컬 소프트웨어의 경우 결함 수정은 고객 만족에 해를 끼칩니다. 결함 수정 비율의 메트릭은 시간 간격에서 결함이있는 모든 수정의 비율입니다.

결함 수정은 두 가지 방법으로 기록 할 수 있습니다. 발견 된 달에 기록하거나 수정 사항이 제공된 달에 기록합니다. 첫 번째는 고객 측정입니다. 두 번째는 프로세스 측정입니다. 두 날짜의 차이는 결함 수정의 잠복 기간입니다.

일반적으로 지연 시간이 길수록 영향을받는 고객이 많아집니다. 결함 수가 많으면 백분율 메트릭의 작은 값이 낙관적 인 그림을 표시합니다. 물론 유지 관리 프로세스의 품질 목표는 연체없이 결함 수정이없는 것입니다.

측정은 무언가를 측정하는 행동입니다. 다른 개체 나 이벤트와 비교할 수있는 개체 또는 이벤트의 특성에 숫자를 할당하는 것입니다.

공식적으로는 명확하게 정의 된 규칙에 따라 설명하는 방식으로 실제 세계에서 개체의 속성에 숫자 또는 기호를 할당하는 프로세스로 정의 할 수 있습니다.

일상 생활에서의 측정

측정은 전문 기술자뿐만 아니라 우리 모두가 일상 생활에서 사용합니다. 상점에서 가격은 품목의 가치를 측정하는 역할을합니다. 마찬가지로 높이와 크기 측정을 통해 천이 제대로 맞는지 여부를 확인할 수 있습니다. 따라서 측정은 항목을 다른 항목과 비교하는 데 도움이됩니다.

측정은 엔티티의 속성에 대한 정보를 취합니다. 엔티티는 사람과 같은 객체이거나 현실 세계에서의 여행과 같은 이벤트입니다. 속성은 사람의 키, 여행 비용 등과 같은 엔티티의 특징 또는 속성입니다. 현실 세계에서는 사물을 측정하려고하지만 실제로는 사물의 속성을 측정하고 있습니다.

속성은 대부분 숫자 또는 기호로 정의됩니다. 예를 들어 가격은 루피 또는 달러로 지정할 수 있으며 의류 크기는 소형, 중형, 대형으로 지정할 수 있습니다.

측정의 정확도는 측정 장비와 측정 정의에 따라 달라집니다. 측정 값을 얻은 후이를 분석하고 개체에 대한 결론을 도출해야합니다.

측정은 직접 정량화이지만 계산은 일부 공식을 사용하여 다른 측정을 결합하는 간접적 인 것입니다.

소프트웨어 공학의 측정

소프트웨어 엔지니어링에는 소프트웨어 제품 관리, 비용 산정, 계획, 모델링, 분석, 지정, 설계, 구현, 테스트 및 유지 관리가 포함됩니다. 따라서 측정은 소프트웨어 엔지니어링에서 중요한 역할을합니다. 소프트웨어 제품의 속성을 측정하려면 엄격한 접근 방식이 필요합니다.

대부분의 개발 프로젝트에서

  • 소프트웨어 제품에 대한 측정 가능한 목표를 설정하지 못함
  • 소프트웨어 프로젝트의 구성 요소 비용을 이해하고 정량화하지 못합니다.
  • 우리가 생산하는 제품의 품질을 정량화하거나 예측하지 않습니다.

따라서 소프트웨어 제품을 제어하려면 속성 측정이 필요합니다. 모든 측정 작업은 명확하게 정의되고 쉽게 이해할 수있는 특정 목표 또는 요구에 의해 동기가 부여되어야합니다. 측정 목표는 구체적이어야하며 관리자, 개발자 및 사용자가 알아야 할 사항에 대해 시도해야합니다. 프로젝트, 제품, 프로세스 및 자원의 상태를 평가하려면 측정이 필요합니다.

소프트웨어 엔지니어링에서 측정은 다음 세 가지 기본 활동에 필수적입니다.

  • 개발 및 유지 관리 중에 일어나는 일을 이해하기 위해
  • 프로젝트에서 일어나는 일을 제어하려면
  • 프로세스와 목표를 개선하기 위해

측정의 대표 이론

측정은 모든 종류의 측정에 대한 개발 및 추론을위한 토대가되는 규칙을 알려줍니다. 그것은 경험적 세계에서 공식적인 관계 세계로의 매핑입니다. 결과적으로 측정 값은 엔터티를 특성화하기 위해이 매핑에 의해 엔터티에 할당 된 번호 또는 기호입니다.

경험적 관계

현실 세계에서는 숫자를 할당하는 것이 아니라 비교함으로써 사물을 이해합니다.

예를 들어, 키를 비교하기 위해 '보다 키가 크다',보다 높음 '이라는 용어를 사용합니다. 따라서 이러한 '보다 키가 크고'보다 높음은 키에 대한 경험적 관계입니다.

동일한 세트에 대해 둘 이상의 경험적 관계를 정의 할 수 있습니다.

예를 들어 X는 Y보다 키가 큽니다. X, Y는 Z보다 훨씬 큽니다.

경험적 관계는 단항, 이진, 삼항 등이 될 수 있습니다.

X는 키가 크고 Y는 키가 크지 않은 단항 관계입니다.

X는 Y가 이진 관계보다 큽니다.

현실 세계의 경험적 관계는 공식적인 수학적 세계에 매핑 될 수 있습니다. 대부분 이러한 관계는 개인적 선호도를 반영합니다.

이러한 경험적 관계를 수학적 세계에 매핑하는 데 사용되는 매핑 또는 평가 기법 중 일부는 다음과 같습니다.

라이 커트 눈금

여기에서 사용자는 동의 또는 동의하지 않는 내용이 표시됩니다.

For example −이 소프트웨어는 잘 작동합니다.

매우 동의 함 동의하다 동의하지도 동의하지도 않음 동의하지 않는다 강력히 Disgaree
         

강제 순위

주어진 대안을 1 (최상)에서 n (최악)까지 주문하십시오.

예 : 성능에 따라 다음 5 개의 소프트웨어 모듈의 순위를 매 깁니다.

모듈 이름 계급
모듈 A
모듈 B
모듈 C
모듈 D
모듈 E

언어 주파수 척도

For example −이 프로그램은 얼마나 자주 실패합니까?

항상 자주 때때로 드물게
         

서수 척도

여기에서 사용자에게 대안 목록이 제공되며 하나를 선택해야합니다.

For example −이 프로그램은 얼마나 자주 실패합니까?

  • Hourly
  • Daily
  • Weekly
  • Monthly
  • 1 년에 여러 번
  • 1 년에 1 ~ 2 회
  • Never

비교 규모

여기에서 사용자는 서로 다른 옵션을 비교하여 숫자를 제공해야합니다.

Very superiorAbout the sameVery inferior

12345678910

수치 척도

여기서 사용자는 중요도에 따라 번호를 부여해야합니다.

UnimportantImportant

12345678910

매핑 규칙

매핑을 수행하려면 매핑을 수행 할 규칙뿐만 아니라 도메인, 범위를 지정해야합니다.

For example − 도메인-현실 세계

  • Range − 정수, 실수 등의 수학적 세계

  • Rules − 신장 측정을 위해 신발 착용 여부

유사하게, 소프트웨어 측정의 경우, 명시 할 코드 라인에 포함될 문장의 체크리스트.

측정의 대표 조건

표현 조건은 측정 매핑이 (M) 실증적 관계가 수치 적 관계에 의해 보존되고 보존되는 방식으로 실체를 숫자로, 경험적 관계를 수치 적 관계로 매핑해야합니다.

예 : '보다 큰'경험적 관계는 숫자 관계 '>'에 매핑됩니다. X is taller than Y, if and only if M(X) > M(Y)

주어진 세트에 많은 관계가있을 수 있기 때문에 표현 조건은 이러한 각 관계에 대한 의미도 가지고 있습니다.

단항 관계 'is tall'의 경우 수치 적 관계가있을 수 있습니다.

X > 50

표현 조건은 모든 측정에 대해 M,

X is tall if and only if M(X) > 50

공식 측정의 주요 단계

측정의 주요 단계는 다음과 같이 요약 할 수 있습니다.

모델은 실제 개체의 수치 요소 동작을 해석하고 측정하는 데 유용합니다. 측정 프로세스를 돕기 위해 매핑 모델도 매핑 도메인 모델로 보완되어야합니다. 모델은 또한 이러한 엔터티가 속성과 관련되는 방식과 특성이 관련되는 방식을 지정해야합니다.

측정은 두 가지 유형입니다-

  • 직접 측정
  • 간접 측정

직접 측정

다른 개체 나 속성의 개입없이 측정 할 수있는 측정입니다.

다음 직접적인 측정은 소프트웨어 엔지니어링에서 일반적으로 사용됩니다.

  • LOC 별 소스 코드 길이
  • 경과 시간에 따른 테스트 목적 기간
  • 테스트 과정에서 결함 수를 계산하여 발견 된 결함 수
  • 프로그래머가 프로그램에 소비하는 시간

간접 측정

다른 엔티티 또는 속성의 관점에서 측정 할 수있는 측정입니다.

다음 간접 측정은 소프트웨어 엔지니어링에서 일반적으로 사용됩니다.

$$\small Programmer\:Productivity = \frac{LOC \: produced }{Person \:months \:of \:effort}$$

$\small Module\:Defect\:Density = \frac{Number \:of\:defects}{Module \:size}$

$$\small Defect\:Detection\:Efficiency = \frac{Number \:of\:defects\:detected}{Total \:number \:of\:defects}$$

$\small Requirement\:Stability = \frac{Number \:of\:initial\:requirements}{Total \:number \:of\:requirements}$

$\small Test\:Effectiveness\:Ratio = \frac{Number \:of\:items\:covered}{Total \:number \:of \:items}$

$\small System\:spoilage = \frac{Effort \:spent\:for\:fixing\:faults}{Total \:project \:effort}$

예측 측정

프로젝트에 적절한 리소스를 할당하려면 프로젝트 개발에 필요한 노력, 시간 및 비용을 예측해야합니다. 예측을위한 측정에는 항상 예측할 속성을 지금 측정 할 수있는 다른 속성과 연결하는 수학적 모델이 필요합니다. 따라서 예측 시스템은 알려지지 않은 매개 변수를 결정하고 결과를 해석하기위한 일련의 예측 절차와 함께 수학적 모델로 구성됩니다.

측정 척도는 경험적 관계 시스템을 나타내는 데 사용되는 매핑입니다. 주로 5 가지 종류-

  • 공칭 규모
  • 서수 척도
  • 간격 척도
  • 비율 척도
  • 절대 스케일

공칭 규모

분류 체계에 요소를 배치합니다. 수업은 주문되지 않습니다. 각각의 모든 엔티티는 속성 값에 따라 특정 클래스 또는 카테고리에 배치되어야합니다.

두 가지 주요 특징이 있습니다.

  • 경험적 관계 시스템은 다른 클래스로만 구성됩니다. 클래스 사이에 순서의 개념이 없습니다.

  • 클래스의 고유 한 번호 매기기 또는 기호 표현은 허용되는 척도이지만 숫자 또는 기호와 관련된 크기의 개념은 없습니다.

서수 척도

정렬 된 분류 체계에 요소를 배치합니다. 그것은 다음과 같은 특성을 가지고 있습니다-

  • 경험적 관계 시스템은 속성과 관련하여 정렬 된 클래스로 구성됩니다.

  • 순서를 유지하는 모든 매핑이 허용됩니다.

  • 숫자는 순위만을 나타냅니다. 따라서 더하기, 빼기 및 기타 산술 연산은 의미가 없습니다.

간격 척도

이 척도는 분류를 구분하는 간격의 크기에 대한 정보를 캡처합니다. 따라서 공칭 척도와 서수 척도보다 더 강력합니다.

그것은 다음과 같은 특성을 가지고 있습니다-

  • 서수 스케일과 같은 순서를 유지합니다.

  • 차이는 유지하지만 비율은 유지하지 않습니다.

  • 더하기와 빼기는이 척도에서 수행 할 수 있지만 곱하기 나 나누기는 할 수 없습니다.

속성이 간격 척도로 측정 가능한 경우 MM’ 표현 조건을 만족하는 매핑이므로 항상 두 개의 숫자를 찾을 수 있습니다. ab 그런,

M = aM '+ b

비율 척도

이것은 가장 유용한 측정 척도입니다. 여기서 비율을 포착하기위한 경험적 관계가 존재합니다. 그것은 다음과 같은 특성을 가지고 있습니다-

  • 순서, 항목 간 간격 크기 및 항목 간 비율을 유지하는 측정 매핑입니다.

  • 속성의 전체 부족을 나타내는 0 요소가 있습니다.

  • 측정 매핑은 0에서 시작하고 단위라고하는 동일한 간격으로 증가해야합니다.

  • 모든 산술 연산을 적용 할 수 있습니다.

여기서 매핑은

M = aM’

어디 ‘a’ 양의 스칼라입니다.

절대 스케일

이 척도에서는 속성에 대해 하나의 가능한 측정 값 만 있습니다. 따라서 가능한 유일한 변환은 정체성 변환입니다.

그것은 다음과 같은 특성을 가지고 있습니다-

  • 측정은 엔티티 세트의 요소 수를 계산하여 이루어집니다.

  • 속성은 항상 "엔티티에서 x 발생 횟수"형식을 취합니다.

  • 가능한 측정 매핑은 실제 개수입니다.

  • 결과 카운트에 대해 모든 산술 연산을 수행 할 수 있습니다.

경험적 조사는 도구, 기술 또는 방법에 대한 과학적 조사를 포함합니다. 이 조사는 주로 다음 4 가지 원칙을 포함합니다.

  • 조사 기술 선택
  • 가설 진술
  • 변수에 대한 통제력 유지
  • 조사를 의미있게 만들기

조사 기법 선택

소프트웨어 엔지니어링에서 경험적 조사의 주요 구성 요소는 다음과 같습니다.

  • Survey
  • 사례 연구
  • 공식 실험

서베이

설문 조사는 관계와 결과를 문서화하기 위해 상황에 대한 후 향적 연구입니다. 항상 이벤트가 발생한 후에 수행됩니다. 예를 들어, 소프트웨어 엔지니어링에서 설문 조사를 수행하여 사용자가 특정 방법, 도구 또는 기술에 반응하여 추세 또는 관계를 결정하는 방법을 결정할 수 있습니다.

이 경우 우리는 당면한 상황을 통제 할 수 없습니다. 상황을 기록하고 비슷한 상황과 비교할 수 있습니다.

사례 연구

활동의 결과에 영향을 미칠 수있는 주요 요인을 식별 한 다음 해당 활동 (입력, 제약, 자원 및 출력)을 문서화하는 연구 기법입니다.

공식 실험

활동에 대한 엄격하게 통제 된 조사이며 주요 요인을 식별하고 조작하여 결과에 미치는 영향을 문서화합니다.

다음 지침에 따라 특정 조사 방법을 선택할 수 있습니다.

  • 활동이 이미 발생한 경우 설문 조사 또는 사례 연구를 수행 할 수 있습니다. 아직 발생하지 않은 경우 사례 연구 또는 공식 실험을 선택할 수 있습니다.

  • 결과에 영향을 줄 수있는 변수에 대한 높은 수준의 제어가 있다면 실험을 사용할 수 있습니다. 변수를 제어 할 수없는 경우 사례 연구가 선호되는 기술입니다.

  • 더 높은 수준에서 복제가 불가능하면 실험이 불가능합니다.

  • 복제 비용이 낮 으면 실험을 고려할 수 있습니다.

가설 진술

특정 조사 기법의 결정을 높이기 위해 연구의 목표를 테스트하려는 가설로 표현해야합니다. 가설은 프로그래머가 탐색하려는 동작을 설명한다고 생각하는 잠정적 인 이론 또는 가정입니다.

변수에 대한 제어 유지

가설을 말한 후에는 그 진실에 영향을 미치는 다양한 변수와 우리가 얼마나 많은 통제력을 가지고 있는지 결정해야합니다. 이는 실험과 사례 연구 사이의 주요 차별 요소가 행동에 영향을 미치는 변수에 대한 통제 정도이기 때문에 필수적입니다.

프로젝트를 특성화하고 평가 결과에 영향을 미칠 수있는 요인 인 상태 변수를 사용하여 공식 실험에서 제어 상황과 실험 상황을 구분합니다. 대조군과 실험을 구별 할 수 없다면 사례 연구 기법이 선호 될 것입니다.

예를 들어 프로그래밍 언어의 변경이 프로젝트의 생산성에 영향을 미칠 수 있는지 여부를 확인하려는 경우 언어는 상태 변수가됩니다. 현재 Ada로 대체하려는 FORTRAN을 사용하고 있다고 가정합니다. 그러면 FORTRAN이 제어 언어가되고 Ada가 실험적 언어가됩니다.

조사를 의미있게 만들기

실험 결과는 일반적으로 사례 연구 또는 설문 조사보다 일반화 가능합니다. 사례 연구 또는 설문 조사의 결과는 일반적으로 특정 조직에만 적용 할 수 있습니다. 다음 요점은 다양한 질문에 답하는 이러한 기술의 효율성을 입증합니다.

일치하는 이론과 관습적인 지혜

사례 연구 또는 설문 조사를 사용하여 단일 조직에서 기존의 통념과 기타 많은 표준, 방법 또는 도구의 효과와 유용성을 준수 할 수 있습니다. 그러나 공식 실험은 주장이 일반적으로 사실 인 상황을 조사 할 수 있습니다.

관계 탐구

자원과 소프트웨어 제품의 다양한 속성 간의 관계는 사례 연구 또는 설문 조사를 통해 제안 될 수 있습니다.

예를 들어, 완료된 프로젝트를 조사한 결과 특정 언어로 작성된 소프트웨어가 다른 언어로 작성된 소프트웨어보다 결함이 적다는 것을 알 수 있습니다.

이러한 관계를 이해하고 확인하는 것은 향후 프로젝트의 성공에 필수적입니다. 이러한 각 관계는 가설로 표현할 수 있으며 관계가 유지되는 정도를 테스트하기 위해 공식적인 실험을 설계 할 수 있습니다. 일반적으로 특정 속성의 값은 다른 속성을 일정하게 유지하거나 제어하여 관찰합니다.

모델의 정확성 평가

모델은 일반적으로 활동의 결과를 예측하거나 방법 또는 도구의 사용을 안내하는 데 사용됩니다. 예측이 종종 결과에 영향을 미치기 때문에 실험이나 사례 연구를 설계 할 때 특히 어려운 문제가 발생합니다. 프로젝트 관리자는 종종 예측을 완료 목표로 전환합니다. 이 효과는 비용 및 일정 모델을 사용할 때 일반적입니다.

신뢰성 모델과 같은 일부 모델은 소프트웨어가 현장에서 사용할 준비가 될 때까지 평균 고장 시간으로 측정 된 신뢰성을 평가할 수 없기 때문에 결과에 영향을 미치지 않습니다.

측정 검증

속성 값을 캡처하는 소프트웨어 측정 방법이 많이 있습니다. 따라서 주어진 측정 값이 캡처해야하는 속성의 변경 사항을 반영하는지 여부를 테스트하기 위해 연구를 수행해야합니다. 하나의 측정 값을 다른 측정 값과 연관시켜 유효성 검사를 수행합니다. 영향 요인에 대한 직접적이고 유효한 척도 인 두 번째 척도를 사용하여 검증해야합니다. 이러한 측정은 항상 사용 가능하거나 측정하기 쉬운 것은 아닙니다. 또한 사용 된 측정은 측정되는 요소에 대한 인간의 개념을 준수해야합니다.

소프트웨어 측정 프레임 워크는 세 가지 원칙을 기반으로합니다.

  • 검사 할 개체 분류
  • 관련 측정 목표 결정
  • 조직이 도달 한 성숙도 수준 식별

검사 할 개체 분류

소프트웨어 엔지니어링에서는 주로 세 가지 유형의 엔티티가 존재합니다. 그들은-

  • Processes
  • Products
  • Resources

이러한 모든 엔티티에는 내부 및 외부 엔티티가 있습니다.

  • Internal attributes프로세스, 제품 또는 자원 자체의 관점에서 순전히 측정 할 수있는 것입니다. 예 : 크기, 복잡성, 모듈 간의 종속성.

  • External attributes환경과의 관계에 대해서만 측정 할 수있는 것입니다. 예 : 사용자가 경험 한 총 실패 수, 데이터베이스를 검색하고 정보를 검색하는 데 걸리는 시간.

각 엔티티에 대해 측정 할 수있는 다른 속성은 다음과 같습니다.

프로세스

프로세스는 소프트웨어 관련 활동의 모음입니다. 다음은 프로세스에 대해 직접 측정 할 수있는 내부 속성 중 일부입니다.

  • 프로세스 또는 활동 중 하나의 기간

  • 프로세스 또는 활동 중 하나와 관련된 노력

  • 프로세스 또는 활동 중 하나에서 발생하는 특정 유형의 인시던트 수

프로세스의 다양한 외부 속성은 비용, 제어 가능성, 효율성, 품질 및 안정성입니다.

제품

제품은 경영진이 제공하기로 약속 한 항목 일뿐만 아니라 소프트웨어 수명주기 동안 생성 된 아티팩트 또는 문서이기도합니다.

다양한 내부 제품 속성은 크기, 노력, 비용, 사양, 길이, 기능, 모듈성, 재사용, 중복성 및 구문 정확성입니다. 이 중 크기, 노력 및 비용은 다른 것보다 상대적으로 측정하기 쉽습니다.

다양한 외부 제품 속성은 사용성, 무결성, 효율성, 테스트 가능성, 재사용 성, 이식성 및 상호 운용성입니다. 이러한 속성은 코드뿐만 아니라 개발 노력을 지원하는 다른 문서도 설명합니다.

자원

이들은 프로세스 활동에 필요한 엔티티입니다. 소프트웨어 생산을위한 모든 입력이 될 수 있습니다. 여기에는 인력, 재료, 도구 및 방법이 포함됩니다.

리소스의 다양한 내부 속성은 연령, 가격, 크기, 속도, 메모리 크기, 온도 등입니다. 다양한 외부 속성은 생산성, 경험, 품질, 유용성, 신뢰성, 편안함 등입니다.

관련 측정 목표 결정

특정 측정은 프로세스 또는 결과 제품 중 하나를 이해하는 데 도움이되는 경우에만 유용합니다. 프로세스 또는 제품의 개선은 프로젝트에 프로세스 및 제품에 대한 목표가 명확하게 정의 된 경우에만 수행 할 수 있습니다. 목표에 대한 명확한 이해는 프로세스 성숙도 프레임 워크의 맥락에서 주어진 프로젝트에 대한 제안 된 지표를 생성하는 데 사용될 수 있습니다.

GQM (Goal-Question-Metric) 패러다임

GQM 접근 방식은 다음 세 단계를 포함하는 프레임 워크를 제공합니다.

  • 개발 또는 유지 보수 프로젝트의 주요 목표 나열

  • 목표 달성 여부를 결정하기 위해 답해야하는 각 목표에서 질문 도출

  • 질문에 적절하게 답하기 위해 측정해야 할 사항을 결정합니다.

GQM 패러다임을 사용하기 위해 먼저 조직의 전반적인 목표를 표현합니다. 그런 다음 목표가 충족되고 있는지 확인할 수 있도록 답변을 알 수 있도록 질문을 생성합니다. 나중에 각 질문에 답하기 위해 필요한 측정 값과 관련하여 각 질문을 분석합니다.

일반적인 목표는 생산성, 품질, 위험, 고객 만족도 등으로 표현됩니다. 목표와 질문은 청중의 관점에서 구성되어야합니다.

목표, 질문 및 메트릭 생성을 돕기 위해 Basili & Rombach는 일련의 템플릿을 제공했습니다.

  • Purpose − 이해, 평가, 관리, 엔지니어링, 학습, 개선 등을 위해 (프로세스, 제품, 모델, 메트릭 등)을 (특성화, 평가, 예측, 동기 부여 등) Example: 그것을 배우기 위해 제품을 특성화합니다.

  • Perspective − 개발자, 관리자, 고객 등의 관점에서 (비용, 효과 성, 정확성, 결함, 변경, 제품 조치 등)을 검토합니다. Example: 고객의 입장에서 결함을 검사합니다.

  • Environment − 환경은 프로세스 요인, 사람 요인, 문제 요인, 방법, 도구, 제약 조건 등으로 구성됩니다. Example:이 소프트웨어의 고객은 도구에 대한 지식이없는 사람들입니다.

측정 및 프로세스 개선

일반적으로 측정은 다음에 유용합니다.

  • 프로세스 및 제품 이해
  • 기준선 설정
  • 결과 접근 및 예측

SEI에서 제공하는 프로세스의 성숙도 수준에 따라 측정 유형과 측정 프로그램이 다릅니다. 다음은 각 성숙도 수준에서 적용 할 수있는 다양한 측정 프로그램입니다.

Level 1: Ad hoc

이 수준에서 입력은 잘못 정의 된 반면 출력은 예상됩니다. 입력에서 출력으로의 전환은 정의되지 않고 제어되지 않습니다. 이 수준의 프로세스 성숙도를 위해서는 측정을위한 시작점을 제공하기 위해 기준 측정이 필요합니다.

Level 2: Repeatable

이 수준에서 프로세스, 제약 및 리소스의 입력 및 출력을 식별 할 수 있습니다. 반복 가능한 프로세스는 다음 다이어그램으로 설명 할 수 있습니다.

입력 측정은 요구 사항의 크기와 변동성이 될 수 있습니다. 산출물은 시스템 크기, 직원 노력의 자원, 비용 및 일정의 제약으로 측정 될 수 있습니다.

Level 3: Defined

이 수준에서 중간 활동이 정의되고 입력 및 출력이 알려지고 이해됩니다. 정의 된 프로세스의 간단한 예가 다음 그림에 설명되어 있습니다.

중간 활동에 대한 입력과 출력을 조사, 측정 및 평가할 수 있습니다.

Level 4: Managed

이 수준에서 초기 프로젝트 활동의 피드백을 사용하여 현재 활동에 대한 우선 순위를 설정하고 나중에 프로젝트 활동에 대한 우선 순위를 설정할 수 있습니다. 프로세스 활동의 효과를 측정 할 수 있습니다. 측정은 전체 프로세스의 특성과 주요 활동 간의 상호 작용을 반영합니다.

Level 5: Optimizing

이 수준에서 활동의 측정은 측정 피드백에 따라 프로세스 활동을 제거 및 추가하고 프로세스 구조를 동적으로 변경하여 프로세스를 개선하는 데 사용됩니다. 따라서 프로세스 변경은 프로세스뿐만 아니라 조직과 프로젝트에 영향을 미칠 수 있습니다. 프로세스는 센서 및 모니터 역할을하며 경고 신호에 대응하여 프로세스를 크게 변경할 수 있습니다.

주어진 성숙도 수준에서 해당 수준과 그 아래의 모든 수준에 대한 측정 값을 수집 할 수 있습니다.

성숙도 확인

프로세스 성숙도는 보이는 것만 측정하도록 제안합니다. 따라서 프로세스 성숙도와 GQM의 조합은 가장 유용한 측정을 제공합니다.

  • 에서 level 1, 프로젝트에 잘못 정의 된 요구 사항이있을 수 있습니다. 이 수준에서는 요구 사항 특성의 측정이 어렵습니다.

  • 에서 level 2, 요구 사항이 잘 정의되어 있으며 각 요구 사항 유형 및 각 유형에 대한 변경 횟수와 같은 추가 정보를 수집 할 수 있습니다.

  • 에서 level 3, 중간 활동은 각 활동에 대한 시작 및 종료 기준으로 정의됩니다.

목표 및 질문 분석은 동일하지만 측정 항목은 성숙도에 따라 달라집니다. 프로세스가 성숙할수록 측정치가 더 풍부 해집니다. 프로세스 성숙도와 함께 GQM 패러다임은 관리자가 측정 프로그램을 설계하는 데 도움이되는 여러 도구의 기반으로 사용되었습니다.

GQM은 속성 측정의 필요성을 이해하는 데 도움이되며 프로세스 성숙도는이를 의미있는 방식으로 측정 할 수 있는지 여부를 나타냅니다. 함께 측정을위한 컨텍스트를 제공합니다.

소프트웨어 시스템의 측정을 검증하는 데는 두 단계가 있습니다.

  • 측정 시스템 검증
  • 예측 시스템 검증

측정 시스템 검증

측정 또는 측정 시스템은 하나 이상의 속성을 수치 적으로 특성화하여 기존 엔티티를 평가하는 데 사용됩니다. 측정은 측정한다고 주장하는 속성을 정확하게 특성화하는 경우 유효합니다.

소프트웨어 측정 시스템을 검증하는 것은 표현 조건이 충족되었음을 보여줌으로써 측정이 청구 된 속성의 적절한 숫자 특성인지 확인하는 프로세스입니다.

측정 시스템을 검증하려면 엔티티를 설명하는 공식 모델과 측정중인 속성을 보존하는 수치 매핑이 모두 필요합니다. 예를 들어 두 개의 프로그램 P1과 P2가 있고 이러한 프로그램을 연결하려는 경우 모든 측정 값이m 그것을 만족시키기 위해 길이의

m (P1 + P2) = m (P1) + m (P2)

프로그램이 P1 프로그램보다 길이가 더 깁니다. P2, 다음 모든 측정 m 만족해야합니다.

m (P1)> m (P2)

프로그램의 길이는 코드 줄을 세어 측정 할 수 있습니다. 이 개수가 위의 관계를 충족하면 코드 줄이 길이의 유효한 척도라고 말할 수 있습니다.

측정을 검증하기위한 공식적인 요구 사항은 측정 이론의 의미에서 명시된 속성을 특성화한다는 것을 입증하는 것을 포함합니다. 검증을 사용하여 측정기가 올바르게 정의되고 엔티티의 실제 행동과 일치하는지 확인할 수 있습니다.

예측 시스템 검증

예측 시스템은 관련 예측 절차와 함께 수학적 모델을 포함하는 미래 엔티티의 일부 속성을 예측하는 데 사용됩니다.

주어진 환경에서 예측 시스템을 검증하는 것은 경험적 수단, 즉 주어진 환경에서 알려진 데이터와 모델 성능을 비교하여 예측 시스템의 정확도를 설정하는 프로세스입니다. 여기에는 실험과 가설 테스트가 포함됩니다.

검증에 허용되는 정확도는 예측 시스템이 결정론 적인지 확률 적인지 여부와 평가를 수행하는 사람에 따라 다릅니다. 일부 확률 적 예측 시스템은 다른 시스템보다 더 확률 적입니다.

확률 적 예측 시스템의 예로는 소프트웨어 비용 추정, 노력 추정, 일정 추정 등과 같은 시스템이 있습니다. 따라서 예측 시스템을 공식적으로 검증하려면 그것이 얼마나 확률 적인지 결정한 다음 예측 시스템의 성능을 알려진 데이터와 비교해야합니다.

소프트웨어 메트릭은 어느 정도의 측정을 포함하는 많은 활동을 포함하는 측정 표준입니다. 제품 지표, 프로세스 지표 및 프로젝트 지표의 세 가지 범주로 분류 할 수 있습니다.

  • Product metrics 크기, 복잡성, 디자인 기능, 성능 및 품질 수준과 같은 제품의 특성을 설명합니다.

  • Process metrics소프트웨어 개발 및 유지 관리를 개선하는 데 사용할 수 있습니다. 예를 들어 개발 중 결함 제거의 효율성, 결함 도착 테스트 패턴 및 수정 프로세스의 응답 시간이 있습니다.

  • Project metrics프로젝트 특성 및 실행을 설명합니다. 예를 들어 소프트웨어 개발자 수, 소프트웨어 수명주기 동안의 인력 패턴, 비용, 일정 및 생산성이 있습니다.

일부 메트릭은 여러 범주에 속합니다. 예를 들어 프로젝트의 프로세스 중 품질 메트릭은 프로세스 메트릭과 프로젝트 메트릭입니다.

소프트웨어 메트릭의 범위

소프트웨어 메트릭은 다음을 포함하는 많은 활동을 포함합니다-

  • 비용 및 노력 추정
  • 생산성 측정 및 모델
  • 데이터 수집
  • 수량 모델 및 측정
  • 신뢰성 모델
  • 성능 및 평가 모델
  • 구조 및 복잡성 메트릭
  • 기능 – 성숙도 평가
  • 지표 별 관리
  • 방법 및 도구 평가

소프트웨어 측정은 특정 단계에서 소프트웨어 프로젝트 비용을 예측하는 모델부터 프로그램 구조 측정에 이르기까지 다양한 활동의 ​​모음입니다.

비용 및 노력 추정

노력은 프로그램의 크기, 개발자의 능력 및 재사용 수준과 같은 하나 이상의 변수의 함수로 표현됩니다. 소프트웨어 수명주기의 초기 단계에서 프로젝트 비용을 예측하기 위해 비용 및 노력 추정 모델이 제안되었습니다. 제안 된 다른 모델은 다음과 같습니다.

  • Boehm의 COCOMO 모델
  • Putnam의 슬림 모델
  • Albrecht의 기능 포인트 모델

생산성 모델 및 측정

생산성은 가치와 비용의 함수로 간주 할 수 있습니다. 각각은 다른 측정 가능한 크기, 기능, 시간, 비용 등으로 분해 될 수 있습니다. 생산성 모델의 다른 가능한 구성 요소는 다음 다이어그램에서 표현할 수 있습니다.

데이터 수집

모든 측정 프로그램의 품질은 신중한 데이터 수집에 달려 있습니다. 수집 된 데이터는 관리자가 개발의 진행 상황과 문제를 이해할 수 있도록 간단한 차트와 그래프로 추출 할 수 있습니다. 데이터 수집은 관계 및 추세에 대한 과학적 조사에도 필수적입니다.

품질 모델 및 측정

생산성이 무의미한 제품의 품질 측정을위한 품질 모델이 개발되었습니다. 이러한 품질 모델을 생산성 모델과 결합하여 정확한 생산성을 측정 할 수 있습니다. 이러한 모델은 일반적으로 나무와 같은 방식으로 구성됩니다. 상위 분기에는 안정성 및 유용성과 같은 중요한 높은 수준의 품질 요소가 있습니다.

분할 및 정복 접근 방식의 개념은 소프트웨어 품질 측정에 대한 표준 접근 방식으로 구현되었습니다.

신뢰성 모델

대부분의 품질 모델은 신뢰성을 구성 요소로 포함하지만 신뢰성을 예측하고 측정해야하는 필요성으로 인해 신뢰성 모델링 및 예측에 대한 별도의 전문화가 이루어졌습니다. 신뢰성 이론의 기본 문제는 시스템이 결국 실패 할시기를 예측하는 것입니다.

성능 평가 및 모델

여기에는 응답 시간 및 완료율과 같은 외부에서 관찰 가능한 시스템 성능 특성과 알고리즘 효율성과 같은 시스템의 내부 작업이 포함됩니다. 품질의 또 다른 측면입니다.

구조적 및 복잡성 메트릭

여기에서는 실행 전에 사용할 수있는 소프트웨어 표현의 구조적 속성을 측정합니다. 그런 다음 품질 보증, 품질 관리 및 품질 예측을 지원하기 위해 경험적 예측 이론을 설정하려고합니다.

기능 성숙도 평가

이 모델은 도구 사용, 표준 관행 등을 포함하여 다양한 개발 속성을 평가할 수 있습니다. 모든 좋은 계약자가 사용해야하는 핵심 관행을 기반으로합니다.

지표 별 관리

소프트웨어 프로젝트를 관리하기 위해 측정은 중요한 역할을합니다. 프로젝트가 진행 중인지 확인하기 위해 사용자와 개발자는 측정 기반 차트와 그래프를 사용할 수 있습니다. 표준 측정 및보고 방법 세트는 고객이 일반적으로 소프트웨어 용어에 익숙하지 않은 제품에 소프트웨어가 내장 된 경우 특히 중요합니다.

방법 및 도구 평가

이는 실험 설계, 결과에 영향을 미칠 수있는 요인의 적절한 식별 및 요인 속성의 적절한 측정에 따라 다릅니다.

소프트웨어 메트릭은 어느 정도의 측정을 포함하는 많은 활동을 포함하는 측정 표준입니다. 소프트웨어 측정의 성공은 수집 및 분석 된 데이터의 품질에 있습니다.

좋은 데이터 란 무엇입니까?

수집 된 데이터는 다음 질문에 대한 답을 얻을 수 있다면 좋은 데이터로 간주 될 수 있습니다.

  • Are they correct? − 메트릭 정의의 정확한 규칙에 따라 수집 된 데이터는 올바른 것으로 간주 될 수 있습니다.

  • Are they accurate? − 정확도는 데이터와 실제 값의 차이를 의미합니다.

  • Are they appropriately precise? − 정밀도는 데이터를 표현하는 데 필요한 소수 자릿수를 다룹니다.

  • Are they consistent? − 한 측정 장치에서 다른 측정 장치로 큰 차이가 나타나지 않는 경우 데이터는 일관성있는 것으로 간주 될 수 있습니다.

  • Are they associated with a particular activity or time period? − 데이터가 특정 활동 또는 기간과 관련된 경우 데이터에 명확하게 지정되어야합니다.

  • Can they be replicated?− 일반적으로 설문 조사, 사례 연구 및 실험과 같은 조사는 여러 상황에서 자주 반복됩니다. 따라서 데이터도 쉽게 복제 할 수 있어야합니다.

데이터를 정의하는 방법?

측정 목적으로 수집되는 데이터는 두 가지 유형이 있습니다.

  • Raw data− 원시 데이터는 프로세스, 제품 또는 자원의 초기 측정 결과입니다. 예 : 조직 직원의 주간 작업 표.

  • Refined data − 정제 된 데이터는 속성 값을 유도하기 위해 원시 데이터에서 필수 데이터 요소를 추출한 결과입니다.

데이터는 다음 사항에 따라 정의 할 수 있습니다.

  • Location
  • Timing
  • Symptoms
  • 최종 결과
  • Mechanism
  • Cause
  • Severity
  • Cost

데이터 수집 방법

데이터 수집에는 사람의 관찰과보고가 필요합니다. 관리자, 시스템 분석가, 프로그래머, 테스터 및 사용자는 양식에 행 데이터를 기록해야합니다. 정확하고 완전한 데이터를 수집하려면 다음이 중요합니다.

  • 절차를 간단하게 유지

  • 불필요한 녹음을 피하십시오

  • 데이터를 기록 할 필요성과 사용할 절차에 대해 직원 교육

  • 데이터 캡처 및 분석 결과를 원래 공급자에게 신속하고 유용한 형식으로 제공하여 작업을 지원합니다.

  • 중앙 수집 지점에서 수집 된 모든 데이터의 유효성을 검사합니다.

데이터 수집 계획에는 여러 단계가 포함됩니다.

  • GQM 분석을 기반으로 측정 할 제품 결정

  • 제품이 구성 제어하에 있는지 확인

  • 측정 할 속성과 간접 측정이 파생되는 방법을 정확하게 결정합니다.

  • 메트릭 세트가 명확하고 측정 할 구성 요소 세트가 식별되면 측정 프로세스와 관련된 각 활동을 식별하기위한 계획을 고안하십시오.

  • 양식 처리, 데이터 분석 및 결과보고를위한 절차 수립

데이터 수집 계획은 프로젝트 계획이 시작될 때 시작되어야합니다. 실제 데이터 수집은 여러 개발 단계에서 이루어집니다.

For example − 프로젝트 인원과 관련된 일부 데이터는 프로젝트 시작시 수집 할 수 있으며, 노력과 같은 다른 데이터 수집은 프로젝트 시작시 시작하여 운영 및 유지 보수를 통해 계속됩니다.

데이터 저장 및 추출 방법

소프트웨어 엔지니어링에서 데이터는 데이터베이스에 저장되고 데이터베이스 관리 시스템 (DBMS)을 사용하여 설정되어야합니다. 다음 그림은 데이터베이스 구조의 예입니다. 이 데이터베이스는 조직의 여러 부서에서 일하는 여러 직원의 세부 정보를 저장합니다.

위 다이어그램에서 각 상자는 데이터베이스의 테이블이고 화살표는 한 테이블에서 다른 테이블로의 다 대일 매핑을 나타냅니다. 매핑은 데이터의 논리적 일관성을 유지하는 제약 조건을 정의합니다.

데이터베이스가 설계되고 데이터로 채워지면 데이터 조작 언어를 사용하여 분석 할 데이터를 추출 할 수 있습니다.

관련 데이터를 수집 한 후 적절한 방식으로 분석해야합니다. 분석 기법을 선택할 때 고려해야 할 세 가지 주요 항목이 있습니다.

  • 데이터의 특성
  • 실험의 목적
  • 디자인 고려 사항

데이터의 본질

데이터를 분석하려면 데이터가 나타내는 더 큰 모집단과 해당 데이터의 분포도 살펴 봐야합니다.

샘플링, 채우기 및 데이터 배포

샘플링은 많은 인구에서 데이터 세트를 선택하는 프로세스입니다. 샘플 통계는 실험 대상 그룹에서 얻은 측정을 설명하고 요약합니다.

모집단 매개 변수는 가능한 모든 대상을 측정 한 경우 얻을 수있는 값을 나타냅니다.

모집단 또는 표본은 평균, 중앙값 및 모드와 같은 중심 경향 측정 값과 분산 및 표준 편차와 같은 분산 측정 값으로 설명 할 수 있습니다. 다음 그래프와 같이 많은 데이터 세트가 정상적으로 분포되어 있습니다.

위와 같이 데이터는 평균에 대해 균등하게 분포됩니다. 이것은 정규 분포의 중요한 특성입니다.

다른 분포보다 평균의 한쪽에 더 많은 데이터 포인트가 있도록 데이터가 치우쳐있는 다른 분포도 있습니다. 예 : 대부분의 데이터가 평균의 왼쪽에있는 경우 분포가 왼쪽으로 치우쳐 있다고 말할 수 있습니다.

실험의 목적

일반적으로 실험이 수행됩니다.

  • 이론을 확인하려면
  • 관계를 탐구하려면

이들 각각을 달성하기 위해 목표는 가설 측면에서 공식적으로 표현되어야하며 분석은 가설을 직접 다루어야합니다.

이론을 확인하려면

조사는 이론의 진실을 탐구하도록 설계되어야합니다. 이론은 일반적으로 특정 방법, 도구 또는 기술의 사용이 주제에 특별한 영향을 미치므로 어떤면에서는 다른 것보다 더 좋다고 말합니다.

고려해야 할 두 가지 데이터 사례가 있습니다. normal datanon-normal data.

데이터가 정규 분포의 데이터이고 비교할 두 그룹이있는 경우 학생의 t 검정을 분석에 사용할 수 있습니다. 비교할 그룹이 세 개 이상인 경우 F- 통계라고하는 분산 검정의 일반 분석을 사용할 수 있습니다.

데이터가 비정규 인 경우 순위를 지정하여 Kruskal-Wallis 검정을 사용하여 데이터를 분석 할 수 있습니다.

관계를 탐구하려면

조사는 하나 또는 여러 변수를 설명하는 데이터 포인트 간의 관계를 결정하도록 설계되었습니다.

관계에 대한 질문에 답할 수있는 세 가지 기술이 있습니다. 상자 그림, 산점도 및 상관 분석입니다.

  • box plot 데이터 집합 범위의 요약을 나타낼 수 있습니다.

  • scatter plot 두 변수 간의 관계를 나타냅니다.

  • Correlation analysis 통계적 방법을 사용하여 두 속성간에 실제 관계가 있는지 확인합니다.

    • 정규 분포 값의 경우 Pearson Correlation Coefficient 두 변수의 상관 관계가 높은지 여부를 확인합니다.

    • 비정규 데이터의 경우 데이터의 순위를 매기고 Spearman Rank Correlation Coefficient연관의 척도로. 비정규 데이터에 대한 또 다른 측정은Kendall robust correlation coefficient, 데이터 포인트 쌍 간의 관계를 조사하고 편 상관을 식별 할 수 있습니다.

순위에 많은 수의 동률 값이 포함 된 경우 chi-squared test분할 표에서 변수 간의 연관성을 테스트하는 데 사용할 수 있습니다. 비슷하게,linear regression 변수 간의 관계를 설명하는 방정식을 생성하는 데 사용할 수 있습니다.

두 개 이상의 변수의 경우 multivariate regression 사용할 수 있습니다.

디자인 고려 사항

분석 기법을 선택하는 동안 조사의 설계를 고려해야합니다. 동시에 분석의 복잡성은 선택한 설계에 영향을 미칠 수 있습니다. 여러 그룹은 두 그룹에 대한 Student 's T-test 대신 F- 통계를 사용합니다.

요인이 세 개 이상인 복잡한 요인 설계의 경우 더 정교한 연관성 및 유의성 검정이 필요합니다.

한 세트의 변수가 다른 변수에 미치는 영향을 설명하거나 타이밍 또는 학습 효과를 보상하기 위해 통계 기법을 사용할 수 있습니다.

내부 제품 속성은 제품 자체에만 의존하는 방식으로 소프트웨어 제품을 설명합니다. 내부 제품 속성을 측정하는 주된 이유는 개발 중에 제품을 모니터링하고 제어하는 ​​데 도움이되기 때문입니다.

내부 제품 속성 측정

주요 내부 제품 속성은 다음과 같습니다. sizestructure. 크기는 실행하지 않고도 정적으로 측정 할 수 있습니다. 제품의 크기는 제품을 만드는 데 필요한 노력을 알려줍니다. 마찬가지로 제품의 구조는 제품의 유지 관리를 설계하는 데 중요한 역할을합니다.

크기 측정

소프트웨어 크기는 세 가지 속성으로 설명 할 수 있습니다.

  • Length − 제품의 물리적 인 크기입니다.

  • Functionality − 제품이 사용자에게 제공하는 기능을 설명합니다.

  • Complexity − 복잡성은 다음과 같은 다양한 유형입니다.

    • Problem complexity − 근본적인 문제의 복잡성을 측정합니다.

    • Algorithmic complexity − 문제 해결을 위해 구현 된 알고리즘의 복잡성 측정

    • Structural complexity − 알고리즘 구현에 사용되는 소프트웨어의 구조를 측정합니다.

    • Cognitive complexity − 소프트웨어를 이해하는 데 필요한 노력을 측정합니다.

이 세 가지 속성의 측정은 다음과 같이 설명 할 수 있습니다.

길이

크기 측정이 예측에 필요한 노력을 예측하는 데 유용한 세 가지 개발 제품이 있습니다. 그것들은 사양, 디자인 및 코드입니다.

사양 및 디자인

이러한 문서는 일반적으로 텍스트, 그래프, 특수 수학적 다이어그램 및 기호를 결합합니다. 사양 측정은 디자인의 길이를 예측하는 데 사용할 수 있으며, 이는 코드 길이의 예측 변수입니다.

문서의 다이어그램에는 레이블이 지정된 digraph, 데이터 흐름 다이어그램 또는 Z 스키마와 같은 통일 된 구문이 있습니다. 사양 및 디자인 문서는 텍스트와 다이어그램으로 구성되어 있으므로 텍스트 길이와 다이어그램 길이를 나타내는 숫자 쌍으로 길이를 측정 할 수 있습니다.

이러한 측정을 위해 원자 객체는 다양한 유형의 다이어그램 및 기호에 대해 정의됩니다.

데이터 흐름 다이어그램의 원자 적 개체는 프로세스, 외부 엔터티, 데이터 저장소 및 데이터 흐름입니다. 대수 사양에 대한 원자 적 엔티티는 정렬, 함수, 연산 및 공리입니다. Z 스키마에 대한 원자 엔티티는 사양에 나타나는 다양한 행입니다.

암호

코드는 절차 적 언어, 개체 방향 및 시각적 프로그래밍과 같은 다양한 방식으로 생성 될 수 있습니다. 가장 일반적으로 사용되는 소스 코드 프로그램 길이 측정 방법은 코드 라인 (LOC)입니다.

총 길이,

LOC = NCLOC + CLOC

즉,

LOC = Non-commented LOC + Commented LOC

코드 줄 외에도 Maurice Halsted가 제안한 크기 및 복잡성과 같은 다른 대안도 길이 측정에 사용할 수 있습니다.

Halstead의 소프트웨어 과학은 프로그램의 다른 속성을 포착하려고 시도했습니다. 그는 크기에 대한 다양한 관점을 반영하는 길이, 어휘 및 볼륨과 같은 세 가지 내부 프로그램 속성을 제안했습니다.

그는 프로그램을 정의하는 것으로 시작했습니다. P연산자 또는 피연산자로 분류 된 토큰 모음입니다. 이 토큰에 대한 기본 메트릭은 다음과 같습니다.

  • μ1 = 고유 연산자 수

  • μ2 = 고유 한 피연산자 수

  • N1 = 연산자의 총 발생

  • N2 = 고유 연산자 수

길이 P 다음과 같이 정의 할 수 있습니다.

$$N = N_{1}+ N_{2}$$

어휘 P 이다

$$\mu =\mu _{1}+\mu _{2}$$

프로그램의 양 = 길이의 프로그램을 작성하는 데 필요한 정신적 비교 횟수 N

$$V = N\times {log_{2}} \mu$$

프로그램의 프로그램 수준 P 볼륨 V 이다,

$$L = \frac{V^\ast}{V}$$

어디, $V^\ast$ 잠재적 인 볼륨, 즉 최소 크기 구현의 볼륨입니다. P

레벨의 역은 난이도입니다-

$$D = 1\diagup L$$

Halstead 이론에 따르면 추정치를 계산할 수 있습니다. L 같이

$${L}' = 1\diagup D = \frac{2}{\mu_{1}} \times \frac{\mu_{2}}{N_{2}}$$

마찬가지로 예상 프로그램 길이는 다음과 같습니다. $\mu_{1}\times log_{2}\mu_{1}+\mu_{2}\times log_{2}\mu_{2}$

P를 생성하는 데 필요한 노력은 다음과 같습니다.

$$E = V\diagup L = \frac{\mu_{1}N_{2}Nlog_{2}\mu}{2\mu_{2}}$$

측정 단위 E 이해하는 데 필요한 기본 정신적 차별입니다 P

길이를 측정하는 다른 대안은 다음과 같습니다.

  • 프로그램 텍스트에 필요한 컴퓨터 저장 공간의 바이트 수

  • 프로그램 텍스트의 문자 수 측면에서

객체 지향 개발은 길이를 측정하는 새로운 방법을 제안합니다. Pfleeger et al. 객체와 메서드의 개수가 코드 줄을 사용하는 것보다 더 정확한 생산성 추정치를 이끌어내는 것을 발견했습니다.

기능성

제품에 내재 된 기능의 양은 제품 크기를 측정합니다. 소프트웨어 제품의 기능을 측정하는 방법은 매우 다양합니다. 다음 장에서 이러한 방법 중 하나 인 Albrecht의 기능 점수 방법에 대해 논의 할 것입니다.

기능 포인트 메트릭은 소프트웨어 애플리케이션의 다양한 기능을 측정하기위한 표준화 된 방법을 제공합니다. 사용자의 관점, 즉 사용자가 그 대가로 요청하고받는 것을 기반으로 기능을 측정합니다. 기능 점 분석은 사용자의 관점에서 소프트웨어 개발을 측정하는 표준 방법입니다.

Albrecht가 원래 고안 한 기능 점수 측정은 1986 년 국제 기능 점수 사용자 그룹 (IFPUG)이 시작되면서 인기가 높아졌습니다. 2002 년에 IFPUG 기능 점수는 국제 ISO 표준 인 ISO / IEC 20926이되었습니다.

기능 포인트는 무엇입니까?

FP (Function Point)소프트웨어 애플리케이션을 정량화하는 데 적합한 가장 널리 퍼진 기능 유형 메트릭입니다. 이는 두 가지 데이터 함수 유형과 세 가지 트랜잭션 함수 유형으로 나뉘는 5 명의 사용자 식별 가능한 논리적 "함수"를 기반으로합니다. 주어진 소프트웨어 응용 프로그램에 대해 이러한 각 요소는 정량화되고 가중치가 부여되어 파일 참조 또는 논리 필드와 같은 특성 요소를 계산합니다.

결과 숫자 (조정되지 않은 FP)는 ​​추가, 변경 또는 삭제 된 기능 세트로 그룹화되고 값 조정 계수 (VAF)와 결합되어 최종 FP 수를 얻습니다. 각 계수 유형 (응용 프로그램, 개발 프로젝트 또는 향상 프로젝트)에 대해 고유 한 최종 공식이 사용됩니다.

Albrecht의 기능 포인트 방법 적용

이제 Albrecht의 Function Point 방법을 적용하는 방법을 이해하겠습니다. 그 절차는 다음과 같습니다-

구성 요소 수 (EI, EO, EQ, ILF 및 ELF) 결정

  • EI− 외부 입력의 수. 파생 된 데이터가 경계를 넘어 외부에서 내부로 전달되는 기본 프로세스입니다. 예시 도서관 데이터베이스 시스템에서 기존 고객의 도서관 카드 번호를 입력합니다.

  • EO− 외부 출력의 수. 파생 된 데이터가 경계를 넘어 내부에서 외부로 전달되는 기본 프로세스입니다. 예제 도서관 데이터베이스 시스템에서 고객에게 대출 된 도서 목록을 표시합니다.

  • EQ− 외부 쿼리의 수. 이는 하나 이상의 내부 논리 파일 및 외부 인터페이스 파일에서 데이터를 검색하는 입력 및 출력 구성 요소가 모두있는 기본 프로세스입니다. 예제 도서관 데이터베이스 시스템에서 현재 고객에게 대출 된 도서를 확인합니다.

  • ILF− 내부 로그 파일 수. 이들은 외부 입력을 통해 유지되는 애플리케이션 경계 내에 완전히 상주하는 논리적으로 관련된 데이터의 사용자 식별 가능 그룹입니다. 예제 도서관 데이터베이스 시스템에서 도서관의 책 파일.

  • ELF− 외부 로그 파일의 수. 이들은 참조 목적으로 만 사용되며 완전히 시스템 외부에 상주하는 논리적으로 관련된 데이터의 사용자 식별 가능 그룹입니다. 예제 라이브러리 데이터베이스 시스템에서 라이브러리의 청구 시스템의 트랜잭션을 포함하는 파일입니다.

조정되지 않은 UFC (Function Point Count) 계산

  • 각 구성 요소를 다음과 같이 평가하십시오. low, average, 또는 high.

  • 거래 용 (EI, EO, and EQ), 등급은 FTRDET.

    • FTR − 업데이트 또는 참조 된 파일 수.

    • DET − 사용자가 인식 할 수있는 필드의 수.

    • 다음 표에 따라 EI 2 개의 파일과 10 개의 데이터 요소를 참조하는 것은 다음과 같이 순위가 매겨집니다. average.

FTR DET
1-5 6-15 >15
0-1 낮은 낮은 평균
2-3 낮은 평균 높은
>3 평균 높은 높은
  • 파일 (ILF and ELF), 등급은 RETDET.

    • RET − 사용자가 인식 할 수있는 데이터 요소의 수 ILF 또는 ELF.

    • DET − 사용자가 인식 할 수있는 필드의 수.

    • 다음 표에 따라 ILF 10 개의 데이터 요소와 5 개의 필드가 포함 된 high.

RET DET
1-5 6-15 >15
1 낮은 낮은 평균
2-5 낮은 평균 높은
>5 평균 높은 높은
  • 평가를 다음으로 변환 UFCs.

평가 가치
EO EQ EI ILF ELF
Low 4 7 5
Average 5 4 4 10 7
High 6 5 6 15 10

FPC (Final Function Point Count) 계산

  • 값 조정 계수 계산 (VAF) 14 개의 일반 시스템 특성을 기반으로 (GSC).

일반 시스템 특성 간단한 설명
GSC 1 데이터 통신 애플리케이션 또는 시스템과의 정보 전송 또는 교환을 지원하기 위해 얼마나 많은 통신 시설이 있습니까?
GSC 2 분산 데이터 처리 분산 데이터 및 처리 기능은 어떻게 처리됩니까?
GSC 3 공연 사용자에게 필요한 응답 시간 또는 처리량입니까?
GSC 4 많이 사용되는 구성 애플리케이션이 실행될 현재 하드웨어 플랫폼은 얼마나 많이 사용됩니까?
GSC 5 거래 율 거래는 매일, 매주, 매월 등 얼마나 자주 실행됩니까?
GSC 6 온라인 데이터 입력 온라인으로 입력되는 정보의 비율은 얼마입니까?
GSC 7 최종 사용자 효율성 최종 사용자의 효율성을 위해 애플리케이션이 설계 되었습니까?
GSC 8 온라인 업데이트 온라인 거래로 얼마나 많은 ILF가 업데이트됩니까?
GSC 9 복잡한 처리 응용 프로그램에 광범위한 논리 또는 수학적 처리가 있습니까?
GSC 10 재사용 성 응용 프로그램이 한 명 또는 여러 사용자의 요구를 충족하도록 개발 되었습니까?
GSC 11 설치 용이성 변환 및 설치가 얼마나 어렵습니까?
GSC 12 운영 용이성 시작, 백업 및 복구 절차가 얼마나 효과적이고 / 또는 자동화되어 있습니까?
GSC 13 여러 사이트 응용 프로그램이 여러 조직의 여러 사이트에 설치되도록 특별히 설계, 개발 및 지원 되었습니까?
GSC 14 변화 촉진 변경을 용이하게하기 위해 응용 프로그램이 특별히 설계, 개발 및 지원 되었습니까?
  • 각각 무게 GSC 강한 영향에 영향을 미치지 않는지 여부에 따라 0에서 5까지의 척도입니다.

  • 계산 FPC 다음과 같이-

    FPC = UFC * (0.65+ (합 (GSC) * .01))

복잡성

복잡성은 크기의 별도 구성 요소입니다. 그것은 두 가지 유형입니다-

  • Complexity of a problem − 문제에 대한 최적의 솔루션에 필요한 자원의 양입니다.

  • Complexity of a solution− 특정 솔루션을 구현하는 데 필요한 리소스입니다. 두 가지 측면이 있습니다. 그들은 다음과 같습니다-

    • Time complexity − 리소스는 컴퓨터 시간입니다.

    • Space complexity − 리소스는 컴퓨터 메모리입니다.

복잡성 측정

복잡성의 한 측면은 효율성입니다. 알고리즘으로 모델링 할 수있는 모든 소프트웨어 제품을 측정합니다.

예 : 특정 문제의 모든 인스턴스를 해결하기위한 알고리즘에 f(n) 계산, 다음 f(n) 문제를 해결하는 복잡성 g를 가진 다른 모든 알고리즘에 대해 점근 적으로 최적입니다. f 이다 O(g). 그러면 주어진 문제의 복잡성이 커집니다.O 문제의 솔루션에 대한 점근 적으로 최적의 알고리즘입니다.

소프트웨어의 구조적 특성 측정은 제품의 유지 관리뿐 아니라 개발 노력을 추정하는 데 중요합니다. 요구 사항, 디자인 및 코드의 구조는 한 제품을 다른 제품으로 변환하거나 제품을 테스트하거나 초기 내부 제품 측정에서 외부 소프트웨어 속성을 예측할 때 발생하는 어려움을 이해하는 데 도움이됩니다.

구조적 측정의 유형

소프트웨어의 구조는 세 부분으로 구성됩니다. 그들은-

  • Control-flow structure − 프로그램에서 명령이 실행되는 순서입니다.

  • Data-flow structure − 프로그램과 상호 작용할 때 데이터의 동작입니다.

  • Data structure − 생성, 수정 또는 삭제를위한 알고리즘과 함께 목록, 대기열, 스택 또는 기타 잘 정의 된 구조의 형태로 데이터 요소의 구성입니다.

제어 흐름 구조 측정

제어 흐름 측정은 일반적으로 각 노드 또는 포인트가 프로그램 명령문에 해당하는 방향성 그래프로 모델링되고 각 호 또는 방향성 에지는 한 명령문에서 다른 명령문으로의 제어 흐름을 나타냅니다. 이러한 그래프를 제어 흐름 그래프 또는 유 방향 그래프라고합니다.

If ‘m’ is a structural measure defined in terms of the flow graph model, and if program A is structurally more complex than program B, then the measure m(A) should be greater than m(B).

Measuring Data-Flow Structure

Data flow or information flow can be inter-modular (flow of information within the modules) or intra-modular (flow of information between individual modules and the rest of the system).

According to the way in which data is moving through the system, it can be classified into the following −

  • Local direct flow − If either a module invokes a second module and passes information to it or the invoked module returns a result to the caller.

  • Local indirect flow − If the invoked module returns information that is subsequently passed to a second invoked module.

  • Global flow − If information flows from one module to another through a global data structure.

Information flow complexity can be expressed according to Henry and Kafura as,

Information flow complexity (M) = length (M) × fan-in (M) × (fan-out (M))2

Where,

  • Fan-in (M) − The number of local flows that terminate at M + the number of data structures from which the information is retrieved by M.

  • Fan–out (M) − The number of local flows that emanate from M + the number of data structures that are updated by M.

Measuring Data Structure

Data structure can be both local and global.

Locally, the amount of structure in each data item will be measured. A graph-theoretic approach can be used to analyze and measure the properties of individual data structures. In that simple data types such as integers, characters, and Booleans are viewed as primes and the various operations that enable us to build more complex data structures are considered. Data structure measures can then be defined hierarchically in terms of values for the primes and values associated with the various operations.

Globally, 사용자 정의 변수의 총 개수가 측정됩니다.

여러 국내 및 국제 표준 기관, 전문 및 산업 지향 조직이 SQA 표준 개발에 참여했습니다.

다음 기관 및 조직은 SQA 및 소프트웨어 엔지니어링 표준의 주요 개발자입니다.

  • IEEE (전기 전자 공학회) 컴퓨터 학회
  • ISO (국제 표준화기구)
  • DOD (미국 국방부)
  • ANSI (미국 표준 협회)
  • IEC (국제 전기 기술위원회)
  • EIA (전자 산업 협회)

이러한 조직은 소프트웨어 개발 및 유지 관리 조직에서 수행되는 전문 및 관리 활동의 품질에 대한 업데이트 된 국제 표준을 제공합니다.

또한 독립적 인 전문 품질 감사를 통해 SQA 인증을 제공합니다. 이러한 외부 감사는 SQA 시스템 개발 및 구현의 성과를 평가합니다. 정기 감사 후 부여되는 인증은 다음 감사까지만 유효하므로 갱신해야합니다. 현재 ISO 9000 인증 서비스는 유럽 및 기타 국가에서 가장 유명한 SQA 인증 제공 업체입니다.

또한 조직의 SQA 시스템 및 운영에 대한 자체 평가 도구를 제공합니다. SEI (Software Engineering Institute), Carnegie Mellon University 및 ISO / IEC Std 15504에서 개발 한 CMM (Capacity Maturity Model)이 이러한 접근 방식의 예입니다.

SQA 표준

소프트웨어 품질 보증 표준은 두 가지 주요 클래스로 분류 할 수 있습니다.

  • 인증 및 평가 방법론을 포함한 소프트웨어 품질 보증 관리 표준 (품질 관리 표준)

  • 소프트웨어 프로젝트 개발 프로세스 표준 (프로젝트 프로세스 표준)

품질 관리 기준

이들은 조직의 SQA 시스템, 인프라 및 요구 사항에 초점을 맞추고 방법과 도구의 선택은 조직에 맡깁니다. 품질 관리 표준을 통해 조직은 소프트웨어 제품이 허용 가능한 품질 수준을 달성하도록 꾸준히 보장 할 수 있습니다.

Example − ISO 9000-3 및 CMM (Capability Maturity Model)

프로젝트 프로세스 표준

이들은 소프트웨어 개발 및 유지 관리 프로젝트를 구현하기위한 방법론에 중점을 둡니다. 이러한 표준에는 다음이 포함됩니다.

  • 취해야 할 단계
  • 설계 문서 요구 사항
  • 디자인 문서의 내용
  • 디자인 검토 및 검토 문제
  • 수행 할 소프트웨어 테스트
  • 주제 테스트

당연히이 클래스의 많은 SQA 표준은 그 특성으로 인해 소프트웨어 엔지니어링 표준으로 사용되며 그 반대의 경우도 마찬가지입니다.

이 두 가지 표준 클래스의 특성은 다음 표에 요약되어 있습니다.

형질 품질 관리 기준 프로젝트 프로세스 표준
목표 단위 소프트웨어 개발, 유지 보수 및 특정 SQA 단위 관리 소프트웨어 개발 및 유지 관리 프로젝트 팀
주요 초점 SQA 시스템, 인프라 및 요구 사항의 구성 소프트웨어 개발 및 유지 보수 프로젝트를 수행하기위한 방법론
표준의 목표 달성 할 "무엇" 수행 방법
표준의 목표 공급 업체의 소프트웨어 품질 보장 및 소프트웨어 프로세스 능력 평가 공급 업체의 소프트웨어 품질 보장 및 소프트웨어 프로세스 능력 평가 특정 소프트웨어 프로젝트의 품질 보장.
ISO 9000-3 SEI의 CMM ISO / IEC 12207 IEEEStd 1012-1998

ISO 9001 인증

ISO (International Organization for Standardization)는 국가 표준기구의 세계적인 연합입니다. ISO 기술위원회는 국제 표준을 준비합니다. ISO는 전기 기술 표준화의 모든 문제에 대해 IEC (International Electro-technical Commission)와 긴밀히 협력합니다.

국제 표준은 ISO / IEC Directives, Part 2의 규칙에 따라 작성됩니다. 기술위원회에서 채택한 국제 표준 초안은 투표를 위해 회원 기관에 회람됩니다. ISO 9001은 기술위원회 ISO / TC 176, 품질 관리 및 품질 보증, 소위원회 SC 2, 품질 시스템에 의해 준비되었습니다.

프로세스 접근 방법

이 국제 표준은 고객 요구 사항을 충족함으로써 고객 만족도를 높이기 위해 품질 관리 시스템의 효과를 개발, 구현 및 개선 할 때 프로세스 접근 방식의 채택을 장려합니다. 조직이 효과적으로 기능하려면 연결된 수많은 활동을 결정하고 관리해야합니다. 자원을 사용하고 입력을 출력으로 변환하기 위해 관리되는 활동 또는 활동 세트는 프로세스로 간주 될 수 있습니다.

종종 한 프로세스의 출력이 다음 프로세스의 입력을 직접 형성합니다. 이러한 프로세스의 식별 및 상호 작용과 함께 조직 내 프로세스 시스템의 적용 및 원하는 결과를 생성하기위한 관리를 다음과 같이 지칭 할 수 있습니다.“process approach”.

프로세스 접근 방식의 장점은 프로세스 시스템 내의 개별 프로세스 간 연결과 그 조합 및 상호 작용에 대해 제공하는 지속적인 제어입니다. 품질 관리 시스템 내에서 사용되는 경우 이러한 접근 방식은 다음 사항의 중요성을 강조합니다.

  • 요구 사항 이해 및 충족
  • 부가가치 측면에서 프로세스 고려 필요
  • 프로세스 성능 및 효과의 결과 얻기
  • 객관적인 측정을 기반으로 한 프로세스의 지속적인 개선

ISO 9001-소프트웨어 적용 : TickIT 이니셔티브

TickIT는 TickIT 이니셔티브로 알려진 소프트웨어 산업의 특성에 ISO 9001을 적용하는 방법론의 개발을 촉진하기 위해 영국 무역 산업부와 협력하여 영국 소프트웨어 산업에 의해 1980 년대 후반에 시작되었습니다.

TickIT는 또한 정보 기술 (IT)을 전문으로합니다. 여기에는 상용 소프트웨어 개발 및 유지 보수 서비스의 전체 범위가 포함됩니다. 현재 BSI의 DISC 부서 (British Standards Institute)에서 관리 및 유지 관리하는 TickIT는 영국과 스웨덴의 IT 조직 인증을 받았습니다.

그 활동은 다음과 같습니다-

  • ISO 9001 인증을 전파하기위한 소프트웨어 업계의 노력을 지원하는 TickIT 가이드 발행. ISO / IEC 12207 및 ISO / IEC 15504에 대한 참조가 포함 된 최신 가이드 (버전 5.0, TickIT, 2001)는 모든 TickIT 고객에게 배포됩니다.

  • 소프트웨어 품질 시스템에 대한 감사 기반 평가 수행 및 관리 외에 소프트웨어 개발 및 유지 관리 프로세스 개선에 대한 조직 자문.

  • ISO 9000 인증 감사를 수행합니다.

감사 기반 평가 및 인증 감사를 수행하는 TickIT 감사자는 IRCA (International Register of Certificated Auditors)에 등록되어 있습니다. 등록 된 IRCA 감사관은 무엇보다도 관리 및 소프트웨어 개발 경험이 있어야합니다. 또한 심사원 과정을 성공적으로 완료해야합니다.

등록 된 선임 감사자는 TickIT 감사를 수행하고 지시하는 데있어 입증 된 경험이 있어야합니다.

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

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

  • 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 (Standard CMMI Assessment Method for Process Improvement)가 개발되었습니다 (Software Engineering Institute, 2000). 또한 CBA IPI를 기반으로합니다. CBA IPI와 SCAMPI는 세 단계로 구성됩니다.

  • 계획 및 준비
  • 현장 평가 수행
  • 결과보고

계획 및 준비 단계의 활동에는 다음이 포함됩니다.

  • 평가 범위 식별
  • 평가 계획 개발
  • 평가 팀 준비 및 교육
  • 참가자에 대한 간략한 평가
  • CMMI 평가 설문지 관리
  • 설문 응답 검토
  • 초기 문서 검토 수행

현장 평가 단계의 활동은 다음과 같습니다.

  • 개회식 개최
  • 인터뷰 실시
  • 정보 통합
  • 결과 초안 프레젠테이션 준비
  • 결과 초안 발표
  • 최종 결과를 통합, 평가 및 준비

보고 결과 단계의 활동에는 다음이 포함됩니다.

  • 최종 결과 발표
  • 집행 세션 실시
  • 평가 마무리

소프트웨어 품질 보증에 대한 IEEE 정의는 다음과 같습니다.

"항목 또는 제품이 확립 된 기술 요구 사항을 준수한다는 적절한 확신을 제공하는 데 필요한 모든 조치의 계획되고 체계적인 패턴. 제품이 개발 또는 제조되는 프로세스를 평가하도록 설계된 일련의 활동."

SQA 활동의 목표

SQA 활동의 목적은 다음과 같습니다.

소프트웨어 개발 (프로세스 지향)

  • 소프트웨어가 기능적 기술 요구 사항을 준수 할 것이라는 허용 가능한 수준의 신뢰를 보장합니다.

  • 소프트웨어가 관리 일정 및 예산 요구 사항을 준수 할 것이라는 허용 가능한 수준의 신뢰를 보장합니다.

  • 소프트웨어 개발 및 SQA 활동의 개선 및 효율성 향상을위한 활동 시작 및 관리.

소프트웨어 유지 관리 (제품 지향)

  • 소프트웨어 유지 관리 활동이 기능적 기술 요구 사항을 준수 할 것이라는 확신 수준을 허용합니다.

  • 소프트웨어 유지 관리 활동이 관리 일정 및 예산 요구 사항을 준수 할 것이라는 확신을 가질 수있는 수준으로 보장합니다.

  • 소프트웨어 유지 관리 및 SQA 활동의 효율성을 개선하고 높이기위한 활동을 시작하고 관리합니다. 여기에는 비용을 줄이면서 기능적 및 관리적 요구 사항을 달성 할 가능성을 개선하는 것이 포함됩니다.

품질 보증을위한 조직

조직 구조 내에서 작동하는 품질 보증 조직 프레임 워크에는 다음 참가자가 포함됩니다.

관리자

  • 최고 경영진, 특히 소프트웨어 품질 보증을 직접 담당하는 경영진

  • 소프트웨어 개발 및 유지 관리 부서 관리자

  • 소프트웨어 테스트 부서 관리자

  • 개발 및 유지 보수 프로젝트의 프로젝트 관리자 및 팀 리더

  • 소프트웨어 테스트 팀의 리더

테스터

  • 소프트웨어 테스트 팀의 구성원

SQA 전문가 및 관심있는 실무자-

  • SQA 수탁자
  • SQA위원회 구성원
  • SQA 포럼 회원
  • SQA 단위 팀원

소프트웨어 테스트 부서의 관리자와 직원 만이 SQA 작업 수행에 풀 타임으로 참여합니다. 다른 사람들은 관리 기능이나 전문 작업을 수행하는 동안 또는 다른 사람들의 자원 봉사자, 대부분의 경우 SQA위원회, SQA 포럼 또는 SQA 관리인으로서 품질 문제에 시간의 일부를 바칩니다.

기본적으로 소프트웨어 개발 조직에는 3 단계 관리 구조가 있습니다.

  • 최고 경영진
  • 부서 관리
  • 프로젝트 관리

소프트웨어 품질에 대한 최고 경영진의 책임

다음은 소프트웨어 품질을 보장하는 최고 경영진의 책임입니다-

  • 회사의 소프트웨어 제품 및 소프트웨어 유지 관리 서비스의 품질 보장

  • 모든 수준의 직원에게 고객 만족과 함께 제품 및 서비스 품질의 중요성을 전달합니다.

  • 만족스러운 기능과 고객 요구 사항의 완전한 준수 보장

  • 조직의 SQA 시스템에 대한 품질 목표가 설정되고 목표가 달성되었는지 확인합니다.

  • 조직의 고객, 경쟁 및 기술과 관련된 주요 내부 및 외부 변화에 SQA 시스템을 적용하는 데 필요한 변경 사항의 계획을 시작하고 구현을 감독합니다.

  • 위기 상황 해결을 지원하고 피해를 최소화하기 위해 직접 개입

  • SQA 시스템에 필요한 리소스의 가용성 보장

다음 단계는 최고 경영진이 책임을 다하기 위해 취할 수 있습니다.

  • 조직의 소프트웨어 품질 정책을 수립하고 업데이트합니다.

  • SQA 부사장 등 중역 중 한 명에게 소프트웨어 품질 문제를 담당하도록 지정

  • 소프트웨어 품질 문제에 대한 성과에 대한 정기적 인 관리 검토 수행

소프트웨어 품질 정책

조직의 소프트웨어 품질 정책은 다음 요구 사항을 전달해야합니다.

  • 조직의 목적과 목표에 대한 적합성

  • 일반 소프트웨어 품질 보증 개념에 대한 약속

  • 조직에서 채택한 품질 표준에 대한 약속

  • 소프트웨어 품질 보증을위한 적절한 리소스 할당에 대한 약속

  • 조직의 품질과 생산성을 지속적으로 개선하기위한 노력

소프트웨어 품질 담당 임원

소프트웨어 품질 문제를 담당하는 임원의 책임은 다음과 같이 분류 될 수 있습니다.

  • 연간 SQA 활동 프로그램 및 예산 준비에 대한 책임

  • SQA 시스템 개발 계획 준비에 대한 책임

  • 연간 SQA 정기 활동 프로그램 및 계획된 SQA 개발 프로젝트의 구현에 대한 전반적인 통제

  • 경영진에게 SQA 문제 발표 및 옹호

연간 SQA 활동 프로그램 준비에 대한 책임

이것은 경영진이-

  • 내년 시스템의 SQA 목표 설정

  • 연간 활동 프로그램을 위해 SQA 단위에서 준비한 제안을 검토하고 SQA 시스템에 설정된 목표를 달성 할 수있는 제안의 잠재력을 확인합니다.

  • 활동 프로그램이 내년에 계획된 하청 업체 서비스 및 소프트웨어 구매의 특성과 범위에 적합한 지 확인합니다.

  • SQA 프로그램 구현을 위해 계획된 인력 및 기타 자원의 적절성 결정

  • 연간 SQA 활동 프로그램 및 예산의 최종 버전 승인

SQA 시스템 개발 계획 준비에 대한 책임

이러한 계획은 고객의 요구와 경쟁뿐만 아니라 기술의 변화에도 적응할 수 있어야합니다. 책임은 다음과 같습니다-

  • 가까운 장래에 조직의 소프트웨어 품질에 영향을 미칠 것으로 예상되는 추세 검토

  • 새로운 도구 및 SQA 표준에 적합한 새로운 절차의 준비와 같은 SQA 적응을위한 제안 검토

  • 베테랑 소프트웨어 개발 팀 및 새로 채용 된 팀원을위한 교육 프로그램 준비

  • 교육 프로그램의 성공은 물론 새로운 도구 및 표준을 평가하는 데 적합한 소프트웨어 품질 메트릭 개발

  • 일정 및 예산을 포함하여 계획된 SQA 개발 프로젝트의 최종 버전 승인

연간 SQA 프로그램 구현의 전반적인 통제

담당 임원은-

  • 연간 활동 프로그램의 일반 감독

  • SQA 적응 프로젝트의 진행 상황 검토

  • 팀의 목표에 따른 품질 성과를 실현하기 위해 취한 조치에 대한 일반 감독 (정기 보고서 기반)

  • 내부 품질 감사를 기반으로 SQA 절차 및 표준 준수 검토

  • 소프트웨어 개발 프로젝트 일정 및 예산 준수에 대한 일반적인 후속 조치

  • 외부 및 내부 고객에게 품질 유지 보수 서비스 제공에 대한 일반적인 후속 조치

경영진에게 SQA 문제 발표 및 옹호

품질을 높이고 SQA 시스템의 어려움을 해결하려면 다음이 필요합니다.

  • 제안 된 연간 활동 프로그램 및 예산의 최종 승인을위한 프레젠테이션

  • 계획된 SQA 적응 프로젝트의 최종 승인을위한 프레젠테이션과 해당 예산

  • 조직의 소프트웨어 품질에 전념하는 정기적 인 관리 검토 회의 시작 및 리더십

  • 심각한 품질 실패, 심각한 전문 인력 부족으로 인한 프로젝트의 성공적인 완료에 대한 위협, SQA 부서의 관리 위기 등과 같은 특별한 소프트웨어 품질 이벤트에 대한 경영진 수준의 논의 시작

SQA에 대한 부서 관리 책임

중간 경영진의 품질 보증 책임은 다음과 같습니다.

  • 소프트웨어 품질 관리 시스템 관리 (품질 시스템 관련 업무)

  • 특정 관리자 권한의 단위 또는 팀이 수행하는 프로젝트 및 서비스 관련 업무 관리 (프로젝트 관련 업무)

품질 시스템 관련 책임

여기에는 부서 수준에서 수행 할 SQA 활동이 포함됩니다.

  • SQA 부서에서 준비한 권장 프로그램을 기반으로 부서의 연간 SQA 활동 프로그램 및 예산 준비

  • SQA 부서에서 준비한 권장 계획을 기반으로 부서의 SQA 시스템 개발 계획 작성

  • 부서의 연간 SQA 활동 프로그램 및 개발 프로젝트의 성능 제어

  • 부서의 SQA 문제를 최고 경영진에게 프레젠테이션

프로젝트 관련 책임

이는 조직의 절차 및 권한 분배에 따라 다릅니다. 그들은 일반적으로 포함합니다-

  • CAB, SCM 및 SCCA 기관을 포함한 부서 단위의 품질 보증 절차에 대한 준수 제어

  • 계약 검토 결과 및 제안 승인에 대한 자세한 후속 조치

  • 계획된 검토 활동의 단위 성과 검토 프로젝트 문서 승인 및 프로젝트 단계 완료

  • 소프트웨어 테스트 및 테스트 결과의 후속 조치 프로젝트의 소프트웨어 제품 승인

  • 소프트웨어 개발 프로젝트 일정 및 예산 편차의 진행 상황에 대한 후속 조치

  • 일정, 예산 및 고객 관계 문제를 해결하기 위해 프로젝트 관리자에게 조언 및 지원

  • 유지 보수 서비스 제공의 후속 조치

  • 프로젝트 위험 및 솔루션에 대한 자세한 후속 조치

  • 고객 요구 사항 및 고객 만족도에 대한 프로젝트의 후속 조치

  • 대규모 소프트웨어 변경 주문 및 프로젝트 사양과의 상당한 편차 승인

소프트웨어 품질에 대한 프로젝트 관리 책임

대부분의 프로젝트 관리 책임은 절차 및 작업 지침에 정의되어 있습니다. 프로젝트 관리자는 모든 팀원이 상기 절차 및 지침을 준수하는지 확인하는 책임자입니다.

그의 업무에는 특히 다음과 같은 전문적인 실무 및 관리 업무가 포함됩니다.

  • Professional hands-on tasks

    • 프로젝트 준비 및 품질 계획 및 업데이트

    • 고객-공급자 공동위원회 참여

    • 모집, 교육 및 교육에 참석하는 것을 포함하여 프로젝트 팀 직원의 긴밀한 후속 조치

  • Management tasks

    프로젝트 관리자는 다음과 같은 후속 문제를 해결합니다.

    • 검토 활동 수행 및 그에 따른 수정

    • 소프트웨어 개발 및 유지 보수 부서의 성능, 통합 및 시스템 테스트 활동과 수정 및 회귀 테스트

    • 수락 테스트의 성능

    • 원격 고객 사이트에 소프트웨어 설치 및 고객에 의한 소프트웨어 시스템 실행

    • 프로젝트 팀원의 SQA 교육 및 교육

    • 프로젝트 활동에 할당 된 일정 및 자원

    • 고객 요청 및 만족

    • 진화하는 프로젝트 개발 위험, 솔루션 적용 및 결과 제어

SQA 단위의 구조는 조직의 유형과 규모에 따라 다릅니다. 다음 그림은 표준 구조의 예와 SQA 단위의 모든 구성 요소를 보여줍니다. 이 장에서는 각 하위 단위의 역할과 책임에 대해 설명합니다.

SQA 부서장이 수행하는 작업

SQA 부서의 책임자는 SQA 부서와 하위 부서가 수행하는 모든 품질 보증 작업을 담당합니다. 이러한 작업은 다음 범주로 분류 할 수 있습니다.

  • 계획 작업
  • 단위 관리
  • SQA 전문 활동

계획 작업

  • 제안 된 연간 활동 프로그램 및 단위 예산 준비

  • 조직의 소프트웨어 품질 관리 시스템 계획 및 업데이트

  • 소프트웨어 개발 및 유지 관리 부서에 권장되는 연간 SQA 활동 프로그램 및 SQA 시스템 개발 계획 준비

관리 업무

  • SQA 팀 활동 관리

  • SQA 활동 프로그램의 구현 모니터링

  • 팀 구성원, SQA위원회 구성원 및 SQA 관리위원회 지명

  • 특별 및 정기 보고서 작성 (예 : 조직 내 소프트웨어 품질 문제 상태 및 월간 성과 보고서)

SQA 전문 활동

  • 프로젝트 합동위원회 참여
  • 공식적인 디자인 검토에 참여
  • 사양 편차 검토 및 승인
  • 프로젝트 관리자 및 팀 리더와의 상담
  • SQA위원회 및 포럼 참여

프로젝트 수명주기 SQA

프로젝트 수명주기 하위 단위와 관련된 SQA 작업은 두 그룹으로 분류 될 수 있습니다.

  • "순수한"관리 후속 조치 및 승인 작업 (프로젝트 수명주기 제어 작업)

  • 전문적 기여가 필요한 프로젝트 팀 SQA 활동에 "실무"또는 적극적인 참여 (참여 작업)

프로젝트 라이프 사이클 제어 작업

  • SQA 절차 및 작업 지침을 준수하는 개발 및 유지 관리 팀의 후속 조치

  • 관련 절차에 따른 소프트웨어 제품의 승인 또는 추천

  • 내부 및 외부 고객에 대한 소프트웨어 유지 관리 서비스 제공 모니터링

  • 고객 만족도 모니터링 및 고객 품질 보증 담당자와의 연락 유지

참여 과제

이러한 작업에는 참여가 포함됩니다.

  • 계약 검토
  • 프로젝트 개발 및 품질 계획의 준비 및 업데이트
  • 공식적인 디자인 검토
  • 협력 업체의 공식 설계 검토
  • 고객 승인 테스트를 포함한 소프트웨어 테스트
  • 협력 업체 소프트웨어 제품의 소프트웨어 수용 테스트
  • 새로운 소프트웨어 제품 설치

SQA 인프라 운영 작업

SQA 시스템은 원활하게 작동하기 위해 다양한 인프라 구성 요소를 사용합니다.

  • 절차 및 작업 지침
  • 고품질 장치 지원 (템플릿, 체크리스트)
  • 직원 교육, 교육 및 인증
  • 예방 및 시정 조치
  • 구성 관리
  • 문서 관리

보다 구체적으로, 이러한 구성 요소와 관련된 SQA 하위 단위의 작업은 다음과 같습니다.

  • 절차, 작업 지침, 템플릿, 체크리스트 등의 업데이트 된 버전을 하드 카피 및 / 또는 전자적 수단으로 배포하는 것과 함께 게시

  • SQA 절차, 작업 지침 및 유사 항목의 준수 및 적용에 관한 교육 및 지침을 신규 및 현재 직원에게 전달

  • 신규 및 수정 된 절차, 개발 도구 및 방법, 기타 구성 요소에 대한 SQA 수탁자 교육

  • 신규 및 수정 된 SQA 절차의 구현 모니터링 및 지원

  • 직원 인증 활동의 후속 조치

  • CAB위원회 참여를 포함하여 예방 및 시정 조치가 필요한 주제 제안

  • CCA위원회 참여를 포함한 구성 관리 활동의 후속 조치

  • 문서화 절차 및 작업 지침 준수에 대한 후속 조치

SQA 내부 감사 및 인증 작업

소프트웨어 조직에서 또는 소프트웨어 조직에 의해 수행되는 SQA 감사 유형은 다음과 같이 분류 할 수 있습니다.

  • 내부 감사

  • SQA 시스템을 평가하기위한 하청 업체 및 공급 업체의 감사

  • 인증 기관이 수행하는 외부 감사

  • 조직을 공급 업체로 수락하기 전에 SQA 시스템을 평가하려는 고객이 수행하는 외부 감사

처음 두 등급의 감사는 SQA 서브 유닛에 의해 시작되고 수행되며 마지막 두 등급은 외부 기관에 의해 수행됩니다.

SQA 부서는 내부 SQA 감사를 위해 다음 작업을 수행합니다.

  • 내부 SQA 감사를위한 연간 프로그램 준비

  • 내부 SQA 감사 수행

  • 감사를받은 팀 및 기타 부서에서 수행 할 수정 및 개선 사항에 대한 후속 조치

  • 개선 권장 사항을 포함하여 감사 결과 상태에 대한주기적인 요약 보고서 작성

SQA 부서는 하청 업체 및 공급 업체의 감사를 위해 다음 작업을 수행합니다.

  • 하청 업체 및 공급 업체의 SQA 감사를위한 연간 프로그램 준비

  • 하도급 업체 및 공급 업체의 SQA 감사 수행

  • 감사를받은 하청 업체 및 공급 업체가 수행 할 수정 및 개선 사항에 대한 후속 조치

  • 내부 및 외부 소스로부터 하청 업체 및 공급 업체의 성과에 대한 데이터 수집

  • 감사 보고서 및 기타 내부 및 외부 소스에서 수집 한 정보를 기반으로 조직의 인증 된 하도급 업체 및 공급 업체의 SQA 시스템을 주기적으로 평가합니다. 평가 보고서에는 다음이 포함됩니다.

    • 협력 업체 및 협력 업체 인증에 관한 권장 사항

    • 인증 기관이 수행하는 외부 감사에는 다음 작업이 포함됩니다.

      • 인증 심사 내용 및 일정 조정

      • 인증 기관에서 지정한 문서 준비

      • 감사를받은 팀의지도 및 인증 감사에 필요한 준비 수행

      • 인증 감사에 참여

      • 필요한 수정 및 개선이 수행되는지 확인

조직의 고객이 수행하는 SQA 감사는 다음 작업을 수반합니다.

  • 감사 내용 및 일정 조정

  • 고객 감사인이 지정한 서류 작성

  • 조직의 고객이 SQA 감사에 필요한 준비를 수행하고 감사를받은 팀을지도합니다.

  • 감사 참여

  • 필요한 수정 및 개선이 수행되었는지 확인

SQA 지원 작업

SQA 지원 서비스 소비자의 대부분은 조직 내에 있습니다. 여기에는 프로젝트 관리자, 팀 리더 및 SQA 수탁자가 포함됩니다. 그들의 임무는 다음과 같습니다-

  • 프로젝트 계획 및 프로젝트 품질 계획 준비

  • 검토 팀 인력 배치

  • 식별 된 소프트웨어 개발 위험을 해결하기위한 조치 선택

  • 일정 지연 및 예산 초과를 해결하기위한 조치 선택

  • SQA 메트릭 및 소프트웨어 비용 구성 요소 선택

  • SQA 정보 시스템 사용

  • SQA 부서에서 축적 한 장애 경험 데이터를 반영하는 개발 방법론 및 도구 선택

SQA 표준 및 절차 작업

SQA 하위 단위는 조직의 절차를 개발 및 유지 관리 할뿐만 아니라 채택 할 SQA 표준을 결정하는 데 긴밀하게 관여합니다. 수반되는 의무를 이행하기 위해 SQA 부서는 다음을 수행해야합니다.

  • 새로운 절차 및 절차 업데이트 개발을위한 연간 프로그램 준비

  • 적절한위원회 및 포럼에 참여하여 새로운 절차 및 절차 업데이트의 개발을 책임집니다.

  • SQA 및 소프트웨어 엔지니어링 표준의 개발 및 변경에 대한 후속 조치 조직과 관련된 추가 절차 및 변경 사항 도입

  • 조직에서 적용한 표준의 채택 또는 삭제를 포함하여 전문 표준의 변경에 대응하여 절차의 업데이트 및 조정을 시작합니다.

SQA 엔지니어링 작업

이 SQA 하위 단위의 즉각적인 목표는 전문적인 발전에 대한 후속 조치, 운영상의 문제 해결 및 전문적인 실패 분석입니다.

따라서 주요 엔지니어링 작업은 다음과 같습니다.

  • 새로운 개발 도구 및 현재 사용되는 개발 도구의 새 버전과 관련하여 품질 및 생산성 측면 테스트

  • 새로운 개발 및 유지 보수 방법 및 방법 개선의 품질 및 생산성 평가

  • 현재 사용되는 소프트웨어 개발 도구 및 방법 적용시 직면 한 어려움에 대한 솔루션 개발

  • 소프트웨어 품질 및 팀 생산성 측정 방법 개발

  • 소프트웨어 개발 실패를 분석하고 제안 된 솔루션을 공식화하는 동안 CAB위원회에 기술 지원 제공

SQA 정보 시스템 작업

SQA 정보 시스템은 SQA 시스템의 기능을 촉진하고 개선하기위한 것입니다. 관련된 작업은 다음과 같습니다-

  • 소프트웨어 개발 및 유지 보수 유닛을위한 SQA 정보 시스템 개발

    • 활동 데이터 수집

    • 예를 들어 정기 보고서, 목록, 예외 보고서 및 쿼리 처리

    • 예를 들어 정기 보고서, 목록, 예외 보고서 및 쿼리 처리

  • 소프트웨어 품질 메트릭 및 소프트웨어 품질 비용의 추정을 포함하여 소프트웨어 개발 및 유지 관리 단위에서 제공하는 SQA 단위의 정보 처리를 용이하게하는 SQA 정보 시스템 개발

  • SQA 정보 시스템 업데이트

  • 조직의 SQA 인터넷 / 인트라넷 사이트 개발 및 유지 관리

SQA 수탁자와 그들의 임무

SQA 수탁자는 주로 소프트웨어 품질 홍보에 관여하는 구성원입니다. 이러한 구성원은 SQA 구성 요소를 성공적으로 구현하는 데 필요한 내부 지원을 제공합니다.

그들의 임무는 조직에 따라 다를 수 있습니다. 따라서 단위 관련 및 / 또는 조직 관련 작업 일 수 있습니다.

단위 관련 작업

  • 소프트웨어 품질 절차 및 작업 지침을 구현하는 동안 어려움을 해결하기 위해 동료 지원

  • 관련 SQA 작업을 수행 할 때 단위 관리자를 지원합니다.

  • 준수를 장려하고 동료의 SQA 절차 및 작업 지침의 구현을 모니터링합니다.

  • SQA 부서에 실질적이고 체계적인 비준수 이벤트보고

  • SQA 부서에 심각한 소프트웨어 품질 오류보고

조직 관련 작업

  • 조직 전체 SQA 절차 및 작업 지침의 변경 및 업데이트 트리거

  • 조직의 개발 및 유지 관리 프로세스 개선 트리거

  • 각 단위에서 관찰 된 반복적 인 오류에 대한 솔루션과 관련하여 CAB에 적용을 시작합니다.

  • 조직 전체의 SQA 교육 요구 사항을 식별하고 SQA 단위에서 수행 할 적절한 교육 또는 교육 프로그램을 제안합니다.

SQA위원회와 그들의 임무

SQA위원회는 영구적이거나 임시적 일 수 있습니다. 작업은 조직마다 상당히 다를 수 있습니다.

  • Permanent committees 일반적으로 SCC (Software Change Control), CA (Corrective Actions), 절차, 방법 개발 도구 및 품질 메트릭을 처리합니다.

  • Ad hoc committees 일반적으로 특정 절차 업데이트, 소프트웨어 오류 분석 및 솔루션 업데이트, 대상 프로세스 또는 제품에 대한 소프트웨어 메트릭 정교화, 특정 문제에 대한 소프트웨어 품질 비용 및 데이터 수집 방법 업데이트와 같은 일반적인 관심 사례를 처리합니다.

영구 SQA위원회는 SQA 조직 프레임 워크의 필수 부분입니다. 그들의 업무와 운영은 일반적으로 조직의 SQA 절차에 정의되어 있습니다.

임시위원회는 소프트웨어 품질 문제를 담당하는 임원, SQA 부서장, SQA 하위 단위, 영구 SQA위원회 또는 시작된 기타 기관이 지명 한 구성원으로 문제별로 단기간에 설립됩니다. 그 형성과 작업에 관심이 있습니다. 이 기관은 또한 특별위원회의 임무를 정의합니다.