소프트웨어로 사용되는 것. 소프트웨어 품질이란 무엇입니까? 품질 관리: 도구 및 기술

매일 업무를 수행하면서 우리는 "소프트웨어 품질"이라는 다소 추상적인 개념을 접하게 되며, 테스터나 프로그래머에게 "품질이란 무엇입니까?"라는 질문을 하면 모든 사람이 자신만의 해석을 갖게 됩니다. 국제 표준의 맥락에서 "소프트웨어 품질"의 정의를 고려해 보겠습니다.

품질 소프트웨어소프트웨어가 필요한 속성 조합을 갖고 있는 정도입니다.

소프트웨어 품질은 명시된 요구와 의도된 요구를 충족시키는 능력과 관련된 소프트웨어 특성의 모음입니다.

소프트웨어 품질 특성

기능성(기능) - 주어진 소프트웨어 사용 조건에서 사용자의 기록되고 예상되는 요구 사항에 해당하는 문제를 해결하는 소프트웨어의 능력에 따라 결정됩니다. 저것들. 이러한 특성은 소프트웨어가 적절하고 정확하게 작동하고, 상호 운용 가능하며, 업계 표준을 충족하고, 무단 액세스로부터 보호된다는 것을 보장합니다.

신뢰할 수 있음신뢰성 - 지정된 기간 또는 지정된 작업 수에 걸쳐 지정된 조건에서 필요한 작업을 수행하는 소프트웨어의 능력입니다. 이 특성의 속성은 전체 시스템의 완전성과 무결성, 장애로부터 독립적이고 올바르게 복구하는 능력 및 내결함성입니다.

사용의 용이성(사용성) – 쉬울 가능성사용자에 대한 소프트웨어의 이해, 학습, 사용 및 매력.

능률(효율성) - 할당된 리소스, 시간 및 기타 지정된 조건에 따라 필요한 수준의 성능을 제공하는 소프트웨어의 능력입니다.

유지관리 용이성(유지 관리 가능성) - 결함 수정, 새로운 요구 사항 구현, 추가 유지 관리를 촉진하고 기존 환경에 적응하기 위해 소프트웨어를 분석, 테스트, 변경할 수 있는 용이성입니다.

이식성(이식성) - 한 환경(소프트웨어/하드웨어)에서 다른 환경으로의 전송이 용이하다는 점에서 소프트웨어의 특징을 나타냅니다.

소프트웨어 품질 모델

~에 이 순간가장 일반적이고 사용되는 다단계 모델소프트웨어 품질, 일련의 표준으로 제시 ISO 9126.최상위 수준에서 강조표시됨 소프트웨어 품질의 6가지 주요 특징, 각각은 후속 평가를 위한 해당 측정항목이 있는 속성 세트로 정의됩니다(

현재 가장 일반적이고 사용되는 것은 ISO 9126 표준 세트에 제시된 다단계 소프트웨어 품질 모델입니다. 최상위 레벨에서는 소프트웨어 품질의 6가지 주요 특성이 식별되며 각 특성은 일련의 속성에 의해 결정됩니다. 후속 평가를 위한 해당 측정항목이 있는 항목

20. 고품질 소프트웨어의 주요 특징.

소프트웨어 및 하드웨어 품질 요소는 일반적으로 고객과의 계약에 설명되지 않은 프로그램에 대한 비기능적 요구 사항이지만 그럼에도 불구하고 프로그램의 품질을 향상시키는 바람직한 요구 사항입니다. 몇 가지 요소는 다음과 같습니다: 명확성(소프트웨어의 목적은 프로그램 자체와 문서에서 명확해야 함), 완전성(프로그램의 모든 필요한 부분이 제시되고 완전히 구현되어야 함), 정확성(모든 기능은 다음에 따라 구현되어야 함) 사양), 간결성(불필요하고 중복된 정보가 없으며, 반복되는 부분은 기능, 모듈, 라이브러리로 변환되어야 함), 문서화, 이식성(이동성), 다른 환경에 프로그램을 적용하는 용이성(다른 아키텍처, 플랫폼)에도 동일하게 적용됩니다. , 운영 체제, 일관성(전체 프로그램과 문서에서 동일한 규칙, 식별자, 형식, 표기법을 사용해야 함), 유지 관리 가능성(새로운 요구 사항(수정 가능성)을 충족하기 위해 프로그램을 변경하는 것이 얼마나 어려운지). 이 요구 사항은 또한 다음을 나타냅니다. 프로그램은 잘 문서화되어야 하며 너무 혼란스럽지 않고 리소스(메모리 및 프로세서) 사용에 대한 성장 여지가 있어야 함), 테스트 가능성(프로그램을 통해 수용 특성을 확인할 수 있는지, 지원되는 성능 측정 기능이 있는지) 및 프로그램의 사용 용이성), 신뢰성(프로그램 작동에 실패 및 실패가 없고 결함 수정, 오류 수정, 재시작 지원 용이성), 효율성(프로그램이 자원을 얼마나 합리적으로 처리하는지), 안전성(지원) 긴급 상황의 경우).

21. 품질: 이동성과 수정 가능성.

소프트웨어 품질은 요구 사항을 충족하는 정도를 나타내는 소프트웨어의 특성입니다.

고품질 소프트웨어에 대한 요구 사항 중 일부는 이동성과 수정 가능성입니다.

소프트웨어 이식성은 소프트웨어가 다양한 하드웨어 플랫폼이나 다양한 운영 체제에서 실행될 수 있는 능력입니다.

수정 가능성,필요한 변경을 쉽게 수행할 수 있는 구조가 있는 경우.

소프트웨어 수정 가능성은 소프트웨어가 쉽게 변경할 수 있는 구조를 갖는 소프트웨어 품질입니다.

22. 품질: 정확성과 신뢰성.

소프트웨어 품질은 요구 사항을 충족하는 정도를 나타내는 소프트웨어의 특성입니다.

고품질 소프트웨어에 대한 요구 사항 중 일부는 정확성과 신뢰성입니다.

소프트웨어 제품에는 다음과 같은 속성이 있습니다. 신뢰할 수 있음,특정 기간 동안 요구되는 기능을 만족스럽게 수행할 것으로 예상되는 경우.

신뢰성을 보장하기 위한 다음과 같은 접근 방식이 있습니다.

