설계 검증 및 검증 프로세스

디자인 검증

디자인 검증 설계 검증은 설계된 소프트웨어 제품의 출력이 입력 사양을 충족하는지 검사 및 증거 제시를 통해 확인하는 방법입니다. 소프트웨어 개발 과정에서 설계 검증 프로세스의 목표는 설계된 소프트웨어 제품이 명시된 내용과 동일한지 확인하는 것입니다.

설계 입력은 설계의 기초가 되는 모든 물리적 및 성능 요구 사항을 의미합니다. 설계 출력은 각 설계 단계와 전체 설계 노력의 결과물입니다. 의료기기와 같은 규제 산업에서는 최종 설계 출력이 기기 마스터 레코드의 기초가 되기 때문에 검증 문서에 설계 관리 용어가 자주 등장합니다.

실제로 검증은 두 가지 문서 세트를 비교하는 것입니다. 하나는 입력된 사양, 표준 및 제약 조건이고, 다른 하나는 출력된 도면, 코드 및 테스트 지침입니다. 이 두 문서 세트 간의 불일치는 모두 검증 결과로 간주됩니다.

디자인 검증

검증은 내부 일관성을 입증합니다. 유효성 검사는 명세서가 애초에 올바른 제품을 설명했는지에 대한 더 어려운 질문을 던집니다.

디자인 검증 설계 검증은 최종 사용자 또는 이해관계자의 정확한 요구사항에 비추어 소프트웨어 제품을 평가하는 과정입니다. 설계 검증의 목적은 소프트웨어 제품 개발 후 사용자의 환경에서 사용될 때 해당 요구사항을 충족하는지 확인하기 위해 테스트를 수행하는 것입니다.

검증은 사용자 요구사항에 비추어 설계의 일관성과 완성도를 입증하는 과정입니다. 이 단계에서는 실제로 제품의 버전을 제작하고 사용자 요구사항에 맞춰 검증합니다.

아래 배너는 디자인 기록에 일반적으로 제시되는 활동의 두 부분을 나타냅니다.

다음 다이어그램은 사용자 요구사항부터 검증된 제품에 이르기까지 설계 검증 프로세스 자체를 보여줍니다.

목적은 제품이 문서화된 사용자 요구 사항을 충족한다는 것을 객관적인 증거로 입증하는 것입니다. 객관적인 증거란 절차가 실제로 수행되었음을 보여주는 결과물(이미지, 텍스트 파일, 오디오 파일 또는 서명된 보고서)의 물리적 증거를 의미합니다.

객관적인 증거를 통해 제품이 사전에 정의된 요구 사항을 충족하는지 여부를 지속적으로 검토합니다. 이 과정에는 시험 활동, 검사, 분석 및 유사한 기술이 포함되므로 검증은 일반적으로 다음과 같은 방법을 활용합니다. 시스템 테스트 사용자 수용 테스트 단위 수준 검사가 아닌.

설계 검증과 검증의 차이점

검증과 유효성 검사 사이에는 항상 오해가 있습니다. 이 둘은 서로 다른 활동이며, 특정 마일스톤에서만 수행되는 것이 아니라 개발 프로세스의 모든 단계에서 수행됩니다.

유용한 지름길: 검증은 대부분 정적 작업 문서에 대한 검증이 주로 이루어지는 반면, 유효성 검사는 대부분 문서에 대한 검증입니다. 동적 테스트 실행 중인 빌드에 대해.

설계 검증 프로세스

검증 과정은 5단계로 진행되며, 각 단계에서 다음 단계에 필요한 결과물이 생성됩니다.

식별 및 준비:

• 사양서가 개발되는 동안 검증 활동이 병행하여 파악됩니다. 이를 통해 설계자는 사양서가 실제로 검증 가능한지 확인할 수 있으며, 테스트 엔지니어는 상세한 테스트 계획 및 절차를 수립할 수 있습니다. 사양서에 변경 사항이 있을 경우 반드시 알려야 합니다.
• 검증을 수행하는 최적의 접근 방식을 파악하고 측정 방법, 필요한 자원, 도구 및 시설을 정의합니다.
• 완성된 검증 계획은 설계팀과 함께 검토하여 계획을 최종 확정하기 전에 문제점을 파악합니다.

계획 :

• 검증 계획은 핵심 팀과 개발 팀이 동시에 진행하는 활동입니다. 프로젝트 수명 주기 전반에 걸쳐 이루어지며 설계 입력값이 변경될 때마다 업데이트됩니다.
• 이 단계에서는 테스트 대상 소프트웨어 또는 시스템의 테스트 범위를 문서화합니다.
• 초기 테스트 계획을 작성한 후 수정합니다. 이 계획에는 프로젝트 위험을 줄이는 데 중요한 이정표가 포함됩니다.
• 도구, 테스트 환경 및 개발 전략이 선택되고, 검사 또는 분석을 통해 확인해야 할 요구 사항이 식별됩니다.

개발ping:

• 테스트 케이스 개발은 다음과 일치합니다. SDLC 방법론 프로젝트 팀은 이를 실행했습니다. 이 단계에서는 다양한 테스트 방법이 확인되었습니다.
• 설계 입력값은 가장 기본적인 검증 활동조차도 모호하지 않고 검증 가능하도록 개발되어야 합니다.
• 유사한 개념을 순차적으로 검증할 경우, 한 테스트의 결과를 다음 테스트의 입력으로 재사용할 수 있기 때문에 검증 시간이 단축됩니다.
• Trac테스트 케이스와 해당 설계 입력 간에는 실행 가능성 링크가 생성되어 모든 요구 사항이 테스트되고 설계 출력이 설계 입력을 충족하는지 확인합니다.

