Sqa(소프트웨어 테스트) 5가지 규칙

소프트웨어 품질 보증(SQA)은 제안된 표준, 절차, 관행 및 방법이 모든 프로젝트에서 올바르게 채택될 수 있도록 관리를 보장하기 위한 계획적이고 체계적인 접근 방식을 확립하는 것입니다.

소프트웨어 품질 보증의 목적은 소프트웨어 프로세스를 관리자에게 공개하는 것입니다. 소프트웨어 제품 및 활동에 대한 검토 및 감사를 통해 소프트웨어가 표준을 준수하는지 확인합니다. 소프트웨어 품질 보증 그룹은 프로젝트 초기에 함께 협력하여 계획, 표준 및 프로세스를 수립합니다. 이를 통해 소프트웨어 프로젝트가 해당 기관의 정책 요구 사항을 충족할 수 있습니다.

1. 기본 목표

목표 1: 소프트웨어 품질 보증 작업은 계획된 방식으로 수행됩니다.

목표 2: 소프트웨어 프로젝트 제품과 작업이 적절한 표준, 절차 및 요구 사항을 따르는지 객관적으로 확인합니다.

목표 3: 관련 그룹과 개인에게 소프트웨어 품질 보증 노력과 결과를 알립니다.

목표 4: 고위 경영진은 프로젝트 내에서 해결될 수 없는 부적합 문제에 노출됩니다.

2. QA의 유래

IBM, CA, PeopleSoft 등 많은 외국 대기업에서는 QA 책임이 테스트(주로 시스템 테스트)인 것으로 알고 있습니다. 사실 초기에는 거의 모든 회사가 이랬습니다. 나중에 효과적인 프로젝트 계획 및 프로젝트 관리가 부족하여 시스템 테스트를 위한 시간이 거의 남지 않았습니다. (참고: 이전에 작업한 프로젝트에서 프로젝트 관리자는 시스템 테스트가 하루만 지속된다고 분명히 말했습니다. , 협상 없음). 또한 요구사항은 너무 빨리 변경됩니다. 완전한 요구사항 문서가 없으면 테스터는 자신의 상상에 따라서만 테스트할 수 있습니다. 이로 인해 테스트를 통한 제품의 품질 확보가 어려우며, 예방조치의 QA 기능이 등장하게 됩니다.

사전예방은 사실 TQM의 개념에 바탕을 두고 있으며, "결함을 빨리 발견할수록 빨리 수정할수록 더 많은 결함을 발견할 수 있다"는 소프트웨어 공학의 원리와도 일맥상통한다. 경제적이에요." 이러한 사상의 기원은 Qu Tu의 Xin 이주, Bian Que의 의료 기술에 대한 논의 등과 같은 고대 중국의 암시로 거슬러 올라갈 수도 있습니다. 특히 나는 우연히 해외 기사에서 편작의 의료 기술에 대한 언급을 보았습니다(나중에 린 루이의 기사에서도 보았습니다). 나는 우리 중국인이 조상의 사상과 문화 유산을 거의 잃어버렸다고 한탄했습니다.

3. QA 현황

현재 CMM을 도입하는 기업이 늘어나고 있습니다. CMM 모델에는 QA 역할 설정이 필요합니다. 여기서 QA는 프로세스 경찰과 유사하며 개발 및 관리 활동이 설정된 프로세스 전략, 표준 및 절차와 일치하는지 확인하고 작업 제품이 템플릿에 지정된 내용 및 형식을 따르는지 확인하는 것이 주요 책임입니다. 이러한 회사에서 QA는 일반적으로 평가의 객관성을 보장하기 위해 프로젝트 팀으로부터 독립되어야 합니다. 국내 관점에서 볼 때 대부분의 QA 직원은 기술적인 배경이 없으며 그들이 발견하는 대부분의 편차는 설득력 있는 배경이 없으며 리더도 이를 지원하지 않습니다. 그렇게 하세요.

신뢰와 지원 부족은 단지 하나의 측면일 뿐이며, QA 작업 자체가 매우 어렵습니다. QA에는 소프트웨어 엔지니어링, 소프트웨어 개발, 산업 배경, 수리 통계, 프로젝트 관리, 품질 관리 등에 대한 지식이 필요합니다.