오류 방지;

오류 자체 감지;

오류 자체 수정;

오류 허용 오차 보장.

소프트웨어 정확성은 할당된 작업과 요구 사항을 충족하는 소프트웨어의 품질입니다.

최신 소프트웨어 패키지의 복잡성과 크기가 급격히 증가하고 동시에 수행되는 기능의 책임도 증가함에 따라 사용 품질과 안전에 대한 고객과 사용자의 요구 사항이 급격히 증가했습니다. 프로그램과 소프트웨어 시스템의 높은 효율성과 기능 품질을 보장하는 입증된 수단은 업계 선두 기업의 대표자들이 참여하여 개발된 국제 표준입니다.

정보 시스템의 사용과 복잡성이 확대됨에 따라 프로그램이나 데이터의 오류나 품질 부족으로 인해 사용에 따른 긍정적인 효과를 크게 초과하는 피해가 발생할 수 있는 영역이 나타났습니다.

많은 경우 정보 시스템의 필수 기능과 품질 특성에 대한 고객과 개발자의 비공식적 아이디어를 기반으로 정보 시스템을 위한 복잡한 소프트웨어 및 데이터베이스 생성을 위한 계약 및 예비 계획이 서투르게 준비되고 평가됩니다. 중요한 시스템 오류필요한 품질 지표를 결정하고 노동 강도, 소프트웨어 제작 비용 및 기간을 평가할 때 이는 상당히 널리 퍼진 현상입니다. 많은 정보 시스템은 보장된 품질로 필요한 기능 작업을 완벽하게 수행할 수 없으며, 필요한 품질과 운영 신뢰성을 달성하기 위해 오랜 시간 동안 수정해야 하고 때로는 실패하여 추가로 많은 비용과 시간을 소비해야 합니다. 결과적으로 정보 시스템 프로젝트는 품질 특성에 대한 원래 선언된 목적 및 요구 사항과 일치하지 않는 경우가 많으며 개발 일정 및 예산에 맞지 않습니다.

기술 사양 및 구현된 정보 시스템 프로젝트에서 소프트웨어 제품 품질의 개념 및 가치, 설명되는 특성, 측정 방법 및 계약에 반영된 요구 사항, 기술 사양 또는 사양과 비교하는 방법에 대한 정보는 침묵하는 경우가 많습니다. 또는 불충분하게 공식화되었습니다. 또한 일부 특성은 소프트웨어 요구 사항에 누락되어 테스트 중에 임의적으로 고려되거나 누락되는 경우가 많습니다. 소프트웨어 품질 특성의 개념과 요구되는 값을 문서에 명확하게 선언하지 않으면 동일한 특성에 대한 서로 다른 해석으로 인해 고객-사용자와 개발자-공급자 간의 갈등이 발생합니다. 이러한 점에서 소프트웨어와 데이터베이스에 필요한 품질을 보장하는 것은 현대 정보 시스템의 수명 주기에서 전략적 과제가 되었습니다.

지난 몇 년 동안 소프트웨어 및 데이터베이스 수명주기의 프로세스와 제품을 규제하는 많은 국제 표준이 만들어졌습니다. 이러한 표준의 사용은 소프트웨어 품질 보증 시스템의 기초가 될 수 있지만, 이러한 유형의 제품의 기술 및 특성의 기본 특징과 관련하여 표준의 일부 조항을 조정, 적용 또는 제외해야 합니다. 동시에 많은 고객은 현대 국제 표준을 충족할 수 있는 설계 기술, 생산 및 제품 품질을 요구하며, 이를 숙지하고 적용하여 글로벌 시장에서 제품 경쟁력을 확보해야 합니다.

품질 특성의 표준화

소프트웨어 품질을 보장하는 데 가장 중요한 문제 중 하나는 품질 특성의 공식화와 평가 방법입니다. 운영 품질의 적절성, 상호 작용, 개선 및 개발을 위한 소프트웨어 도구의 기술적 기능의 가용성을 결정하려면 품질 특성을 평가하는 분야에서 표준을 사용해야 합니다. 소프트웨어 품질 지표 규제의 기초는 이전에 국제 표준 ISO 9126:1991(GOST R ISO / IEC 9126-93)이었습니다. 정보기술. 소프트웨어 제품 평가. 품질 특성 및 사용 지침." 네 부분으로 구성된 ISO 9126-1--4 표준의 최종 초안은 1991년 부판을 대체하기 위해 마무리되고 공식화되었습니다. 프로젝트는 "정보"라는 일반 제목 아래 다음 부분으로 구성됩니다. 기술 - 품질 특성 및 측정 소프트웨어": "1부. 품질의 특성 및 하위 특성" 2부. 외부 품질 측정" "3부. 내부 품질 측정" "4부. 사용 중인 품질 측정."

러시아에서는 복잡한 소프트웨어 패키지의 수명주기와 품질을 보장하는 분야에서 세계 수준보다 5~10년 뒤처지는 오래된 GOST 표준 그룹이 주로 사용됩니다.

표준의 첫 번째 부분인 ISO 9126-1은 소프트웨어 품질 속성을 표준의 나머지 부분에서 사용되는 6가지 특성으로 분류합니다. 측정의 기본 가능성을 기반으로 모든 특성을 적용할 세 그룹으로 결합할 수 있습니다. 다른 카테고리측정항목:

범주형 또는 설명형(명목형) 측정항목이 가장 적합합니다. 기능성소프트웨어;
복잡한 소프트웨어 패키지의 신뢰성과 효율성을 측정하는 데 정량적 측정 기준을 적용할 수 있습니다.
품질 지표는 소프트웨어의 유용성, 유지 관리성 및 이식성과 가장 일치합니다.

ISO 9126-1 표준의 일부는 품질 하위 특성뿐만 아니라 각 소프트웨어 특성에 대한 나머지 부분의 설명과 함께 정의를 제공합니다.

지난 몇 년 동안 소프트웨어 품질 보증 시스템의 기반이 될 수 있는 소프트웨어 수명주기 및 데이터베이스의 프로세스와 제품을 규제하는 많은 ISO 표준이 만들어졌습니다.