실행:

• 개발 단계에서 작성된 테스트 절차는 테스트 계획에 따라 실행되며 검증 활동 중에 엄격하게 준수됩니다.
• 유효하지 않은 결과가 발생하거나 절차 수정이 필요한 경우, 변경 사항은 문서화하고 공식적인 승인을 받아야 합니다.
• 발견된 모든 문제는 통상적인 절차를 통해 결함으로 기록됩니다. 결함 관리 프로세스.
• A trac가능성 매트릭스 이 테스트는 검증 테스트 계획에 명시된 모든 설계 입력값이 테스트되었는지 확인하고 합격률을 결정하기 위해 만들어졌습니다.

보고서 :

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

설계 검증 프로세스

검증에는 엄격한 순서가 없습니다. 대신, 검증은 몇 가지 인정된 방법을 활용하며, 프로젝트에서는 일반적으로 하나 이상의 방법을 사용합니다.

• 유사한 설계와의 비교. 일부 설계는 유사한 목적을 수행하는 유사 장비와의 비교를 통해 검증될 수 있습니다. 이는 기존 인프라의 구성 변경이나 새로운 시스템 또는 애플리케이션에 통합되는 표준 설계를 검증할 때 특히 중요합니다.
• 시연 및 검사. 둘 중 하나 또는 둘 다를 사용하여 제품의 요구 사항 및 기타 기능을 검증할 수 있습니다.
• 분석. 해당 설계는 필요한 기능을 재현하는 수학적 모델링 또는 시뮬레이션을 통해 분석할 수 있습니다.
• 테스트. 최종 설계에 대한 테스트는 시스템이 명시된 대로 작동하는지 확인하기 위해 수행되며, 바로 이 단계에서 테스트가 진행됩니다. 기능 테스트 비기능 테스트 사용자 요구사항을 충족합니다.
• 선적 서류 비치. 시험 계획, 실행 및 결과는 설계 기록의 일부로 문서화하고 보관해야 합니다. 궁극적으로 유효성 검증은 모든 유효성 검증 활동의 종합적인 결과입니다.
• 동등성 입증. 최종 설계 검증에 동등한 제품이 사용되는 경우, 제조업체는 유사점과 초기 생산품과의 차이점을 문서화해야 합니다.

예시

간단한 예시를 통해 그 차이점을 명확히 알 수 있습니다.

• 간단한 제품을 예로 들어보겠습니다. 방수 시계입니다.
• 제품 요구사항 문서에는 "시계는 수영 중에도 방수되어야 한다"라고 명시되어 있을 수 있습니다. 이는 사용자의 요구사항이며, 검증은 바로 이 요구사항을 기준으로 이루어집니다.
• 설계 사양서에는 "사용자가 장시간 수영을 하더라도 시계는 작동해야 한다"라고 명시될 수 있습니다. 이것이 바로 설계 입력값이며, 검증은 이 입력값을 기준으로 이루어집니다.
• 테스트 결과는 해당 시계가 이러한 요구 사항을 충족하는지 확인해야 합니다. 만약 충족하지 못할 경우, 충족할 때까지 재설계 과정을 계속 진행합니다.

시계가 검증은 통과했지만 유효성 검사에는 실패할 수 있다는 점에 주목하세요. 사양에서 장시간 수영을 15분으로 정의했는데 실제 수영 선수들은 한 시간 동안 물속에 머무른다면, 설계 결과는 입력과 완벽하게 일치하더라도 사용자는 오류를 범할 수 있습니다.

설계 검증 및 검증의 장점

두 활동을 마지막 단계에서 관문으로 처리하는 것이 아니라 지속적으로 실행하는 것이 아래와 같은 이점을 가져다줍니다.

• 설계 과정을 지속적으로 모니터링할 수 있으므로 모든 단계에서 사용자가 정의한 요구 사항을 충족할 수 있습니다.
• 설계 검증은 기능이 실제로 작동하는 방식과 예상되는 작동 방식 간의 차이점을 파악하는 데 도움이 됩니다.
• 유효성 검사 절차를 문서화하면 나중에 변경이나 개선이 이루어질 때 기능을 쉽게 이해할 수 있습니다.
• 개발 시간이 지속적으로 단축되고 생산성이 향상되어 예상대로 제품을 제공할 수 있습니다.
• 이 프로세스는 사용해야 하는 각 검증 방법의 범위와 한계를 정의합니다.
• 검증은 최종 사용자 요구사항을 나타내는 상세 설계 데이터를 사용하여 수행할 수 있습니다.
• 결과와 사용자 요구 사항 문서 간의 차이점은 손실되지 않고 기록됩니다.
• 검증된 설계가 변경되면 재검증 작업이 트리거되므로 기록이 제품과 분리되지 않습니다.
• 검증 과정에서 발생하는 모든 활동을 문서화하는 것이야말로 설계가 사용자 요구사항을 충족한다는 것을 충분히 입증하는 방법입니다.

따라서 설계 검증 및 유효성 검사는 더 넓은 범위의 계획 내에서 수립하는 것이 가장 좋습니다. 소프트웨어 테스팅 수명주기 그리고 다른 하나에 매핑되었습니다 소프트웨어 테스트 유형별도의 규정 준수 활동으로 취급하기보다는,

자주 묻는 질문