Software 썸네일형 리스트형 SW FMEA의 Ground Rules SW-FMEA를 시작하기 전에, 그라운드 룰이 무엇인지를 결정할 필요가 있다.어떤것이 맞는것인지 어떤것이 틀린것인지에 대한 원칙은 없지만, SW-FMEA를 수행함에 있어(1) 어떤 고장을 고려할 것인지,(2) 어떤 종류의 고장을 포함할 것인지,(3) 고장 허용 수준은 어느정도로 할 것인지 등의 정보를 사전에 고려해야만 한다. SW FMEA Ground Rules (Example)특정 레벨에 대한 모든 고장들이 식별되어야 한다. (SW FMEA의 범위 식별)가령 컴포넌트 레벨에 대한 모든 고장을 식별한다든지 또는 서브 시스템의 모든 고장 혹은 소프트웨어 레벨의 모든 고장을 식별할 것인지를 결정해야 한다.특정 레벨에서 어떤 고장이 존재하는지가 식별되어야 한다. (잠재 고장 모드 식별)소프트웨어가 의도된 기능.. 더보기 Software Isolation During the Software Refactoring 최근 3~4년간 시간들을 돌이켜보면 소프트웨어 관련 기술들을 실무에 적용하기 위해 상당한 시간을 들였던 것으로 기억합니다. 소프트웨어를 개발하는 조직에서 소프트웨어 엔지니어로 살기 위해 여러 케이스를 고려한 나름의 노력이었는데, 안타깝지만 성과는 크지 않았던 것이 현실이었습니다.이런 무성과? 저성과?의 이유를 생각해 보면, 결국 조직적 이슈였던거 같은데 지속적으로 소프트웨어를 개발하고 유지보수하는 업무를 단순화 그리고 효율화하기 위한 노력이 왜 조직적 이슈로 인해 무산(?) 되었을까.. 그리고 무엇이 이러한 조직적 이슈를 야기시키고 있는 것일까 생각해 봅니다. 결국 생각해보면, "소프트웨어에 새로운 기능이 요구되고, 시간이 지남에 따라 복잡해지고 (예를 들어 불필요한 종속성, 중복되거나 강하게 결합된 기.. 더보기 Software Safety Analysis (MIL-HDBK-338B) 시스템 안전성 분석의 주요 목적은 기능적 요구사항과 연관된 안전성을 시스템이나 장비, 설비, 이들간의 인터페이스 설계에 안전 요구사항을 추가/고려하는 것이다. MIL-HDBK-338B (Electronic Reliability Design Handbook)에는 안전성이 자세하게 언급되어 있는데 다음과 같은 지침을 제공하고 있다. 시스템 위험을 식별하기 위한 안전성 프로그램을 구현하고, 개발할 수 있는 가이드 위험 요소를 제거함으로써 사고를 막거나 허용할 수 있는 수준의 활동을 관리하여 관련된 위험을 축소 시킬 수 있는 설계 요구사항과 관리 및 통제에 대한 가이드 Terminologies of Safety Fail Safe A design feature that either ensures that the .. 더보기 소프트웨어 신뢰성 관련 용어 정리 여기서 소개하는 소프트웨어 신뢰성 관련 용어는 TTA (Telecommunications Technology Association)의 "정보통신용어사전"과 소프트웨어 품질 및 신뢰성 관련 표준을 기반으로 정의하였으며, 그외 IEEE 표준을 참조 하였음을 밝힌다. 고장 (Failure) 필요한 기능을 수행하는 어떤 요소의 기능 종료 혹은 미리 지정된 제한 시간 내에서의 수행 불능 상태 결점 (Defect) 고장을 야기하는 버그 또는 문제점을 의미하며, 예를 들어 리뷰를 통해 발견하지 못한 사항으로 인해 소프트웨어의 고장을 야기하게 되면 이들을 결점이라고 한다. 오류 (Error) 결과적으로 결함이 포함된 소프트웨어를 만든 사람의 행위, 예를 들면 소프트웨어 명세시 사용자 요구사항을 누락하거나 잘못 해석한 .. 더보기 Definition of Software Reliability 소프트웨어 신뢰성에 대한 정의는 정의를 내리는 사람 또는 기관에 따라 약간씩 다르게 정의되고 있다. 먼저 1992년 미국의 AIAA (American Institute of Aeronautics and Astronautics)의 정의에 따르면, "The ability of a system or component to perform its required functions under stated conditions for a specified period of time." (특정 시간 동안 정해진 환경 조건하에서 요구되는 기능을 수행하기 위한 시스템 또는 컴포넌트들의 능력) (by ANS/AIAA R-013-1992) 로 되어 있다. 최근 새롭게 정의된 개념은 소프트웨어 시험(테스팅)에 보다 중점을 둔 개.. 더보기 Software Reliability Engineering 소프트웨어 신뢰성 공학은 매우 중요한 품질 특성중의 하나인 신뢰성을 다루고 있다. 품질 틀성에는 신뢰성 이외에도 기능성, 사용성, 성능, 유지 보수성 등과 같은 여 러 다른 특성들을 포함하고 있지만, 신뢰성은 인명 손실과 막대한 재산 피해를 일으킬 수 있는 소프트웨어 고장을 정량화하기 때문에 특히 중요하게 생각되어진다. 실제로 많은 경우, 소프트웨어 신뢰성은 전체 시스템 신뢰성의 병목 지역으로 작용하고, 보통 소프트웨어 완성도는 하드웨어의 완성도보다 떨어진다. 그러므로 시스템 전체의 신뢰성을 높이기 위해서는 하드웨어 신뢰성도 중요하지만, 소프트웨어 신뢰성은 특히 주의깊게 관리되어야 한다. 소프트웨어 신뢰성 공학에 대한 정의는 "신뢰성에 관한 사용자 요구사항을 가진 소프트웨어 시스템의 운용에 대한 정량적인.. 더보기 Software Reliability Engineering Process 소프트웨어 신뢰성 공학 프로세스는 소프트웨어의 신뢰도를 측정하고 그것을 기반으로 사용자가 만족하는 제품을 알맞은 시간에 정해진 비용 한도 내에서 소프트웨어 제품을 생산할 수 있게 하는 활동의 절차를 이야기한다. 소프트웨어 신뢰성 공학의 대표적인 전문가인 J. D. Musa와 Michael R. Lyu는 다음과 같은 프로세스 모델을 제시하였다. Musa가 제시한 소프트웨어 신뢰성 공학 프로세스는 6가지의 활동으로 이루어졌다. 제품 정의 활동 운영 프로파일 (Operational Profile) 작성 활동 "Just Right" 신뢰성 활동 시험 준비 활동 시험 실행 활동 결함 정보 분석 활동 [J. D. Musa가 제안한 소프트웨어 신뢰성 공학 프로세스] 제품 정의 활동은 제품의 공급자, 고객, 사용자뿐만.. 더보기 Software Reliability Measurement Process 소프트웨어 신뢰성 측정 프로세스는 크게 두 부분으로 구성된다. 신뢰성에 영향을 미치는 프로세스의 특성, 산출물의 특성을 나타내는 측정치와 시험 단계에서 나오는 결함 정보를 수집하는 과정 수집된 정보를 분석하여 현재의 신뢰성과 미래의 신뢰성를 추정 및 예측하는 과정 1. 정보 수집 프레임 워크 소프트웨어 신뢰성 공학을 적용할 때에 프로젝트에 대해 너무 자세한 정보를 모두 유지하려는 생각은 버려야한다. 많은 사람들이 정확하게 정의된 정보 수집의 목적을 알지 못하는 경우가 많다. 그 결과, 노력에 비해서 얻어지는 이익은 미비한 경우가 많이 발생하게 된다. 어떤 조직에서는 얻어진 정보를 분석하는 능력을 고려하지 않은 채 정보 수집에 많은 자원을 투입한다. 이런 이득 없이 낭비되는 시간 및 인력은 제품 개발 기간.. 더보기 이전 1 2 다음