표준의 두 번째 및 세 번째 부분인 ISO 9126-2 및 ISO 9126-3은 복잡한 소프트웨어의 품질 특성에 대한 외부 및 내부 측정 기준을 각각 공식화하는 데 전념합니다. 모든 테이블에는 측정항목의 이름과 목적을 반영하는 통합 제목이 포함되어 있습니다. 적용 방법; 측정 방법, 미터법 척도 유형; 측정량의 유형; 측정 및 비교를 위한 기준 데이터 측정항목이 적용되는 소프트웨어 수명주기 단계(ISO 12207에 따름)도 마찬가지입니다.

표준의 네 번째 부분인 ISO 9126-4는 구매자, 공급업체, 개발자, 유지 관리 담당자, 사용자 및 소프트웨어 품질 관리자를 대상으로 합니다. 이는 소프트웨어 사용 범위(컨텍스트)와 사용자를 위해 선택된 측정항목 그룹에 대해 선택된 지표를 정당화하고 설명합니다.

품질 지표 선택

대부분의 경우 품질 지표를 선택할 때 초기 데이터와 최우선 순위는 해당 소프트웨어 도구의 목적, 기능 및 기능적 적합성입니다. 이러한 특성에 대한 상당히 완전하고 정확한 설명은 대부분의 다른 특성 및 품질 속성 값을 결정하는 기초가 되어야 합니다. 교장과 기술적 능력품질 특성의 속성 값을 측정하는 정확도는 항상 해당 내용에 따라 제한됩니다. 이는 실제 프로젝트의 요구사항 사양에 대한 선례를 분석하는 것은 물론, 상식에 따라 선택할 수 있는 각 속성에 대한 합리적인 값 범위를 정의합니다.

소프트웨어 품질 특성을 설명하기 위해 측정 기준과 척도를 선택하고 설정하는 프로세스는 두 단계로 나눌 수 있습니다.

반영된 초기 데이터 세트의 선택 및 정당화 일반적인 특징소프트웨어 프로젝트와 소비자의 라이프사이클 단계. 각 단계는 소프트웨어 패키지의 특정 품질 특성에 영향을 미칩니다.
소프트웨어 라이프사이클의 특정 단계에서 적격성 테스트 또는 인증 과정에서 사양 요구 사항과의 후속 평가 및 비교를 위해 프로젝트의 특성 및 품질 속성을 측정하기 위한 특정 측정 기준 및 척도의 선택, 설정 및 승인.

첫 번째 단계에서는 ISO 9126에 표준화된 특성, 하위 특성 및 속성의 전체 기본 명명법을 기초로 삼아야 하며, 특정 소프트웨어 프로젝트의 목적과 범위를 고려하여 우선순위에 따라 설명을 사전 주문하는 것이 좋습니다. . 다음으로, 전문성과 직업적 관심을 고려하여 소프트웨어 프로젝트의 품질에 대한 특정 지표가 필요한 소비자를 식별하고 우선순위를 지정하는 것이 필요합니다. 초기 데이터 준비는 특정 소비자에 대한 소프트웨어의 기능적 적합성을 결정하는 다양한 기본 우선 순위 품질 지표를 식별함으로써 완료됩니다.

두 번째 단계에서는 품질 평가 소비자가 수행해야 하는 초기 데이터를 수정한 후 특정 프로젝트와 해당 소비자에 대한 특성 및 하위 특성의 순위를 지정하는 것으로 명칭 및 지표 선택 프로세스가 시작됩니다. 다음으로, 이러한 전문가들은 프로젝트와 분석 결과의 소비자에 대해 선택된 각 지표에 대한 하위 특성과 해당 속성에 대한 측정 기준 및 등급 척도를 설정하고 동의해야 합니다. 질적 특성으로 표현되는 지표의 경우, 다음과 같이 고려해야 하는 조건을 사양 설명에 정의하고 기록하는 것이 바람직합니다. 이 특성소프트웨어로 구현됩니다. 선택한 품질 특성 값과 그 속성은 특정 프로젝트의 사용 가능한 자원을 고려하여 개발자가 사전에 타당성을 확인하고 필요한 경우 조정해야 합니다.

품질 관리

6개 부분으로 구성된 국제 표준 ISO 14598은 수명주기의 다양한 단계에서 완성된 소프트웨어 도구와 해당 구성 요소(소프트웨어 제품)의 품질 특성을 평가하는 방법론 및 표준화에 전념합니다. 프로그램 품질 특성을 평가하기 위해 다음과 같은 일반적인 프로세스 체계가 권장됩니다.

평가를 위한 초기 요구 사항 설정 - 테스트 목표 정의, 소프트웨어 측정 항목 유형 식별, 적절한 지표 식별 및 품질 속성에 필요한 값 식별
품질 지표 선택, 하위 특성 및 속성 지표에 대한 등급 및 우선순위 수준 설정, 검사 및 측정 수행을 위한 기준 선택
소프트웨어 도구의 수명주기에서 특성과 품질 속성을 평가하기 위한 프로세스를 계획하고 설계합니다.
평가를 위한 측정 수행, 결과를 기준 및 요구 사항과 비교, 결과 요약 및 평가.

각 품질 특성에 대해 필수 값, 허용 가능한 값, 불만족스러운 값을 강조하는 측정값과 측정 척도를 만드는 것이 좋습니다. 평가 프로세스의 구현은 ISO 12207 표준의 해당 버전에 따라 특정 소프트웨어 프로젝트의 수명주기 단계와 상호 연관되어야 합니다.

기능성 피트니스- 소프트웨어 도구의 하위 특성을 평가하기 가장 불확실하고 객관적으로 어렵습니다. 소프트웨어 컴플렉스의 적용, 명명법 및 기능 영역은 인간 활동의 매우 다양한 영역을 포괄하므로 다양한 소프트웨어 컴플렉스에서 이러한 하위 특성을 평가하고 비교하기 위해 소수의 속성을 골라내고 통합하는 것이 불가능합니다.

소프트웨어의 정확성 평가계약의 초기 요구 사항, 기술 사양 및 소프트웨어 및 해당 구성 요소의 사양에 따라 구현된 프로그램 집합의 준수 정도를 공식적으로 결정하는 것으로 구성됩니다. 검증을 통해 모듈, 프로그램 텍스트 및 데이터 설명에 이르기까지 소프트웨어 패키지의 전체 구성 요소 세트에 대한 초기 요구 사항을 준수하는지 확인해야 합니다.

