Verification and Valdiation (4) 썸네일형 리스트형 Software detailed design & unit verification in the model based development(모델 기반 개발 환경/프로세스에서 SW단위설계와 단위테스트 활동) : A-SPICE & ISO 26262에서의 적용 ● 프로세스 측면 ISO 26262-6: 2018에 의하면 소프트웨어의 Safety requirements와 Non-safety requirements는 하나의 개발 프로세스 (one development process)에 의해 취급되어야 한다고 정의하고 있다. 왜냐하면 하나의 소프트웨어는 safety related requirements와 non-safety related requirement를 포함하고 있기 때문이다. 즉 SSR(SW Safety Requirements)만을 SRS(Software Requirements Specification)로 간주하여 관리 및 작성하면 안된다. 일부 현장에서는 개발 상의 리소스 및 오해의 소지로 이러한 경우가 종종 발생하고 있다. 하지만 명확한(clear), 정.. Test Coverage에 대한 오해 [Safety 분야서 소프트웨어 커버리지를 포함하는 Standard 표준] l In Avionics equipment, DO-178B에서 사용 (FAA - Federal Aviation Administration) l IEC 61508 - E/E/E/EPES - Structured based testing (SIL 3, SIL 4) l ISO 26262 - E/E Safety-related systems for automotive [**소프트웨어** 테스트 커버리지의 개념] 프로그램의 소스코드가 테스트 된 정도(degree)를 판단하는 기준 얼마나 많이 테스트 되었는가? White box testing방법으로 코드가 검사 됨 코드 커버리지는 systematic software testing을 위해 고안되.. Test Coverage의 정도 (How much?) 소프트웨어 및 시스템의 Quality improvement의 주요 활동인 Testing은 , 기존의 시스템 및 소프트웨어 개발영역에 포함된 활동으로 인식되어 오다, 현재는 시스템 및 소프트웨어가 복잡해 지면서, 주요한 영역으로 Spotlight를 받고 있다. 그럼 이러한 테스팅에서 커버리는 주요한 이슈이다. 얼마만큼 테스트를 수행을 해야 하냐는 테스팅의 Entry 또는 Exit Criteria로 많이 활용되고 있다. 커버리지 종류에는 간략하게 다음과 같이 분류 할 수 있다. 요구사항 커버리지(Requirement Coverage) - 소프트웨어, 시스템의 사양서 기반의 기능/비기능 등의 충족 정도구조 커버리지 (Structure Coverage) - 소프트웨어 Control flow 등 기반의 구문관련 .. 전장품 품질에 대한 고찰 품질의 기본은 프로세스와 제품의 관점에서 고찰해야 한다. 대부분 최고 경영층의 품질적인 측면 접근은 Defect zero관점에서 접근하다 보니, 결함이나 품질문제가 발생되는 것을 현업이나 실무 부서에서는 항상 두려워한다. 이러한 문제가 개발과정의 결함을 감추고, 필드에서 제품에 발생된 문제점을 1) 근본원인 및 2) 왜 이러한 결함이 유입 되었는가의 개관적인 고찰 없이, 무조건 빠르게 해결하고, 근본대책 및 재발방지 방안에 대해 발표를 통해 일을 마무리하고, 문제가 크게 발생될 시는 책임소재를 피하려는 방안을 강구하는데 중점을 두고 있다. 이러한 사고방식으로는 항상 결함이라는 위험을 내포할 수 밖에 없다. 이러한 문제를 해결할 수 있는 방법은 무엇인가? Defect zero is impossible (얼.. 이전 1 다음
