소프트웨어 품질 측정

편집자 주: 우리가 만드는 소프트웨어의 품질을 측정 가능하게 만들기 위해 소프트웨어 개발 아웃소싱에 대한 우리 팀 소프트웨어 품질을 측정, 개선 및 제어하는 ​​데 도움이 되는 일련의 소프트웨어 메트릭을 설정합니다. ScienceSoft의 제 동료들은 31년의 경험을 귀사의 소프트웨어 프로젝트에 기꺼이 활용할 것입니다.

품질 관리의 필수적인 부분인 소프트웨어 메트릭은 핵심 수치 시스템을 정의하고 따라서 개발 프로세스를 보다 효율적으로 계획 및 제어하고 투명성을 생성하는 역할을 합니다. ScienceSoft 전문가는 두 가지 메트릭 그룹을 구분합니다.

• 제품 지향 소프트웨어 메트릭, 개발 프로세스의 모든 단계에서 소프트웨어 품질을 측정하고 확인하는 데 사용됩니다.
• 프로젝트 지향 소프트웨어 메트릭, 이는 개발팀, UX디자이너, QA, 지원팀 등 관련된 모든 팀의 전체 개발 프로세스와 생산성을 평가하고 효율적인 프로젝트 제어를 가능하게 하는 역할을 합니다.

이 블로그 게시물에서는 아웃소싱 개발 프로젝트를 사용하여 소프트웨어 품질을 측정하고 평가할 때 일반적으로 사용하는 첫 번째 소프트웨어 메트릭 세트에 중점을 둘 것입니다. 다음 메트릭 그룹에 대한 정보는 블로그 게시물의 두 번째 부분에서 찾을 수 있습니다.

이러한 소프트웨어 메트릭은 자동화된 코드 검토를 통해 소프트웨어 상태를 평가하고 코드 품질이 얼마나 높은지에 대한 질문에 답하는 데 적합합니다. 메트릭은 또한 기능 확장의 어려움과 소프트웨어의 유지 관리 및 지원 문제를 피하기 위해 코드가 얼마나 복잡한지 이해하는 데 도움이 됩니다.

우리 프로젝트에서는 다음과 같은 소프트웨어 메트릭을 사용하여 코드 품질을 측정합니다.

• 유지보수성 지수(MI)
• 순환 복잡성
• 상속 트리의 깊이
• 클래스 간 결합
• 코드 줄 수

같은 도구 마이크로소프트 비주얼 스튜디오 이러한 성능 지표를 자동으로 계산할 수 있습니다.

이러한 유형의 소프트웨어 메트릭은 소프트웨어의 품질이 배송하기에 충분히 높은지 여부를 추정하는 데 사용됩니다. 우리는 이러한 소프트웨어 지표를 사용하여 소프트웨어의 상태 판단할 뿐만 아니라 생산성 결과적으로 관련 조치를 통해 소프트웨어 품질과 팀의 생산성을 모두 향상시킵니다.

소프트웨어로서의 테스트 커버리지미터법 품질 보증을 위해 테스트 사례에서 다루는 소프트웨어 요구 사항의 백분율을 나타냅니다. 더 많은 기능적 및 비기능적 요구사항이 적합한 테스트 케이스에 의해 다루어질수록 더 많은 오류를 식별할 수 있습니다. 이를 통해 요구 사항에 따라 고품질 소프트웨어를 제공할 수 있습니다.

• 동안 결함 수락 테스트 발견되다

승인 테스트 중에 결함이 발견되면 소프트웨어가 사용자 관점에서 특정 요구 사항을 충족하지 않는다는 의미입니다. 승인 테스트 중에 발견된 버그의 수가 이전에 발견된 버그의 수만큼 많은 경우 테스트 및 개발 프로세스를 모두 최적화해야 함을 나타낼 수 있습니다.

• 출시 후 발견된 결함

버그가 초기에 발견되지 않고 릴리스 이후에만 식별되면 종종 비용이 많이 들고 후기 단계에서 버그를 수정하기 위해 구현하기가 쉽지 않기 때문에 이로 인해 수익 손실이 발생할 수 있습니다. 또한 사용자가 소프트웨어로 많은 작업을 할 수 있고 원하지 않기 때문에 사용자 경험에 부정적인 영향을 미칩니다. 따라서 소프트웨어 버전을 출시하기 전에 버그의 90% 이상이 수정되었는지 확인해야 합니다.

사용자가 소프트웨어에 액세스할 수 없고 사용하는 동안 특정 문제에 직면하면 해당 소프트웨어 사용을 중단할 가능성이 높습니다. 소프트웨어의 가용성이 얼마나 높은지 측정하기 위해 여러 지표를 사용합니다. 이러한 소프트웨어 메트릭은 또한 팀이 얼마나 효율적으로 문제를 해결하고 성능을 개선했는지 보여줍니다. 주요 가용성 메트릭에는 다음이 포함됩니다.

• 고장 사이의 평균 시간, MTBF)

ScienceSoft의 제 동료들은 MTBF를 계산하여 예상되는 정전을 예측하고 따라서 지원 팀의 작업을 수행합니다. 평가하다. 이 맥락에서 값이 낮다는 것은 소프트웨어 성능이 제대로 모니터링되지 않았거나 충분히 모니터링되지 않았거나 지원 팀이 과거에 복구 작업을 제대로 수행하지 못했음을 나타낼 수 있습니다.

