표준 기반 개발 관행을 사용해야 하는 이유(필요하지 않더라도)

전체 산업은 IEC 61508, ISO 26262, IEC 62304, MISRA C 및 CWE와 같은 기능 안전, 보안 및 코딩 표준에 의해 옹호되는 검증 및 검증 관행을 중심으로 발전했습니다. 물론 모든 사람이 이러한 표준이 추진하는 공식 프로세스와 방법론을 따를 의무는 없습니다. 특히 해당 소프트웨어가 이러한 표준의 엄격함을 충족할 필요가 없는 경우에는 더욱 그렇습니다. 그러나 경험에 따르면 표준은 고품질의 안정적이고 강력한 소프트웨어를 달성하는 가장 효과적인 방법을 나타내기 때문에 표준은 모범 사례를 옹호합니다.

이러한 표준을 따르는 모범 사례 개발 기술은 처음부터 코드에 오류가 발생하지 않도록 하여 출시 시간을 늦추고 비용을 추가할 수 있는 광범위한 디버깅 활동의 필요성을 줄입니다. 물론 모든 개발자가 항공우주, 자동차 또는 의료 기기 산업에서 볼 수 있는 응용 프로그램에 시간과 예산을 투자할 여유가 있는 것은 아닙니다. 그러나 그들이 배포하는 기술은 중요도가 사용을 강제하는지 여부에 관계없이 모든 개발 팀에 엄청난 잠재적 이점이 있는 도구 상자를 나타냅니다.

오류 유형 및 해결 도구

소프트웨어에서 두 가지 주요 유형의 오류를 찾을 수 있으며 오류 발생을 방지하는 도구를 사용하여 해결할 수 있습니다.

• 코딩 오류. 예를 들어 배열 범위 외부에 액세스를 시도하는 코드가 있습니다. 이러한 종류의 문제는 정적 분석을 수행하여 감지할 수 있습니다.
• 응용 프로그램 오류. 이는 애플리케이션이 수행해야 하는 작업을 정확히 알아야만 감지할 수 있습니다. 즉, 요구 사항에 대한 테스트를 의미합니다.

코딩 오류 및 코드 검토

정적 분석은 특히 프로젝트 시작부터 배포될 때 코딩 버그를 감지하는 효과적인 기술입니다. 코드가 분석되면 다양한 유형의 결과를 볼 수 있습니다. 코드 검토는 MISRA C:2012와 같은 코딩 표준에 대해 코드를 확인하는 것입니다. 이 문서에서 중점적으로 다룰 내용입니다.

이상적으로는 Ada와 같은 안전한 언어가 모든 임베디드 프로젝트에 사용됩니다. Ada에는 오류를 자연스럽게 줄이는 사고 과정을 시행하기 위한 다양한 특성이 포함되어 있습니다(예:엄격한 입력). 불행히도 Ada에 대한 지식과 경험이 있는 프로그래머를 찾기가 어렵기 때문에 대부분의 회사에서 C 및/또는 C++를 대신 사용합니다. 그러나 이러한 언어는 숙련된 개발자에게도 함정이 있습니다. 다행히 코드 검토를 수행하면 이러한 잠재적 함정의 대부분을 피할 수 있습니다.

코드의 결함을 피하는 가장 좋은 방법은 결함을 거기에 두지 않는 것입니다. 이것은 당연하게 들리지만 이것이 바로 코딩 표준이 하는 일입니다. C 및 C++ 세계에서 소프트웨어 결함의 약 80%는 언어의 약 20%를 잘못 사용하여 발생합니다. 문제가 있는 것으로 알려진 언어 부분을 피하기 위해 언어 사용을 제한하면 결함이 방지되고 소프트웨어 품질이 크게 향상됩니다.

C/C++ 프로그래밍 언어에서 언어와 관련된 기본 실패 원인은 정의되지 않은 동작, 구현에서 정의된 동작 및 지정되지 않은 동작입니다. 이러한 동작은 소프트웨어 버그 및 보안 문제로 이어집니다.

구현 정의 동작의 예로 부호 있는 정수가 오른쪽으로 이동될 때 상위 비트의 전파를 고려하십시오. 결과는 0x40000000입니까 아니면 0xC0000000입니까?

그림 1:일부 C 및 C++ 구성의 동작은 사용되는 컴파일러에 따라 다릅니다. (출처:LDRA)