우리는 개선이 일정 수준에 도달한 후에는 돌파하기 어려운 문제에 자주 직면합니다. 우리는 에너지가 충분하지만 에너지가 충분하지 않다고 느끼고 우울해지기 시작합니다. 나중에 배움과 훈련, 소통을 통해 생각과 실력이 승화되었고, 통 속의 가장 짧은 조각을 발견하게 되었고, 그러다가 다시 향상되기 시작했고, 그러다가 다시 유리천장을 만나게 되었는데... 우울한주기에.

모든 지식을 마스터하고 모든 유리천장을 뚫을 수 있다면 QA는 순조롭게 항해할 수 있을까요? 대답은 '아니요'입니다. QA 역할 정의 자체에는 상당한 제한이 있습니다. QA는 프로세스 경찰의 역할을 맡는다. 의미가 있든 없든 프로세스의 실행을 폭압적으로 강요하는데, 이는 프로젝트 팀 내에서 쉽게 적대적인 관계를 조성하고 배제로 이어질 수 있다. 팀 정신.

이처럼 QA 작업에는 대인관계 능력도 필요합니다. 앞서 제가 "품질 균형"과 "QA가 프로젝트 팀으로부터 독립되어야 하는가?"에 대해 쓴 것처럼요. 》그렇습니다. 이 관계를 예술적으로 처리해 보세요.

4. QA의 미래

독립적인 QA 검토 메커니즘은 어느 정도 폭포 모델의 산물입니다. 현대 소프트웨어 개발 기술의 발전과 나선형 모델 및 반복 모델의 등장으로 QA 메커니즘은 조용히 변화하고 있습니다. 이러한 변화는 프로세스 전반에 걸쳐 독립적인 풀타임 QA에서 파트타임 QA로의 진화입니다. CMMI 모델에서는 이런 종류의 파트타임 QA도 허용됩니다. 왜 이런 변화가 일어났는가? XP, RUP 또는 기타 고급 방법론이든 관계없이 아키텍처가 먼저 생성된 다음 완료될 때까지 점진적으로 개발됩니다. 이 모델에서는 각 반복 주기에서 요구 사항과 설계 결함을 최대한 빨리 발견하고 수정하며, 아키텍처와 프로세스에 품질이 내장되어 있으며, 프로젝트의 비용과 일정도 보장됩니다.

그때쯤이면 독립적인 QA는 존재하지 않게 될까요? 성숙도가 낮은 일부 회사에서는 주로 프로세스 실행의 효율성과 평가의 객관성을 보장하기 위해 여전히 이를 필요로 합니다.

5. SQA의 이론적 탐구

1. 프로세스 이해

우리 모두는 프로젝트의 주요 내용이 비용, 일정, 품질이라는 것을 알고 있습니다. 좋은 프로젝트 관리는 세 가지 요소를 통합하고, 세 가지 측면의 목표의 균형을 맞추고, 최종적으로 목표에 따라 작업을 완료하는 것입니다. 프로젝트의 이 세 가지 측면은 서로를 제한하고 영향을 미칩니다. 때로는 이 세 가지 측면의 균형 전략이 기업 수준의 요구 사항이 되어 기업의 행동을 결정하기도 합니다. 우리는 IBM의 소프트웨어가 품질을 가장 중요한 목표로 삼는다는 것을 알고 있습니다. Microsoft의 "충분히 좋은 소프트웨어" 전략은 훨씬 더 친숙합니다. 이러한 품질 목표는 실제로 회사의 전략적 목표를 기반으로 합니다. 따라서 품질 보증에 사용되는 SQA 작업도 기업의 전략적 목표를 기반으로 해야 하며 이러한 관점에서 SQA를 생각하고 SQA에 대한 이론적 이해를 형성해야 합니다.

소프트웨어 업계는 소프트웨어 프로젝트의 진행, 비용, 품질에 영향을 미치는 요소가 주로 '사람, 프로세스, 기술'이라는 데 공감대를 형성했습니다. 먼저 분명히 짚고 넘어가야 할 점은 이 세 가지 요소 중 사람이 먼저라는 것이다.