상호 운용성 평가다른 소프트웨어 구성 요소와 데이터베이스의 공동 작업 품질을 결정하는 것으로 구성됩니다. 응용 시스템다양한 컴퓨팅 플랫폼의 구성 요소 및 구성 요소를 하나의 플랫폼에서 이동하기에 편리한 스타일로 사용자와 상호 작용할 수 있습니다. 컴퓨팅 시스템비슷한 기능을 가진 다른 사람에게.

소프트웨어 보안 평가여기에는 잠재적인 위협으로부터 소프트웨어를 보호하기 위해 사용 가능한 방법과 수단의 사용 완전성과 이를 통해 달성된 운영 안전을 결정하는 것이 포함됩니다. 정보 시스템. 정보 시스템의 포괄적인 보호를 평가하기 위한 가장 광범위하고 상세한 방법론적, 체계적 작업은 ISO 15408:1999-1-3 표준 "보안 보장 방법 및 수단"의 세 부분에 명시되어 있습니다. 정보 보안 평가 기준 기술."

신뢰성 평가- 사용 중인 하위 특성의 속성에 대한 정량적 측정 기준: 완전성, 결함 허용, 복구 가능성 및 가용성/준비.

메모리 및 성능 요구 사항문제를 해결하는 과정에서 컴퓨터는 초기 데이터의 구성과 양에 따라 크게 달라집니다. 한도를 정확하게 결정하려면 대역폭이 소프트웨어를 사용하는 정보 시스템에서는 프로그램 기능 그룹의 실행 기간과 해당 프로그램이 달성되는 경로의 극단값과 평균값을 측정해야 합니다. 설계 과정에서 컴퓨터 성능을 이전에 평가하지 않은 경우 컴퓨터를 대대적으로 수정하거나 더 빠른 컴퓨터로 교체해야 할 가능성이 높습니다.

유용성 평가소프트웨어 평가는 전문가가 수행하며 소프트웨어의 이해 가능성, 사용 용이성, 학습 가능성 및 매력을 결정하는 것을 포함합니다. 이는 주로 정성적(및 주관적) 평가이지만, 일부 속성은 소프트웨어를 사용할 때의 복잡성과 작업 기간은 물론 이를 연구하는 데 필요한 문서의 양에 따라 정량적으로 평가될 수 있습니다.

유지 관리성소프트웨어 및 해당 구성 요소의 상태, 제안 및 완료된 모든 변경 사항에 대한 문서의 완전성과 신뢰성을 평가할 수 있으므로 언제든지 프로그램 버전의 현재 상태와 개발 내역을 설정할 수 있습니다. 이는 프로그램 및 데이터 문서의 생성, 수정 및 적용을 위한 전략, 표준, 절차, 자원 할당 및 계획을 정의해야 합니다.

이동성 평가- 프로그램의 적응성, 설치 용이성, 호환성 및 교체 가능성에 대한 전문가의 질적 결정이 포인트로 표시됩니다. 소프트웨어 도구의 이러한 특성과 해당 속성의 전체성은 경제 지표(비용, 노동 강도, 특정 프로그램 및 데이터 세트를 다른 플랫폼으로 전송하기 위한 절차 구현 기간)에서 정량적으로 평가할 수 있습니다.

품질 관리 시스템

소프트웨어의 특성을 선택하고 품질을 평가하는 것은 소프트웨어 개발 회사가 생산하는 제품의 품질을 보장하는 분야의 작업 중 하나일 뿐입니다. 완벽한 솔루션소프트웨어 품질을 보장하는 작업에는 하나 이상의 품질 관리 시스템의 개발 및 구현이 포함됩니다. 세계적으로 가장 널리 사용되는 시스템은 소프트웨어 품질 보증을 규제하는 표준(ISO 9000/3)을 포함하여 12개 이상의 문서를 포함하는 ISO 9000 시리즈의 국제 표준을 기반으로 합니다. 이러한 표준은 맞춤형 소프트웨어 개발 회사의 선도적인 전문가를 위한 지침 역할을 해야 합니다.

품질 특성 및 하위 특성 정의(ISO 9126-1)

기능성- 주어진 조건에서 일련의 프로그램을 사용할 때 고객과 사용자의 공식화된 요구를 충족시키는 문제에 대한 솔루션을 제공하는 소프트웨어 도구의 능력.

기능성 피트니스- 고객 또는 잠재적 사용자의 기술 사양 및 사양에 따라 소프트웨어의 목적, 명명법, 기본, 필수 및 충분한 기능을 정의하는 하위 특성 및 해당 속성에 대한 집합 및 설명입니다.

정확성 (정확성)- 사용자에게 정확하거나 수용 가능한 결과와 외부 효과를 제공하는 소프트웨어 도구의 능력.

상호 운용성- 내부 및 외부 환경의 하나 이상의 구성 요소와 상호 작용하는 소프트웨어 및 해당 구성 요소의 속성입니다.

보안- 부정적인 영향으로부터 프로그램과 정보를 보호하는 소프트웨어 구성 요소의 기능.

1년 남짓 전 잡지에서 " 개방형 시스템““소프트웨어 품질 관리 원칙”이라는 제목의 기사가 출판되었습니다. 온라인 버전여기에서 확인할 수 있습니다: http://www.osp.ru/os/2008/06/5344965/. 출판되기 전에 기사의 원본은 편집자들에 의해 대대적으로 수정되었으며 그 결과 크기가 2배로 줄어들었고 제목을 포함한 텍스트도 대폭 수정되었습니다. 이제 나는 저자의 업데이트된 버전을 내 블로그에 게시하기로 결정하고 몇 가지 사항을 추가했습니다. 이 기사는 블로그 형식이 아니라 과학 또는 교육 출판물이므로 용서해 주십시오.

소프트웨어 품질에 대한 주제는 러시아어 문헌과 기사에서 자주 언급되지만 테스트에 대한 긴 연설이나 대화를 넘어서는 경우는 거의 없습니다. 이 기사의 목적은 소프트웨어 품질 문제와 소프트웨어 품질 관리의 기본 원칙에 대한 전체적인 이해를 제공하는 것입니다. 이 기사에서는 소프트웨어 품질의 개념을 정의하고 품질 분석 작업을 단순화하는 접근 방식을 설명하며 다음을 제공합니다. 짧은 리뷰 알려진 방법품질 향상.