• 평균 복구/수리 시간(평균 복구/수리 시간, MTTR)

MTTR은 팀이 문제를 해결하고 소프트웨어를 백업하고 중단 후 실행하는 데 걸리는 평균 시간입니다. 그만큼 회복 시간 문제 식별 및 분석으로 시작하여 수리를 진행합니다. 순수한 수리 시간 기능 테스트 및 복원을 위한 수리에만 필요한 기간만 포함됩니다. 아웃소싱 소프트웨어 개발 프로젝트를 처리하고 서비스 수준 계약(SLA)의 일부로 가용성을 복원하는 것이 의무로 간주될 때 두 용어를 구별하는 것이 특히 중요합니다. 결국 양 당사자는 무엇이 측정되는지에 대해 정확히 동의해야 합니다.

이 두 매개변수를 사용하면 다음 공식을 사용하여 가용성(V)을 계산할 수 있습니다.

V = MTBF/ MTBF+ MTTR

• 단일 실패 수

이 소프트웨어 메트릭은 시간 단위(주 또는 월)당 소프트웨어가 실패한 빈도를 나타냅니다. 메트릭은 원인을 분석하는 데 도움이 되며 가용성 수준을 높일 수 있습니다. 그러나 예정된 유지 관리를 위해 다운타임이 필요할 수 있으므로 100% 가용성을 목표로 해야 한다는 의미는 아닙니다. 그러나 그렇게 함으로써 최소한의 중단 시간으로 최대 가동 시간을 허용해야 합니다.

• 페이지 로드 시간(웹 앱만 해당)

로딩 시간은 페이지 콘텐츠가 완전히 로드되는 속도를 나타냅니다. 이 소프트웨어 메트릭은 사용자 경험에 긍정적인 영향을 미치도록 지속적으로 제어되고 최적화되어야 합니다. 로딩 시간은 2~3초 이상 걸리지 않습니다. 그렇지 않으면 방문자가 웹 앱을 떠날 수 있습니다. 또한 느린 페이지는 검색 결과에서 더 낮게 표시될 수 있습니다.

이러한 유형의 소프트웨어 메트릭은 취약성 관리 활동을 계획 및 실행하고 조치의 효과를 결정하며 결과적으로 안전한 소프트웨어를 개발하기 위한 지표로 사용됩니다. 이 경우 일반적인 추세가 위인지 아래인지가 더 중요합니다.

• 정기적인 펜 테스트를 통해 발견된 취약점 수

이 소프트웨어 지표는 소프트웨어가 보안 위험에 노출된 정도를 나타냅니다. 이상적으로는 메트릭이 낮아져 솔루션이 보안과 관련하여 더욱 안전해지고 있음을 나타냅니다. 메트릭이 증가하면 소프트웨어 업데이트가 너무 빨리 릴리스되고 있음을 의미할 수 있습니다.

• 이미 식별된 수 취약점해결되지 않은 것

아직 수정되지 않은 버그가 많은 경우 패치된 취약점의 수는 소프트웨어의 보안 수준을 완벽하게 보여주지 않습니다. 핵심 수치는 이러한 격차를 염두에 두고 보안을 개선하기 위해 적시에 필요한 조치를 계획하는 데 도움이 됩니다.

• 보안 사고의 수 및 심각도

이 소프트웨어 지표를 사용하여 사고가 소프트웨어 안정성 측면에서 미칠 수 있는 영향을 기반으로 특정 순서로 대응하기 위해 심각도별로 사고의 우선 순위를 지정합니다.

설문 조사 및 설문지의 도움으로 사용자 만족도를 측정할 수 있습니다. 예를 들어 설문조사에서 다음 값을 사용하여 사용자 관점에서 소프트웨어를 평가할 수 있습니다.

• 소프트웨어가 기능에 대한 사용자 기대치를 충족합니까?
• 사용자 인터페이스의 직관적인 사용성을 제공합니다.
• 사용자가 소프트웨어 성능의 안정성을 평가하는 방법.

소프트웨어 메트릭 요약은 표를 참조하십시오. 이 KPI 시스템은 웹 앱 개발을 위한 예제 프로젝트를 사용하여 월 단위로 추적할 수 있는 대상 값을 보여줍니다.

프로젝트에 소프트웨어 메트릭을 구현하고 싶습니까?

소프트웨어 품질은 코드 및 테스트 품질, 가용성, 보안 및 사용자 만족도를 측정하고 평가하여 확인할 수 있습니다. 서로 다른 소프트웨어 메트릭을 사용하면 적시에 목표 편차를 발견하고 소프트웨어 품질뿐만 아니라 팀과 각 개별 프로젝트 참가자의 생산성을 향상시키기 위한 정성적 조치를 취할 수 있는 기회를 제공합니다. 또한 검토를 통해 소프트웨어 품질을 측정하기 위해 소프트웨어 프로젝트에 소프트웨어 메트릭을 구현하려는 경우 확인하다 시의적절한 대응책을 취하십시오. 당사의 소프트웨어 개발 팀은 귀하의 아웃소싱 프로젝트가 이를 정의하고 사용할 수 있도록 적절한 소프트웨어 지표를 제공할 수 있습니다!