요즘 CMM을 구현하는 많은 사람들이 CMM 이론에 중독되어 "프로세스"를 너무 강조하는 것은 매우 위험한 경향입니다. 이러한 이념적 경향은 해외에서 거센 비판을 받아왔다. 어떤 의미에서는 다양한 애자일 프로세스 방식을 제안한 것은 프로세스를 강조한 반영이다. "XP"의 아이디어 중 하나는 "과정보다 사람이 더 중요하다"는 점입니다. 제 개인적인 의견은 프로세스 개선에 있어 '사람 중심'을 고수하고 프로세스와 사람의 조화를 강조하는 것입니다.

Modern Software Engineering이 실패한 많은 프로젝트를 조사한 결과, 관리가 프로젝트 실패의 주요 원인인 것으로 나타났습니다. 이 사실의 중요성은 "프로젝트가 실패하지 않도록 하려면 관리에 더 많은 관심을 기울여야 한다"는 점을 설명하는 것입니다. 이 사실은 "좋은 관리가 프로젝트의 성공을 보장할 수 있습니다."라는 또 다른 문제를 설명하지 않는다는 점에 유의하십시오. 오늘날 많은 사람들은 대략적인 논리에 근거하여 이러한 결론을 도출하는데, 이는 논리적으로 잘못된 것이며, 이는 SQA에 대한 이해에도 반영됩니다.

역사적 발전을 살펴보면 CMM의 본질을 더 쉽게 이해할 수 있을 것입니다. CMM은 주로 미 국방부 공급업체의 품질 보장 능력을 평가하는 "평가 표준"으로 처음 등장했습니다. CMM이 중점을 두고 있는 소프트웨어 제작은 다음과 같은 특징을 가지고 있습니다.

(1) 품질이 중요합니다

(2) 대규모

이것이 바로 CMM의 등장 "종합 품질 관리"라는 개념을 소개하며, 특히 "종합 품질 관리" 중 "공정 방법"에 중점을 두고 "통계적 공정 관리" 방법을 소개합니다. 이 두 가지 아이디어가 CMM의 기반이라고 할 수 있습니다.

위 내용은 소프트웨어 프로세스의 상태와 가치에 대한 기본적인 이해를 형성하며 이를 바탕으로 SQA에 대한 논의를 확장할 수 있습니다.

2. 생산 라인의 비유

소프트웨어 생산을 공장 생산에 비유한다면. 그러면 생산 라인이 공정이고, 생산 라인의 지정된 공정에 따라 제품이 생산됩니다. SQA의 책임은 프로세스 실행, 즉 생산 라인의 정상적인 실행을 보장하는 것입니다.

관리 시스템 모델은 다음과 같이 추상화됩니다. 이 모델은 프로세스 시스템이 "의사결정, 실행 및 피드백"이라는 세 가지 중요한 측면을 포함해야 함을 보여줍니다.

QA의 책임은 프로세스의 효과적인 실행을 보장하고 프로세스에 따라 프로젝트 활동을 감독하는 것입니다. 제품의 품질을 감독하고 프로젝트 상태를 경영진에게 제공할 책임은 없습니다. 경영진을 대신하여 관리하며 프로세스 실행을 보장하기 위해 경영진을 대표합니다.

3. SQA와 기타 업무의 결합

많은 회사에서 SQA 업무는 QC, SEPG 및 조직 수준 프로젝트 관리자의 업무와 혼합되어 있습니다. SQA의 자체 업무를 수행하는 대신 작업의 다른 측면에 더 많은 관심을 기울이십시오.

hjhza의 의견에 따르면 "중국에는 기본적으로 세 가지 유형의 QA가 있습니다(작업 우선순위에 따라 구분됨). 하나는 프로세스 개선 유형, 하나는 구성 관리 유형, 다른 하나는 테스트 유형입니다." 개인적으로 SQA 업무가 다른 업무와 결합되어 있기 때문이라고 생각합니다.

다음은 내 경험을 바탕으로 둘 사이의 관계를 설명합니다.

4. QA 및 QC

두 가지 모두의 기본 책임

QC: 제품의 품질을 검사하고 제품이 고객 요구를 충족하는지 확인하는 것이 바로 제품 품질입니다.

