설계 검증 및 검증 프로세스

디자인 검증

디자인 검증 최종 사용자나 이해관계자의 정확한 요구 사항에 맞게 소프트웨어 제품을 평가하는 프로세스입니다. 설계 검증의 목적은 개발 후 소프트웨어 제품을 테스트하여 사용자 환경의 응용 프로그램 측면에서 요구 사항을 충족하는지 확인하는 것입니다.

검증은 사용자 요구와 관련하여 설계의 일관성과 완전성을 입증하는 것과 관련이 있습니다. 이는 실제로 제품 버전을 구축하고 사용자 요구 사항에 대해 유효성을 검사하는 단계입니다.

아래 이미지는 설계 검증 프로세스를 나타냅니다.

그 목적은 제품이 사용자의 요구 사항을 문서에 만족한다는 것을 객관적인 증거로 증명하는 것입니다. 객관적인 증거는 절차가 완료되었음을 나타내는 이미지, 텍스트 또는 오디오 파일과 같은 출력의 물리적 증거일 뿐입니다.

객관적인 증거를 통해 이 프로세스는 제품이 사전 정의된 요구 사항을 충족하는지 지속적으로 검사합니다. 이 프로세스에는 테스트 활동, 검사 및 분석 등이 포함됩니다.

디자인 검증

디자인 검증 설계된 소프트웨어 제품의 출력이 입력 사양을 충족하는지 조사하고 증거를 제공하여 확인하는 방법입니다. 소프트웨어 개발 중 설계 검증 프로세스의 목표는 설계된 소프트웨어 제품이 지정된 것과 동일하다는 것을 확인하는 것입니다.

설계 입력은 설계 목적의 기초로 사용되는 물리적 및 성능 요구 사항입니다. 설계 출력은 각 설계 단계의 결과이자 전체 설계 노력의 마지막 단계입니다. 최종 설계 출력은 장치 마스터 기록의 기초가 됩니다.

설계 검증과 검증의 차이점

확인과 검증 사이에는 항상 오해가 있습니다. 이는 개발 프로세스의 모든 단계에서 수행되는 다양한 활동입니다.

설계 검증 프로세스

식별 및 준비:

• 사양 개발 단계에서는 검증 활동 식별이 동시에 수행됩니다. 이를 통해 설계자는 사양이 검증 가능한지 확인할 수 있습니다. 따라서 테스트 엔지니어는 자세한 테스트 계획 및 절차를 시작할 수 있습니다. 사양의 모든 변경 사항을 전달해야 합니다.
• 검증을 수행하고 측정 방법, 필요한 리소스, 도구 및 시설을 정의하는 최선의 접근 방식을 식별합니다.
• 완성된 검증 계획은 설계팀과 함께 검토하여 문제를 파악한 후 계획을 확정합니다.

계획 :

• 검증 계획은 핵심 팀과 개발 팀의 동시 활동입니다. 이는 프로젝트 수명주기 전반에 걸쳐 발생합니다. 이는 설계 입력이 변경되면 업데이트될 것입니다.
• 이 단계에서는 테스트 중인 소프트웨어 또는 시스템을 범위 내에서 문서화해야 합니다.
• 이 단계에서는 예비 테스트 계획과 테스트 계획 개선이 이루어집니다. 테스트 계획은 프로젝트 위험을 줄이는 중요한 이정표를 포착합니다.
• 도구, 테스트 환경, 개발 전략 및 검사 또는 분석을 통한 요구 사항 식별.

개발 중:

• 테스트 케이스 개발은 다음과 일치합니다. SDLC 방법론 프로젝트 팀에 의해 구현됩니다. 이 단계에서는 다양한 테스트 방법이 식별됩니다.
• 설계 입력은 명확하고 검증 가능한 가장 간단한 검증 활동을 포함하여 개발되어야 합니다.
• 유사한 개념이 순차적으로 수행되면 검증 시간이 단축됩니다. 심지어 한 테스트의 출력도 후속 테스트의 입력으로 사용할 수 있습니다.
• 테스트 사례와 해당 설계 입력 사이에 다루기 쉬운 링크가 생성되어 모든 요구 사항이 테스트되고 설계 출력이 설계 입력을 충족하는지 확인합니다.

실행:

• 개발 단계에서 작성된 테스트 절차는 테스트 계획에 따라 실행되며, 검증 활동에서도 이를 엄격히 준수합니다.
• 유효하지 않은 결과가 발생하거나 절차에 수정이 필요한 경우 변경 사항을 문서화하고 적절한 승인을 받는 것이 중요합니다.
• 이 단계에서는 모든 문제가 식별되어 결함으로 기록됩니다.
• 다루기 쉬운 매트릭스 검증 테스트 계획에서 식별된 모든 설계 입력이 테스트되었는지 확인하고 합격률을 결정하기 위해 생성됩니다.

보고서 :

• 이 활동은 검증 실행의 각 단계가 끝날 때 수행됩니다.
• 설계 검증 보고서는 구성 관리, 테스트 유형별 테스트 결과, 검증 활동 중에 발견된 문제를 포함하는 검증 결과에 대한 자세한 요약을 제공합니다.
• 모든 요구사항이 테스트되었으며 적절한 결과가 제공되었는지 확인하기 위해 요구사항과 해당 테스트 결과 간에 설계 검증 추적성 보고서가 생성됩니다.
• 모든 부적합 사항은 문서화되고 적절하게 처리됩니다.
• Rev설계 검증 활동이 완료되면 검토가 완료되고 각각 승인됩니다.

설계 검증 프로세스

• 일부 설계는 유사한 목적을 수행하는 유사한 장비와 비교하여 검증될 수 있습니다. 이 방법은 특히 기존 인프라의 구성 변경 사항이나 새로운 시스템이나 애플리케이션에 통합될 표준 설계를 검증하는 데 적합합니다.
• 시연 및/또는 검사는 제품의 요구 사항 및 기타 기능을 검증하는 데 사용될 수 있습니다.
• 필요한 기능을 재현할 수 있는 시뮬레이션, 수학적 모델링 등 설계 분석을 수행할 수 있습니다.
• 최종 설계에 대한 테스트를 수행하여 지정된 설계에 따라 시스템이 작동할 수 있는 능력을 검증합니다.
• 테스트 계획, 실행 및 결과는 설계 기록의 일부로 문서화되고 유지되어야 합니다. 따라서 검증은 모든 검증 활동의 결과를 모아 놓은 것입니다.
• 최종 설계 검증에 동등한 제품이 사용되는 경우 제조업체는 유사성과 초기 생산과의 차이점을 문서화해야 합니다.

예시

• 간단한 제품인 방수시계를 예로 들어보겠습니다.
• 제품 요구 사항 문서에는 "시계는 수영 중에 방수 처리되어야 합니다."라고 명시되어 있을 수 있습니다.
• 디자인 사양에는 "사용자가 장시간 수영을 해도 시계는 작동해야 합니다."라고 명시되어 있을 수 있습니다.
• 테스트 결과는 시계가 이러한 요구 사항을 충족해야 함을 확인해야 하며, 그렇지 않으면 요구 사항을 충족할 때까지 재설계 반복이 수행됩니다.

설계 검증 및 검증의 장점

• 우리는 모든 단계에서 사용자 정의 요구 사항을 충족할 수 있도록 설계를 지속적으로 모니터링할 수 있습니다.
• 디자인을 검증하면 기능이 작동하는 방식과 예상되는 작동 방식 간의 차이를 지적할 수 있습니다.
• 검증 절차를 문서화하면 향후 변경이나 개선이 있을 경우 모든 단계에서 기능을 쉽게 이해하는 데 도움이 됩니다.
• 개발 시간은 지속적으로 단축되어 생산성이 향상되어 예상한 대로 제품을 제공할 수 있습니다.
• 이 프로세스에는 채택이 요구되는 각 검증 방법의 범위와 내용이 포함됩니다.
• 최종 사용자 요구 사항을 나타내는 세부 설계 데이터를 사용하여 검증을 수행할 수 있습니다.
• 결과와 사용자 요구 문서 간의 차이를 파악해야 합니다.
• 검증 설계의 변경은 재검증 활동으로 이어집니다.
• 검증 중에 발생하는 모든 활동을 문서화하여 설계가 사용자 요구 사항을 충족한다는 것을 적절하게 입증하는 것이 중요합니다.