I. 소프트웨어 품질의 개념

소프트웨어 제품의 품질 결정
GOST R ISO 9000-2001에 따르면 품질은 "(제품의) 고유 특성이 요구 사항을 충족하는 정도"입니다. 이것은 일반적인 정의입니다. 말 그대로 소프트웨어 개발 분야로 옮겨지면 완전히 정확하게 해석되지 않을 수도 있습니다. 사실 요구사항 개발은 이 용어가 소프트웨어 분야에 대해 이해된다는 의미에서 소프트웨어 개발 프로세스의 필수적인 부분입니다. 소프트웨어 제품(SP)에 대한 요구사항의 품질은 해당 소프트웨어 자체의 품질에 직접적인 영향을 미칩니다. 즉, 소프트웨어 제품에 대한 요구사항이 품질이 좋지 않으면 이러한 요구사항에 따라 개발된 제품 자체도 완벽하게 준수하더라도 품질이 떨어지게 됩니다.

GOST 정의에서 "요구 사항"이라는 단어가 "프로젝트 목표"라는 단어로 대체되면(여기서 프로젝트는 특정 소프트웨어 제품을 개발하거나 기존 제품의 기능을 확장하는 프로세스를 의미함) 모든 것이 제자리에 있게 됩니다. 이 기사에서 소프트웨어 품질은 다음을 의미합니다.

나는 그것을 주목한다 이 정의비용 문제를 다루지 않습니다. 소프트웨어 개발 프로젝트의 목표는 주로 비즈니스 목표와 기존 제한 사항에 따라 결정됩니다.

PP 품질 기준
소프트웨어의 품질은 복잡하고 다면적인 개념입니다. 일반적으로 품질은 다음 변수의 함수입니다.

기능(소프트웨어가 사용자에게 얼마나 유용한지)
품질 사용자 인터페이스(사용 용이성, 학습 용이성)
신뢰성(소프트웨어에 결함이 없음, 오류에 대한 저항성)
생산성, 자원 소비, 환경 요구 사항
품질 정보 지원(선적 서류 비치);
유지 관리성(아키텍처 및 코드 품질, 내부 품질)
+ 아마도 다른 기준일 수도 있습니다.

품질 기준 목록에 대한 다른 옵션은 예를 들어 다음에서 찾을 수 있습니다. 개발 회사는 각 소프트웨어 프로젝트의 각 기준에 대한 품질 표준을 정의합니다(정의해야 합니다). 품질을 평가할 때는 각 기준을 정량화할 수 있어야 합니다.

소프트웨어 품질에 대한 수명주기 활동의 영향
소프트웨어 프로젝트 라이프사이클의 일반적인 활동과 이것이 위에 나열된 품질 기준에 미치는 영향을 살펴보겠습니다. 아래 표에서 * 기호는 다음을 의미합니다. 이 유형활동(행)은 이 품질 기준(열)에 분명히 영향을 미칩니다.

여기서 제가 주목하고 싶은 주요 사항은 다음과 같습니다. 최종 제품의 품질은 초기부터 최신까지 예외 없이 프로젝트의 모든 단계와 활동에 영향을 받습니다. 따라서 프로젝트의 각 단계(예를 들어 테스트 단계뿐만 아니라)에서 얼마나 효과적이고 효율적으로 작업하는지는 개발 중인 제품의 품질이 얼마나 높은지에 따라 달라집니다. 즉, 개발 프로세스의 품질이 개발 중인 제품의 품질을 결정합니다. 제품의 품질은 프로세스의 품질과 불가분의 관계이며, 소프트웨어의 품질을 향상시키기 위해서는 본 소프트웨어의 개발 프로세스의 품질을 향상시키는 것이 필요합니다.

결함의 일반화된 개념
품질 분석을 위해 몇 가지 분리된 기준 대신 특정 일반화된 품질 기준을 도입하고 사용하는 것이 편리할 것입니다. 이 기준은 결함의 일반화된 개념입니다.

따라서 위 기준 중 하나라도 품질 표준에서 벗어나는 경우 이를 결함이라고 부릅니다. 예를 들어 기능이 부족하거나 불필요한 기능이 결함입니다. 불편한 인터페이스는 결함입니다. 유지 관리성에 부정적인 영향을 미치는 잘못 설계되거나 더러운 코드는 결함입니다. 허용할 수 없는 성능은 결함입니다. 잘못된 작업프로그램("버그", 잘못된 동작)은 결함의 특별한 경우입니다. 철자 실수사용자 문서에도 결함이 있습니다.

결함은 예를 들어 다음 매개변수에 따라 분류될 수 있습니다.

결함 유형(발생한 개발 단계 또는 활동에 따라 결정됨)

결함의 심각도(소프트웨어에 결함이 얼마나 중요한지)

결함의 우선순위(수정하는 것이 얼마나 중요한지)

결함의 복잡성(수정하는 데 얼마나 많은 노동력이 필요한지)

이러한 일반화된 역품질 지표를 사용하면 개발 중인 소프트웨어의 품질은 물론 전반적인 개발 프로세스의 품질을 평가하고 분석하는 것이 더 쉬워집니다. 결함 수 또는 결함 중량의 합(일부 매개변수 기준)을 계산하고, 제품의 단위 부피당 결함 밀도를 추정하고, 프로세스의 어느 단계가 가장 문제가 되는지 분석하는 등의 작업을 할 수 있습니다. 이제 품질을 위한 투쟁은 결함에 대한 투쟁에 지나지 않습니다.

II. 소프트웨어 제품 품질 관리

소프트웨어 제품 품질에 대한 전통적인 접근 방식
결함의 일반화된 개념을 도입하면 시간이 지남에 따라 프로젝트의 결함 수 변화를 나타내는 그래프를 그릴 수 있습니다(그림 1). 단순화를 위해 프로젝트 수명주기의 폭포 모델을 고려해 보겠습니다. 철저한 테스트를 강조하는 PCB 품질에 대한 전통적인 접근 방식에서 이 그래프는 다음과 같습니다.

쌀. 1. 품질 관리에 대한 전통적인 접근 방식과 폭포수 수명 주기를 사용하여 시간이 지남에 따라 프로젝트의 결함 수를 변경합니다.