QA: 프로세스 품질을 감사하여 프로세스가 올바르게 실행되는지 확인합니다.

검사와 감사의 차이점에 주의하세요. /p>

검사: 우리가 흔히 말하는 것은 결점을 찾는 것입니다.

감사: 프로젝트가 요구대로 수행되고 있다는 증거를 확인하기 위해 사용된 용어를 자세히 살펴봅니다. 많은 "확인"을 사용하는 CMM의 각 KPA에 대한 SQA 검사. 감사 내용은 주로 프로세스와 관련되어 있으며 프로젝트 관리자 및 고위 관리자의 검토 내용을 CMM과 비교하므로 특정 내용에 더 많은 관심을 기울입니다. .

위의 관리 시스템 모델과 비교하여 QC는 품질 관리를 수행하고 품질 정보를 경영진에 피드백합니다. QA는 QC가 프로세스에 따라 품질 관리 활동을 수행하고 검사 결과를 경영진에게 보고하도록 보장합니다. 과정. 이것이 QA와 QC 작업의 관계입니다.

이러한 분업 원칙에 따라 QA는 프로젝트가 프로세스에 따라 특정 활동을 수행했는지, 특정 제품이 생산되었는지 여부만 확인하면 되고, QC는 제품이 품질을 충족하는지 확인하면 됩니다. 요구 사항.

회사에 원래 QC 인력이 있고 QA 인력이 부족한 경우 먼저 QC가 QA 업무도 맡는다고 판단할 수 있습니다. 그러나 이는 일시적일 수 있으며 QC 작업도 프로세스 요구 사항을 따르고 감사를 받아야 하기 때문에 독립적인 QA 인력이 있어야 합니다. 이러한 혼합된 상황으로 인해 QC 작업의 프로세스 품질을 보장하기가 어렵습니다.

5. QA 및 SEPG

두 가지 모두의 기본 책임

SEPG: 프로세스 개발 및 프로세스 개선 구현

QA: 프로세스 보장; 올바르게 실행하십시오.

SEPG는 프로젝트 팀이 프로젝트 프로세스를 공식화하고 계획을 세우는 데 도움이 되는 프로세스 지침을 제공하여 프로젝트 팀이 효과적으로 작업하고 프로세스를 효과적으로 실행할 수 있도록 도와야 합니다. 프로젝트와 프로세스에 대한 QA의 이해 사이에 분쟁이 있는 경우 SEPG가 최종 중재자 역할을 합니다. 효과적인 프로세스 개선을 위해 SEPG는 프로젝트 데이터를 분석해야 합니다.

QA 서적도 프로세스 표준화를 진행해야 하므로 전체 QA 중 가장 경험이 많고 능력이 뛰어난 QA가 SEPG에 참여할 수 있지만 둘의 차이점에 주목하세요.

회사의 SEPG 직원이 상대적으로 깊은 개발 배경을 갖고 있는 경우 SQA 작업을 맡을 수도 있습니다. 이는 프로세스의 지속적인 개선에 도움이 되지만 법률과 법 집행의 통합으로 인해 SQA가 너무 강해 프로젝트의 독립성에 영향을 미치기 쉽습니다.

상대적으로 성숙한 관리 프로세스를 갖춘 기업의 경우 회사의 문화와 관리 메커니즘이 개선되었기 때문에 SQA 책임 범위 내에서 작업이 줄어들고 특정 프로젝트에 대한 명확한 우선순위를 가지고 SQA 계획을 수립하는 경우가 많습니다. , SQA 감사 작업이 크게 줄어들어 동시에 더 많은 프로젝트를 감사할 수 있습니다.

반면, 세부적인 업무 분업과 관리 시스템의 복잡성으로 인해 SEPG의 모든 관리 프로세스와 운영을 이해해야 하는 정규 직원이 필요한 경우가 많습니다. 이를 바탕으로 전반적인 상황을 조정할 수 있으며, 전반적인 상황을 이해하는 SQA 인력이 정규 SEPG의 주요 후보자가 되며 점차적으로 SEPG 인력으로 전환됩니다. 경영 지식과 SQA 업무는 점차 아르바이트가 될 것입니다.