대답은 사용 중인 컴파일러에 따라 다릅니다(그림 1). 둘 중 하나일 수 있습니다. 함수에 대한 인수가 평가되는 순서는 C 언어에서 지정되지 않습니다. 그림 2에 표시된 코드에서 - 여기서 rollDice() 함수는 단순히 "1, 2, 3 및 4" 값을 보유하는 순환 버퍼에서 다음 값을 읽습니다. 예상되는 반환 값은 1234입니다. 그러나 이에 대한 보장은 없으며 최소한 하나의 컴파일러에서 다음을 반환하는 코드를 생성합니다. 값 3412.

그림 2:일부 C 및 C++ 구성의 동작은 언어에 의해 지정되지 않습니다. (출처:LDRA)

C/C++ 언어에는 이와 같은 많은 함정이 있지만 코딩 표준을 사용하면 이러한 정의되지 않고 지정되지 않고 구현에 정의된 동작을 피할 수 있습니다. 마찬가지로 goto와 같은 구문을 사용합니다. 또는 malloc 결함으로 이어질 수 있으므로 코딩 표준을 사용하여 이러한 구성이 사용되는 것을 방지할 수 있습니다. 부호 있는 값과 부호 없는 값을 혼합할 때 많은 문제가 발생하여 대부분의 경우 문제가 발생하지 않지만 때로는 부호 있는 값이 오버플로되어 음수가 되는 경우가 있을 수 있습니다.

코딩 표준은 코드가 특정 스타일로 작성되었는지 확인할 수도 있습니다. 예를 들어 탭 문자가 사용되지 않았는지, 들여쓰기가 특정 크기인지 또는 괄호가 특정 위치에 있는지 확인합니다. 이는 일부 수동 코드 검토가 필요하고 탭 문자의 크기가 다른 다른 편집기에서 코드를 볼 때 이상한 레이아웃으로 인해 검토자가 코드 검토에 집중하지 못하도록 하기 때문에 중요합니다.

일부 개발자는 매우 효율적이고 간결할 수 있지만 다른 사람들이 이해하기 어렵게 만드는 비밀스럽고 복잡할 수 있는 "영리한" 코드를 작성하는 죄를 범하고 있습니다. 단순하게 유지하고 컴파일러가 효율적인 바이너리를 만들도록 하는 것이 훨씬 좋습니다. 다시 한 번, 코딩 표준을 사용하면 개발자가 문서화되지 않고 지나치게 복잡한 코드를 만드는 것을 방지할 수 있습니다.

가장 잘 알려진 프로그래밍 표준은 아마도 자동차 산업을 위해 1998년에 처음 발표된 MISRA 표준일 것입니다. 이러한 표준의 인기는 일정 수준의 MISRA 검사를 제공하는 임베디드 컴파일러의 수에 반영됩니다. MISRA의 최신 버전은 MISRA C:2012로 이전 버전의 페이지 수가 거의 두 배입니다. 이 추가 문서의 대부분은 각 규칙이 존재하는 이유에 대한 유용한 설명과 함께 해당 규칙에 대한 다양한 예외에 대한 세부 정보로 구성됩니다. MISRA에는 몇 가지 지침이 있으며 해당되는 경우 표준 또는 정의되지 않은, 지정되지 않은 및 구현 정의 동작에 대한 참조가 포함됩니다. 이에 대한 예는 그림 3에서 볼 수 있습니다.

그림 3:정의되지 않은, 지정되지 않은, 구현 정의 동작에 대한 MISRA C 참조. (출처:LDRA)

MISRA 지침의 대부분은 "결정 가능"이며, 이는 도구가 위반 여부를 식별할 수 있어야 함을 의미합니다. 그러나 몇 가지 지침은 "결정 불가능"입니다. 즉, 도구가 위반 여부를 추론하는 것이 항상 가능한 것은 아닙니다. 이것의 예는 초기화되지 않은 변수가 그것을 초기화해야 하는 시스템 함수에 출력 매개변수로 전달되는 경우입니다. 그러나 정적 분석이 시스템 함수의 소스 코드에 액세스할 수 없으면 초기화하기 전에 해당 함수가 변수를 사용하는지 알 수 없습니다. 간단한 MISRA 검사기가 사용되는 경우 이 위반을 보고하지 않을 수 있으며 위음성으로 이어질 수 있습니다. 또는 MISRA 검사기가 확실하지 않은 경우 위반을 보고하여 오탐으로 이어질 수 있습니다. 가장 좋은 것은 무엇입니까? 문제가 있을 수 있다는 것을 모르십니까? 아니면 문제가 없는지 확인하기 위해 시간을 어디에 보낼지 정확히 알고 계십니까? 확실히 위음성보다는 위양성을 갖는 것이 바람직합니다.

