Software Engineering

MISRA C:2020 Compliance - 편차 기록(Deviation Record)의 목적과 필요성

habana4 2024. 8. 25. 12:07
반응형

목차

     

    MISRA 규칙을 적용하는 과정에서 모든 규칙을 100% 준수하는 것이 불가능한 상황이 발생할 수 있습니다. 이때 deviation이 발생하며, deviation을 정당화하고 기록하는 것이 중요합니다. 이를 통해 규칙 위반이 단순 실수가 아니라, 프로젝트 특성에 따른 필연적인 선택임을 설명하고, deviation이 소프트웨어의 안전성이나 품질에 미치는 영향을 최소화할 수 있는 방안을 마련하게 됩니다.

    "Deviation 기록(Deviation Record)"은 이러한 deviation이 발생했을 때, 왜 규칙을 준수하지 않았는지, 그 이유와 대처 방안을 명확하게 문서화한 기록입니다. 이 기록은 MISRA 규칙 준수를 선언할 때도 매우 중요한 문서로 작용하며, 프로젝트의 투명성을 높이고, 품질 보증에 필수적인 역할을 합니다.

     

     

    MISRA Compliance 2020: 어떻게 MISRA를 준수할 수 있을까? (MISRA 준수 방법)

    1. MISRA 준수를 위한 소프트웨어 개발 프로세스: 핵심 요소와 도구 관리MISRA 규칙 준수는 안전하고 신뢰성 있는 소프트웨어를 개발하는 데 중요한 기준입니다. 소프트웨어 개발 과정에서 MISRA 규

    habana4.tistory.com

     

    Deviation Record 구성 요소

    1. 프로젝트 정보 (Project Information)

    프로젝트 정보는 deviation이 발생한 프로젝트에 대한 기본 정보를 기록하는 부분입니다.

    • 프로젝트 이름: deviation이 발생한 프로젝트의 이름을 명시합니다.
    • 버전: deviation이 발생한 코드나 시스템의 버전을 기록합니다.
    • 작성자: deviation 기록을 작성한 담당자의 이름을 기재합니다.
    • 날짜: deviation 기록을 작성한 날짜를 명시합니다.

    이 부분은 기본 프로젝트 식별 정보를 제공하며, 기록 관리 및 추적을 용이하게 합니다.

    2. 규칙 정보 (Guideline Information)

    규칙 정보는 deviation이 발생한 MISRA 규칙에 대한 세부 정보를 포함합니다.

    • 규칙 번호: deviation이 발생한 MISRA 규칙의 번호를 명시합니다. 예를 들어, Rule 14.1이나 Directive 4.1 등이 해당합니다.
    • 규칙 설명: 해당 규칙이 요구하는 사항에 대한 간략한 설명을 포함합니다.

    이 항목은 deviation이 어떤 규칙에서 발생했는지 명확히 식별할 수 있도록 도와줍니다.

    3. Deviation 설명 (Description of the Deviation)

    Deviation 설명은 규칙을 준수하지 않은 구체적인 상황을 설명하는 부분입니다.

    • Deviation 발생 상황: 규칙을 준수하지 못한 코드나 상황을 설명합니다.
    • 위반 이유: 왜 해당 규칙을 준수할 수 없었는지에 대한 명확한 이유를 기재합니다. 이는 하드웨어 제약, 성능 문제, 코드 통합 등의 이유일 수 있습니다.

    이 항목은 deviation의 정당성을 설명하는 중요한 부분입니다. Deviation이 단순한 오류나 실수가 아니라, 프로젝트의 특성상 불가피하게 발생한 상황임을 설명하는 것이 목표입니다.

    4. 위험 분석 (Risk Assessment)

    위험 분석은 deviation이 발생했을 때 소프트웨어의 안전성이나 성능에 미칠 수 있는 영향을 평가하는 항목입니다.

    • 위험 요소 식별: deviation으로 인해 발생할 수 있는 잠재적 위험 요소를 식별합니다.
    • 위험 수준: Deviation이 시스템의 안전성, 보안성, 또는 성능에 미치는 영향을 평가하여 위험 수준을 기록합니다.
    • 위험 완화 방안: Deviation으로 인해 발생할 수 있는 위험을 줄이기 위한 대책을 명시합니다. 예를 들어, 추가적인 테스트나 코드 검토가 여기에 포함될 수 있습니다.

    이 부분은 deviation이 소프트웨어 안전성에 미치는 영향을 최소화하기 위한 절차를 설명하며, deviation으로 인해 발생할 수 있는 문제를 사전에 방지하는 계획을 명확히 합니다.

    5. 대안 고려 사항 (Consideration of Alternatives)

    대안 고려 사항은 규칙을 준수할 수 있는 다른 방법을 검토했는지를 명시하는 항목입니다.

    • 다른 접근법 검토: 규칙을 위반하지 않고 문제를 해결할 수 있는 대안적인 방법을 검토했는지 설명합니다.
    • 대안 미적용 이유: 대안이 존재했더라도, 그것이 왜 적용되지 않았는지에 대한 이유를 설명합니다.

    이 항목은 규칙을 위반하기 전에 가능한 모든 대안을 검토했음을 입증하는 역할을 합니다. 이는 규칙 위반이 최후의 수단이었음을 설명하는 중요한 항목입니다.

    6. Deviation 승인 (Deviation Approval)

    Deviation 승인은 해당 deviation을 승인하는 절차와 관련된 정보를 기록하는 부분입니다.

    • 승인자: Deviation을 공식적으로 승인한 담당자의 이름을 기재합니다.
    • 승인 날짜: Deviation이 승인된 날짜를 기록합니다.
    • 승인 이유: Deviation을 승인한 이유와 그 정당성을 간단히 설명합니다.

    이 항목은 deviation이 조직 내에서 승인되었음을 공식적으로 문서화하여, deviation이 허용된 이유를 명확히 남깁니다.

    7. 추가 설명 (Additional Comments)

    추가 설명 항목은 deviation 기록에서 다루지 않은 추가적인 정보나 고려해야 할 사항을 기재하는 항목입니다.

    이 부분은 기록을 보다 유연하게 관리할 수 있도록 추가적인 정보를 제공하는 용도로 사용됩니다.

     

    마치며...

    MISRA 준수 가이드라인의 부록 B에서 제공된 Example Deviation Record는 규칙을 준수하지 못하는 경우 이를 어떻게 기록하고 관리해야 하는지를 구체적으로 보여줍니다. 이 기록은 규칙 위반이 단순한 실수가 아닌, 정당한 이유와 위험 관리 방안이 수반된 합리적인 선택임을 설명하는 데 필수적입니다. 각 항목은 규칙 준수를 위한 투명성과 책임감을 높이는 역할을 하며, 프로젝트 종료 후 MISRA 준수를 선언할 때 중요한 근거 자료로 사용될 수 있습니다.

    Deviation 기록은 명확하고 철저하게 작성되어야 하며, 프로젝트의 모든 이해관계자가 이를 이해하고 신뢰할 수 있도록 관리해야 합니다. 이를 통해 deviation 발생 시에도 MISRA 규칙 준수가 전체적으로 유지되고 있음을 보장할 수 있습니다.

     

    반응형