이러한 상황은 많은 CMM5 회사에서 흔히 발생합니다. SQA 인력은 프로젝트 팀에 종종 나타나지 않거나 거의 나타나지 않습니다. SEPG와 SQA의 통합은 조직의 프로세스 개선 작업에 특히 유용합니다. SEPG는 프로세스 개선 내용을 결정하고, SQA 계획은 이러한 개선 내용을 반영하여 효과적인 개선을 보장하는 데 중점을 두고 있으며, 이는 특히 CMM5의 요구 사항을 충족하는 데 도움이 됩니다. 이러한 관점에서 볼 때 왜 외국 SQA 인력이 높은 급여를 받는지 이해하는 것은 어렵지 않습니다. 이는 또한 중국 SQA 인력이 현재 관리 프로세스가 완벽하지 않기 때문에 무시당하는 이유를 결정합니다. 우리 SQA 인력은 아직 그렇게 훌륭한 성과를 내지 못했습니다. 값!

6. QA 및 조직 수준 감독 및 관리

프로젝트를 더 잘 감독하고 관리하기 위해 일부 회사에서는 "조직 수준 감독 관리자"라는 역할을 설정했습니다. ”, 그들의 책임은 모든 프로젝트에 대한 경영진의 가시성과 관리 용이성을 보장하기 위해 모든 프로젝트에 대한 통합 추적, 감독 및 적절한 관리를 수행하는 것입니다.

프로젝트를 효과적으로 관리하기 위해서는 '조직 감독 관리자'가 프로젝트 데이터를 분석해야 한다.

이들의 책임은 위 모델에 따라 "피드백" 기능을 수행하는 것입니다.

QA 자체는 피드백을 제공하지 않고, 프로세스 실행 정보에 대한 피드백만 제공합니다.

SQA 직원은 매우 조심스럽습니다.

더 나은 관리 프로세스가 확립되면 프로젝트의 가시성이 향상되어 회사의 모든 프로젝트에 대한 더 나은 관리가 보장되고 QA는 이러한 관리 프로세스의 운영을 보장합니다.

5. SQA 작업 내용 및 작업 방법

1. 계획

프로젝트 팀이 프로세스를 올바르게 실행할 수 있도록 특정 프로젝트에 대한 SQA 계획을 개발합니다. SQA 계획을 세울 때 다음 사항에 주의해야 합니다.

중점: 기업 목표 및 프로젝트 조건을 기반으로 감사의 초점을 결정합니다.

명확한 감사 내용: 어떤 것이 무엇인지 명확히 합니다. 활동 및 제품이 감사됩니다.

감사 방법 명확화: 감사 수행 방법 결정

감사 결과 보고 규칙 명확화: 감사 결과 보고 대상

2. 감사/확인

SQA 계획에 따라 SQA 감사 업무를 수행하고 규정에 따라 감사 결과 보고서를 발행합니다.

감사에는 프로젝트 팀원이 동행해야 하며 기습 공격은 허용되지 않습니다. 양측은 서로 개방적이고 정직해야 합니다.

감사 내용: 해당 활동이 프로세스 요구사항에 따라 수행되었는지, 해당 제품이 프로세스 요구사항에 따라 생산되었는지 여부.

3. 문제 추적

감사 중에 발견된 문제를 개선하도록 프로젝트 팀에 요청하고 해결될 때까지 후속 조치를 취합니다.

6. SQA의 품질

프로세스 중심: 프로세스가 보장되는 한 문제는 프로세스의 관점에서 고려되어야 합니다.

서비스 정신: 프로젝트 팀에 봉사하고 프로젝트 팀이 프로세스의 올바른 실행을 보장하도록 돕습니다.

프로세스 이해: 회사의 엔지니어링에 대해 깊이 이해하고 특정 이론적 지식을 보유합니다. 프로세스 관리

개발 이해 : 개발 업무의 기본 상황을 이해하고 프로젝트 활동을 이해할 수 있는 능력

의사소통 능력 : 의사소통을 잘하고 좋은 분위기를 조성할 수 있으며, 감사 활동이 결함 찾기 활동이 되는 것을 방지합니다.

7. SQA 활동