여기서 맨 위의 빨간색 선은 현재 발생한 결함 수를 나타냅니다(결함을 모두 찾을 때까지 총 결함 수를 정확하게 계산할 수 없으므로 이 선은 가상이라는 점을 분명히 해야 합니다). 아래쪽 녹색 선은 현재 발견되어 수정된 결함 수를 나타냅니다. 여기서는 결함이 발견된 후 거의 즉시 수정된다고 가정합니다. 각 순간의 빨간색 선과 녹색 선의 차이는 현재 존재하는 결함 수를 표시합니다. 우리는 프로젝트가 끝날 때 이 차이가 무엇인지에 가장 관심이 있습니다. 크기가 작을수록 제품의 품질이 좋아집니다. 품질 관점에서 이 그림의 수명주기는 결함을 도입하고 수정하는 프로세스 간의 경쟁으로 표현됩니다.

결함 발견 효율성
예를 들어, 시스템 테스트 단계와 같이 결함을 찾고 수정하는 단계 중 하나를 고려해 보겠습니다. 이 단계에서 발견된 특정 수의 결함 D가 발견되는 동시에 D 누락 단계가 끝날 때 특정 수의 결함이 발견되지 않은 상태로 남아 있습니다(그림 2). 총 수단계를 통과한 결함은 발견된 D + 누락된 D와 같습니다.

쌀. 2. 한 단계 동안 결함 수의 변화.

발견된 결함의 총 수에 대한 비율을 백분율로 표시하여 결함 검색 효율성(EDE%)이라고 부르겠습니다.

EPD% = .

결함이 발견되고 수정되는 각 단계에서 성숙한 프로세스와 다른 조건이 동일하다면 이 값은 거의 일정할 것으로 예상됩니다. 이 사실을 통해 현재 프로젝트와 계획된 프로젝트의 품질 수준(검출되지 않은 결함 수로 표시)을 정량화할 수 있습니다.

결함 탐지의 효율성은 개별 단계와 활동은 물론 전체 개발 수명 주기에 대해 고려할 수 있습니다. 동시에 개별 단계의 효율성이 전체 수명주기의 효율성을 결정합니다. 결함 검색의 각 단계는 결함의 특정 부분을 유지하는 일종의 필터로 간주될 수 있으며 전체 수명 주기는 필터 시스템으로 간주될 수 있습니다. 수명주기의 초기 단계에 많은 결함을 통과하는 불량 필터가 있는 경우 이러한 결함이 누적되며 이를 잘 필터링하려면 수명주기가 끝날 때(테스트 단계) 매우 좋은 필터가 필요합니다.

결함 수정 비용
결함을 제거하기 위한 조기 조치를 취하지 않으면 결함은 시간이 지남에 따라 누적되는 경향이 있습니다. 그러나 프로젝트에서 결함이 오래 지속될수록 이를 수정하는 데 더 많은 비용이 들고(즉, 노동 집약적) 종속성이 기하급수적으로 커지는 경우가 많다는 것도 잘 알려진 사실입니다. 폭포 수명주기 모델의 경우 이러한 의존성은 다음 그래프(그림 3)에 잘 설명되어 있습니다.

쌀. 3. 시간이 지남에 따라 결함 수정 비용이 변경됩니다(폭포 수명주기).

반복적 수명주기 모델의 경우 그림은 유사하며(그림 4) 레이블만 변경되고 Y축의 크기는 변경됩니다. 다른 유형결함(예: 요구 사항 및 설계 결함의 경우 코딩 결함보다 규모가 더 커집니다).

쌀. 4. 시간이 지남에 따라 결함 수정 비용이 변경됩니다(반복 수명 주기).

품질 관리에 대한 통합적 접근 방식
따라서 테스트에만 의존하는 것은 매우 철저하더라도 품질 문제를 해결할 수 없다는 것이 밝혀졌습니다. 테스트 단계까지 결함을 해결하기 위한 조치를 취하지 않으면 테스트가 시작될 때까지 프로젝트에 너무 많은 결함이 축적되어 이를 제거하는 것이 불가능한 작업이 될 수 있습니다.

따라서 테스트 단계의 마지막 단계뿐만 아니라 초기 단계부터 시작하여 프로젝트의 전체 수명 주기 동안 지속적으로 결함을 찾고 수정해야 합니다. 대략적으로 말하자면, 테스트 단계에서 프로젝트가 끝나면 결함을 찾기에는 너무 늦습니다. 결함이 많이 쌓이면 아무리 많은 테스트를 해도 품질이 낮은 제품을 고품질 제품으로 바꾸는 데 도움이 되지 않습니다.

동시에 적용할 수 있고 적용해야 하는 두 번째 접근 방식은 결함을 방지하는 것입니다.

품질 관리에 통합 접근 방식을 적용할 때 결함 수 대 시간 그래프가 어떻게 변하는지 고려해 보겠습니다(그림 5). 전체 프로젝트 수명 주기에 걸쳐 결함 탐지 방법을 사용하면 발견된 결함 곡선이 위쪽으로 높아집니다. 그리고 결함 방지 방법을 사용하면 도입된 결함 곡선이 아래쪽으로 낮아집니다. 따라서 수명주기 전반에 걸쳐 발견되지 않은 결함 수가 줄어들고, 결과적으로 프로젝트가 끝날 때 발견되지 않은 결함 수가 줄어듭니다.

쌀. 5. 시간이 지남에 따라 프로젝트의 결함 수 변화 통합 된 접근 방식품질경영에.

결함 검색 방법
결함 검출 방법은 다음 기준에 따라 분류될 수 있습니다.

정적 및 동적;
수동 및 자동화.

따라서 네 가지 범주의 방법을 구분할 수 있습니다.

수동 아티팩트 분석:
자동 정적 검사:
자동화된 테스트:
수동 테스트:

나열된 각 방법에는 장단점이 있습니다. 일부 유형의 결함은 한 가지 방법으로 더 잘 포착되고 일부는 다른 방법으로 더 잘 포착됩니다. 따라서 결함을 찾는 효과적인 전략은 여러 이질적인 방법을 조합하여 사용하는 것입니다. 각 검색 방법은 특정 조건에서 얼마나 잘 구현되고 적용되는지에 따라 백분율로 표시되는 고유한 효율성 수준을 갖습니다. S. McConnell의 저서 "Perfect Code"에서 대략적인 결함 감지 효율성 표를 찾을 수 있습니다. 다양한 방법(아래 표의 사본을 참조하세요) 이러한 데이터에 따르면 테스트의 결함 발견 효율성은 상대적으로 낮으며(25%-40%), 이를 높이려면 테스트 프로세스 비용을 몇 배로 늘려야 합니다(효율성 1000명이 넘는 테스터를 대상으로 한 베타 테스트는 약 75%입니다.

검색방법	EPD%	검색방법	EPD%
비공식 디자인 검토	35%	테스트 새로운 기능(요소)	30%
형식적 설계(기술적) 검사	55%	통합 테스트	35%
비공식 코드 검토	25%	회귀 테스트	25%
공식 코드 검토	60%	시스템 테스트	40%
모델링 및 프로토타이핑	65%	베타 테스트(<10 тестеров)	35%
단위 테스트	30%	베타 테스트(>1000명의 테스터)	75%

결함 예방 방법
결함이 전혀 없는 소프트웨어를 개발하는 방법을 배웠다면 결함을 찾는 데 위의 방법이 필요하지 않을 것입니다. 이는 달성될 가능성이 낮지만 발생하는 결함 수를 줄이려고 노력할 가치가 있습니다. 결함을 예방하는 방법에는 다음이 포함됩니다.

프로토타입 제작은 시스템 특성을 테스트하고 개발 중에 심각한 결함(및 재작업)을 초래할 수 있는 잘못된 가정과 솔루션을 식별하기 위해 개발 중인 시스템의 저비용 모델을 생성하고 테스트하는 것입니다.

소프트웨어 개발 중에 생산된 모든 유형의 제품(요구 사항, 아키텍처, 코드, 다양한 문서 등)에 대한 표준을 사용합니다. 엄격하고 보편적으로 인정되는 표준은 이러한 제품을 사용할 때 사람들 사이에서 발생할 수 있는 오해(제품을 읽는 사람이 제품 작성자가 염두에 둔 내용을 읽지 못한 경우)를 최소화하고 결과적으로 제품과 관련된 결함의 발생을 방지하는 데 도움이 됩니다.

구성 요소(또는 모듈식) 접근 방식을 적용합니다. 구축 시 구성 요소 접근 방식을 적절하게 사용 소프트웨어 시스템복잡성이 줄어들고 결과적으로 결함이 발생할 수 있는 공간이 좁아집니다.

기성품으로 입증된 솔루션 및 구성요소(자체 또는 구매) 사용 고품질우리는 확신합니다. 자체적으로 새로운 솔루션을 개발해야 하는 횟수가 줄어들수록 우리가 저지르는 실수도 줄어듭니다.

코드 리팩토링 - 코드를 적절한 형식으로 만드는 것은 좋은 방법이해하기 어렵고 잘못 설계된 코드 섹션을 수정할 때 나타날 가능성이 매우 높은 향후 유지 관리 결함을 방지합니다.

테스트 케이스의 예비 개발(코딩 단계 전)을 통해 개발 중인 시스템에 대한 요구 사항을 더 잘 이해하고 더 효과적으로 설계할 수 있습니다. 특별한 경우이 접근 방식은 테스트 기반 개발(Test-Driven Development)이며, 단위 테스트는 코딩 후가 아닌 코딩 전에 개발됩니다.

가장 심각한 결함의 원인을 정기적으로 분석하고 이러한 원인을 제거하는 방법을 찾습니다. 이는 정기적인 개발 팀 회의에서 발생할 수도 있고 시스템 테스트 또는 구현 후 단계에서 발견된 모든 주요 결함에 대해 수행될 수도 있습니다. 그러한 분석의 결과는 결함의 원인을 제거하거나 최소한 그러한 결함의 조기 발견을 촉진하기 위한 개발 프로세스의 수정이어야 합니다.

당신의 아이디어는 무엇입니까?

여기서 인적 요소도 언급할 가치가 있습니다. 어떤 방법도 개발자와 관리자의 전문성과 경험을 대체할 수 없습니다. 실제 경험이 풍부한 전문가는 원칙적으로 실수가 적고, 이들의 경험을 활용하는 것이 고품질 개발을 위한 좋은 기반을 제공합니다. 팀이 주로 젊고 경험이 없는 개발자로 구성되어 있다면 이들을 위한 특별 교육을 실시할 가능성을 고려해야 합니다.

반복적인 라이프사이클에서의 품질 관리
예를 들어, 5개의 반복으로 구성된 반복적인 수명 주기를 생각해 보십시오. 각 반복은 작지만 완전한 폭포수 수명 주기로 간주될 수 있습니다(그림 6).

쌀. 6. 반복 수명주기 동안 시간이 지남에 따라 프로젝트의 결함 수가 변경됩니다.

각 워터폴 루프의 결함 발견 효율이 50%이고 각 반복마다 동일한 수의 결함이 발생한다고 가정해 보겠습니다. EPD% 공식을 사용하여 계산해 보겠습니다. 이는 5번의 연속 반복으로 구성된 반복 주기에서 결함을 검색하는 효율성과 동일합니다. 첫 번째 반복 이후 이 효율성은 50%가 됩니다. 2차 이후 – 62.5%; 3번째 이후 – 70.8%; 4회 이후 – 76.6%; 5회 이후에는 5회 반복 모두에서 결함 검색 효율성이 80.6%가 됩니다.

이 예는 이상화되었으며 실제 생활에서는 여러 반복에서 결함을 찾는 효율성이 다를 가능성이 높습니다. 이는 서로 다른 반복에서 활동이 이질성 때문입니다. 그러나 어쨌든 단순한 폭포수 수명 주기 전에는 품질 면에서 분명한 진전이 있습니다. 이 효과는 매우 간단하게 설명할 수 있습니다. 각 후속 반복에서 현재 반복의 결함뿐만 아니라 이전 반복의 나머지 결함도 발견합니다. 결과적으로 결함 감지의 전반적인 효율성이 향상됩니다.

따라서 결함을 조기에 발견하기 위한 추가 방법(예: 검사, 검토 등)을 도입하는 것뿐만 아니라 폭포수에서 반복적인 소프트웨어 개발 수명 주기로 전환함으로써 품질 개선을 달성할 수 있는 것으로 나타났습니다. 게다가 이론적으로는 반복 횟수가 늘어날수록 더 나은 품질. 초기 반복 테스트는 수명주기 초기에 결함을 찾는 것으로 생각할 수 있습니다.

소프트웨어 품질 비용
많이 사용하는 것 같긴 하지만 다양한 방법소프트웨어 품질이 향상되면 소프트웨어 개발 비용이 증가합니다. 이는 단기적으로(사용 과정이 안정화될 때까지) 또는 방법이 잘못 사용된 경우에 해당될 수 있습니다. 장기적으로 품질 개선 방법을 통합적으로 사용하면 개발 비용이 증가하지 않을 뿐만 아니라 비용도 절감할 수 있습니다. 왜 이런 일이 발생하는지 봅시다.

첫째, 위에서 언급한 것처럼 결함을 조기에 발견할수록 수리 비용이 저렴해집니다. 따라서 조기 결함 탐지 방법을 효과적으로 사용하면 프로젝트 비용을 절감하는 데 도움이 됩니다.

둘째, 위에서 논의한 결함 검색 방법은 효율성 외에도 결함을 찾는 평균 속도도 특징입니다. 예를 들어 통계 데이터에 따르면 테스트 방법에 대한 이 지표는 결함을 조기에 감지하는 방법보다 몇 배 더 나쁩니다. 즉, 초기 단계에서 결함을 찾는 데 시간을 투자함으로써 향후 테스트에 더 많은 시간을 절약할 수 있습니다.

S. McConnell은 "시스템의 품질을 높이면 개발 비용이 절감된다"고 주장합니다. "(후기 단계에서) 결함을 제거하는 것은 실제로 소프트웨어 개발에서 가장 비용이 많이 들고 시간이 많이 걸리는 단계입니다."

품질경영 프로세스
품질관리가 부족하다 사용하기 쉬운높이기 위한 다양한 방법. 품질 지향 소프트웨어 개발 프로세스의 필수적인 부분이 될 의식적이고 체계적인 적용이 필요합니다.

전체 개발 프로세스를 구성하는 개별 하위 프로세스의 품질 관리는 물론 품질 지표를 통해 개발 중인 소프트웨어의 품질을 지속적으로 모니터링해야 합니다.

어제 잘 먹힌 방법이 오늘은 시간낭비일 수도 있다. 각 프로젝트에는 서로 다른 품질 개선 방법이 필요한 고유한 특성이 있을 수 있습니다. 방법의 효과를 지속적으로 모니터링하지 않으면 시간이 지남에 따라 성능이 크게 저하될 수 있습니다.

품질 관리는 또한 도입된 결함 수를 줄이고 결함 탐지 방법의 효율성을 높이기 위해 개발 프로세스를 개선할 수 있는 방법을 끊임없이 모색하는 것입니다.

결론
위의 내용을 모두 요약해 보겠습니다. 소프트웨어의 품질은 주로 이 소프트웨어를 개발하는 과정에 따라 결정됩니다. 성숙하고 안정적이며 품질 지향적인 프로세스만이 소프트웨어 제품예측 가능하고 통제된 수준의 품질을 제공합니다. 이러한 프로세스는 소프트웨어 품질 관리의 기본 원칙을 기반으로 해야 합니다.

초기 단계부터 시작하여 전체 개발 수명주기 동안 지속적인 결함 검색 및 수정;

결함 예방 방법의 체계적인 적용;

개발된 소프트웨어 및 개발 프로세스의 지속적인 품질 관리;

품질을 향상시키기 위해 개발 프로세스를 지속적으로 개선합니다.

문학

1. Humphrey, Watts S., 소프트웨어 엔지니어링 분야, ISBN 0-201-54610-8. Addison-Wesley의 저작권 1995.
2. McConnell S., 완벽한 코드. 마스터 클래스 / 번역. 영어로부터 –M.: 출판 및 무역 회사 "Russian Edition"; 상트페테르부르크: 피터, 2005.
3. Humphrey, Watts S., 팀 소프트웨어 프로세스 소개, ISBN 0-201-47719-X. Addison Wesley Longman, Inc.의 저작권 2005
4. Humphrey, Watts S., PSP: 소프트웨어 엔지니어를 위한 자기 개선 프로세스, ISBN 0-321-30549-3. 저작권 2005 Pearson Education, Inc.
5. Ambler S., Agile 기술: 익스트림 프로그래밍 및 통합 개발 프로세스. 프로그래머의 도서관. 당. 영어로부터 –SPb.: 피터, 2005.
6. Kroll P., Kratchen F., Rational Unified Process - 쉽습니다. RUP에 대한 실무자 가이드. 당. 영어로부터 – M.: KUDITS-OBRAZ, 2004.
7. R. J. Torres, 사용자 인터페이스 디자인 및 개발에 대한 실용 가이드. 영어 번역 –M.: 윌리엄스 출판사, 2002.
8. Bobrovsky S., 소프트웨어 엔지니어링. 러시아 프로그래머를 위한 국방부 기술. –SPb.: 피터, 2003.
9. Hunt E., Thomas D., 실용적인 프로그래머. 견습생에서 마스터가 되는 길. 당. 영어로부터 –M.: 출판사 “Lori”, 2004.
10. Fowler M., 리팩토링: 기존 코드 개선. 당. 영어로부터 – 상트페테르부르크: Symbol-Plus, 2005.
11. Beck K., 익스트림 프로그래밍. 당. 영어로부터 –SPb.: 피터, 2002.
12. Beck K., 익스트림 프로그래밍: 테스트 주도 개발. 프로그래머의 도서관. 당. 영어로부터 –SPb.: 피터, 2003.
13. GOST R ISO 9000-2001, http://bib-gost.narod.ru/kazestvo/_gost_r_iso_9000_2001.zip
14. Royce Walker, 소프트웨어 개발 프로세스 관리. 당. 영어로부터 –M.: 출판사 “Lori”, 2007.
15. Tian, Jeff, 소프트웨어 품질 엔지니어링, ISBN 0-471-71345-7. IEEE 컴퓨터 협회의 저작권 2005.