2016년 4월, MISRA 위원회는 MISRA가 안전에 중요한 소프트웨어뿐만 아니라 보안에 중요한 소프트웨어에도 적용 가능하도록 14개의 추가 지침을 추가한 MISRA C:2012에 대한 수정안을 발표했습니다. 이러한 지침 중 하나는 지침 4.14로, 그림 4에서 볼 수 있듯이 정의되지 않은 동작으로 인한 함정을 방지하는 데 도움이 됩니다.

그림 4:MISRA 및 보안 고려 사항. (출처:LDRA)

애플리케이션 오류 및 요구사항 테스트

응용 프로그램 버그는 제품이 해야 할 일을 하고 요구 사항이 있음을 의미하는지 테스트해야만 찾을 수 있습니다. 애플리케이션 버그를 피하려면 올바른 제품을 설계하고 제품을 올바르게 설계해야 합니다.

올바른 제품을 설계한다는 것은 요구 사항을 미리 설정하고 요구 사항과 소스 코드 간의 양방향 추적성을 보장하여 모든 요구 사항이 구현되고 모든 소프트웨어 기능이 요구 사항을 역추적하는 것을 의미합니다. 누락되거나 불필요한 기능(요구 사항을 충족하지 않음)도 애플리케이션 버그입니다. 제품권을 디자인하는 것은 개발된 시스템 코드가 프로젝트 요구사항을 충족하는지 확인하는 과정이며 요구사항 기반 테스트를 수행하여 달성할 수 있습니다.

그림 5는 양방향 추적 가능성의 예를 보여줍니다. 이 간단한 예에서는 단일 기능이 선택되었으며 업스트림 추적 가능성이 기능에서 하위 수준 요구 사항, 상위 수준 요구 사항, 마지막으로 시스템 수준 요구 사항으로 강조 표시됩니다.

그림 5:기능이 선택된 양방향 추적 가능성. (출처:LDRA)

그림 6에서는 상위 수준 요구 사항이 선택되었으며 강조 표시는 시스템 수준 요구 사항에 대한 업스트림 추적 가능성과 하위 수준 요구 사항 및 소스 코드 기능에 대한 다운스트림 추적 가능성을 모두 보여줍니다.

더 큰 이미지를 보려면 클릭하세요.

그림 6:요구 사항이 선택된 양방향 추적 가능성. (출처:LDRA)

추적 가능성을 시각화하는 이러한 기능은 수명 주기 초기에 추적 가능성 문제(응용 프로그램 버그)를 감지할 수 있습니다.

코드 기능을 테스트하려면 수행해야 하는 작업에 대한 인식이 필요하며, 이는 각 기능이 수행하는 작업을 명시하는 낮은 수준의 요구 사항을 의미합니다. 그림 7은 이 경우 단일 기능을 완전히 설명하는 하위 수준 요구 사항의 예를 보여줍니다.

그림 7:하위 수준 요구 사항의 예. (출처:LDRA)

테스트 케이스는 표 1과 같이 낮은 수준의 요구 사항에서 파생됩니다.

표 1:하위 수준 요구 사항에서 파생된 테스트 사례. (출처:LDRA)

단위 테스트 도구를 사용하면 이러한 테스트 사례를 호스트 또는 대상에서 실행하여 코드가 요구 사항에 따라 작동하는지 확인할 수 있습니다. 그림 8은 모든 테스트 케이스가 회귀되어 통과되었음을 보여줍니다.

그림 8:단위 테스트 수행. (출처:LDRA)

테스트 케이스가 실행되면 모든 코드가 실행되었는지 확인하기 위해 구조적 적용 범위를 측정해야 합니다. 커버리지가 100%가 아니라면 더 많은 테스트 케이스가 필요하거나 제거해야 할 불필요한 코드가 있을 수 있습니다.

결론

소프트웨어 복잡성이 증가함에 따라 잠재적인 소프트웨어 오류도 증가합니다. 모범 사례 개발 기술은 이러한 오류가 발생하는 것을 방지하는 데 도움이 됩니다. 모범 사례 개발은 MISRA C:2012와 같은 최신 코딩 표준 사용, 코드에 대한 메트릭 측정, 요구 사항 추적 및 요구 사항 기반 테스트 구현으로 구성됩니다. 표준을 충족할 의무가 없는 경우 이러한 기술이 적용되는 범위는 개발 팀의 재량에 달려 있습니다. 그러나 경험에 따르면 표준이 품질, 안정적이고 강력한 소프트웨어를 달성하는 가장 효과적인 방법을 나타내기 때문에 표준은 이러한 관행을 옹호합니다. 그리고 제품이 안전에 중요한지 여부에 관계없이 개발 팀에만 도움이 될 수 있는 결과입니다.