소프트웨어 품질 보증(SQA)은 전체 소프트웨어 프로세스에 적용되는 활동입니다.

1. 일종의 품질입니다. 관리 방법

2. 효과적인 소프트웨어 엔지니어링 기술(방법 및 도구)

3. 소프트웨어 프로세스 전반에 걸쳐 사용되는 공식적인 기술 검토

4. 1. 다중 수준의 테스트 전략

5. 소프트웨어 문서 및 수정 사항의 통제

6. 소프트웨어가 소프트웨어 개발 표준을 준수하는지 확인

7. 측정 및 보고 메커니즘

SQA는 기술 작업을 수행하는 소프트웨어 엔지니어와 품질 보증의 계획, 감독, 기록, 분석 및 보고를 담당하는 SQA 팀이라는 두 가지 참가자로 구성됩니다.

소프트웨어 엔지니어는 신뢰할 수 있는 기술적 방법과 조치를 채택하고, 공식적인 기술 검토를 수행하고, 잘 계획된 소프트웨어 테스트를 수행하고, 소프트웨어 품질 보증 및 품질 관리 활동을 완료함으로써 품질 문제를 고려합니다.

SQA 팀의 책임은 소프트웨어 엔지니어링 팀이 고품질 최종 제품을 얻을 수 있도록 지원하는 것입니다. SQA 팀은 다음을 완료했습니다.

(1) 프로젝트에 대한 SQA 계획을 준비합니다. 이 계획은 프로젝트에서 규정한 프로젝트 계획을 개발하는 동안 수립되며 모든 이해관계자의 검토를 받습니다.

·필수 감사 및 검토,

·프로젝트에서 채택할 수 있는 표준,

·오류 보고 및 추적 절차,

·SQA 팀이 제작한 문서,

·소프트웨어 프로젝트 팀에 제공된 피드백의 양.

(2) 개발 프로젝트와 관련된 소프트웨어 프로세스에 대한 설명입니다. 프로세스 설명을 검토하여 프로세스가 조직 정책, 내부 소프트웨어 표준, 외부 표준 및 프로젝트 계획의 기타 부분과 일치하는지 확인하십시오.

(3) 다양한 소프트웨어 엔지니어링 활동을 검토하고 정의된 소프트웨어 프로세스를 준수하는지 확인합니다. 프로세스의 편차를 문서화하고 추적합니다.

(4) 지정된 소프트웨어 작업 제품을 감사하고 사전 정의된 요구 사항을 충족하는지 확인합니다. 제품을 검토하고, 편차를 식별, 기록 및 추적하고, 수정되었는지 확인하고, 작업 결과를 프로젝트 관리자에게 정기적으로 보고합니다.

(5) 소프트웨어 작업 및 제품의 편차를 문서화하고 사전 결정된 절차에 따라 처리하는지 확인하십시오.

(6) 모든 위반 사항을 기록하고 고위 리더에게 보고합니다.

8. 공식 기술 검토(FTR)

공식 기술 검토는 소프트웨어 엔지니어 및 기타 전문가가 수행하는 소프트웨어 품질 보증 활동입니다.

1. 목표:

(1) 기능적, 논리적 또는 구현 오류를 찾습니다.

(2) 검토된 소프트웨어가 실제로 요구 사항을 충족하는지 확인합니다.

(3) 소프트웨어 표현이 사전 정의된 표준을 준수하는지 확인

(4) 소프트웨어를 일관된 방식으로 개발

(5) 프로젝트 관리를 더 쉽게 만들기

2. 검토 회의

3~5명이 2시간 이내로 검토 위원장, 검토자 및 제작자가 참석하여 다음 중 하나를 결정해야 합니다.

p>

(1) 작업 결과물을 수정 없이 승인할 수 있는지 여부,

(2) 심각한 오류로 인한 작업 결과물 거부,

(3) 임시 작업 결과물의 수락.

3. 요약 보고서 및 답변 검토

검토 내용은 무엇입니까? 누구에 의해 검토되었나요? 결론은 무엇입니까?

리뷰 요약 보고서는 프로젝트 기록의 일부이며 제품의 문제 영역을 식별하고 생산자가 수정하도록 안내하는 관리 체크리스트 역할을 합니다.

4. 검토 지침

(1) 생산자가 아닌 제품을 검토하십시오. 오류를 정중하게 지적하고 편안한 분위기를 유지하도록 주의하세요.

(2) 주제에서 벗어나 토론을 제한하지 마세요. 동의하지 않는 문제는 논쟁을 벌이는 것이 아니라 문서화해야 합니다.

(3) 다양한 문제에 대한 의견을 표현합니다. 문제 해결은 검토 회의 이후로 연기되어야 합니다.

(4) 검토할 각 작업 산출물에 대한 체크리스트를 만듭니다. 분석, 설계, 코딩 및 테스트 문서화를 위한 체크리스트를 수립해야 합니다.

(5) 자원과 시간을 할당하십시오. 검토는 소프트웨어 엔지니어링 작업으로 예약되어야 합니다.

(6) 이전 리뷰 검토

9. 통계적 소프트웨어 품질 보증

1. 모든 오류를 분류하고 계산합니다.

IES 사양은 불완전하거나 사양이 잘못됨

MCC가 사용자 의도를 이해하지 못함

IDS가 의도적으로 사양에서 벗어남

VPS가 프로그래밍 표준을 위반함

EDR 데이터 표현이 잘못됨

ICI 구성 요소 인터페이스가 일관되지 않음

EDL 설계 논리가 잘못됨

IET 테스트가 불완전하거나 잘못됨

IID 부정확함 또는 불완전한 문서

PLT 설계 프로그래밍 언어 번역 오류

HCI 불분명하거나 일관성이 없는 인간-기계 인터페이스

MIS 기타 오류

통계 심각도, 보통, 경미 수준에 따른 다양한 유형의 오류 수 비율과 전체 오류 수 및 비율입니다. 예를 들어, 다음과 유사한 테이블을 만듭니다.

그런 다음 "중요한 몇 가지" 오류 표시를 고려하고 개선 사항을 제안합니다.

2. 소프트웨어 프로세스의 각 단계를 기반으로 오류 지표를 계산합니다.

Ei = i에서 발견된 총 오류 수

Si = 심각한 오류 수

Mi = 일반 오류 수

Ti = 사소한 오류 번호

PS = i단계의 제품 규모(LOC, 설계 명세서, 문서 페이지 수)

Ws, Wm 및 Wt는 심각하고 일반적인 오류에 대한 가중치 요소입니다. 및 사소한 오류 각각 권장 값, Ws=10, Wm=3, Wt=1

소프트웨어 엔지니어링 프로세스의 모든 단계에서 각 단계의 단계 지표가 계산됩니다.

PIi = Ws(Si/Ei) Wm(Mi/Ei) Wt(Ti/Ei)

오류 지수

Ei= ∑(i×PIi)/PS

= (PI1 2PI2 3PI3 … i*PIi)/PS

위 표에서 수집된 정보와 오류 측정항목을 결합하면 전반적인 소프트웨어 품질 개선 측정항목이 생성됩니다.

7. 품질 보증 및 검사

각 개발 프로세스의 품질을 보장하고 소프트웨어 오류가 다음 프로세스로 확산되는 것을 방지하기 위한 검사의 목적은 두 가지입니다.

1 . 개발 단계를 효과적으로 관리하고 각 개발 단계에서 품질 보증을 확인합니다.

2． 소프트웨어 오류로 인해 사용자에게 손실이 발생하는 것을 방지합니다.

검사 유형은 다음과 같습니다.

1. 공급검사 : 소프트웨어 제품을 구성하는 부품, 사양, 반제품 또는 외부기관에 개발업무를 위탁하여 구매 또는 양도한 제품을 검사하는 것을 말한다.

2． 중간 점검/단계 검토의 목적은

후속 개발을 위해 다음 단계로 진입할 수 있는지 판단하고 오류가 후속 작업으로 확산되는 것을 방지하는 것입니다.

3． 승인 검사:

제품이 제품 검사를 위한 품질 요구 사항에 도달했는지 확인합니다.

4． 제품 검사:

사용자에게 제공된 소프트웨어 제품이 만족스러운지 확인

다음 사항을 살펴볼 수 있습니다...