내 머리속 지우개

여기서 소개하는 소프트웨어 신뢰성 관련 용어는 TTA (Telecommunications Technology Association)의 "정보통신용어사전"과 소프트웨어 품질 및 신뢰성 관련 표준을 기반으로 정의하였으며, 그외 IEEE 표준을 참조 하였음을 밝힌다. 고장 (Failure) 필요한 기능을 수행하는 어떤 요소의 기능 종료 혹은 미리 지정된 제한 시간 내에서의 수행 불능 상태 결점 (Defect) 고장을 야기하는 버그 또는 문제점을 의미하며, 예를 들어 리뷰를 통해 발견하지 못한 사항으로 인해 소프트웨어의 고장을 야기하게 되면 이들을 결점이라고 한다. 오류 (Error) 결과적으로 결함이 포함된 소프트웨어를 만든 사람의 행위, 예를 들면 소프트웨어 명세시 사용자 요구사항을 누락하거나 잘못 해석한 ..

소프트웨어 신뢰성 공학은 매우 중요한 품질 특성중의 하나인 신뢰성을 다루고 있다. 품질 틀성에는 신뢰성 이외에도 기능성, 사용성, 성능, 유지 보수성 등과 같은 여 러 다른 특성들을 포함하고 있지만, 신뢰성은 인명 손실과 막대한 재산 피해를 일으킬 수 있는 소프트웨어 고장을 정량화하기 때문에 특히 중요하게 생각되어진다. 실제로 많은 경우, 소프트웨어 신뢰성은 전체 시스템 신뢰성의 병목 지역으로 작용하고, 보통 소프트웨어 완성도는 하드웨어의 완성도보다 떨어진다. 그러므로 시스템 전체의 신뢰성을 높이기 위해서는 하드웨어 신뢰성도 중요하지만, 소프트웨어 신뢰성은 특히 주의깊게 관리되어야 한다. 소프트웨어 신뢰성 공학에 대한 정의는 "신뢰성에 관한 사용자 요구사항을 가진 소프트웨어 시스템의 운용에 대한 정량적인..

소프트웨어 신뢰성 공학 프로세스는 소프트웨어의 신뢰도를 측정하고 그것을 기반으로 사용자가 만족하는 제품을 알맞은 시간에 정해진 비용 한도 내에서 소프트웨어 제품을 생산할 수 있게 하는 활동의 절차를 이야기한다. 소프트웨어 신뢰성 공학의 대표적인 전문가인 J. D. Musa와 Michael R. Lyu는 다음과 같은 프로세스 모델을 제시하였다. Musa가 제시한 소프트웨어 신뢰성 공학 프로세스는 6가지의 활동으로 이루어졌다. 제품 정의 활동 운영 프로파일 (Operational Profile) 작성 활동 "Just Right" 신뢰성 활동 시험 준비 활동 시험 실행 활동 결함 정보 분석 활동 [J. D. Musa가 제안한 소프트웨어 신뢰성 공학 프로세스] 제품 정의 활동은 제품의 공급자, 고객, 사용자뿐만..

소프트웨어 신뢰성 측정 프로세스는 크게 두 부분으로 구성된다. 신뢰성에 영향을 미치는 프로세스의 특성, 산출물의 특성을 나타내는 측정치와 시험 단계에서 나오는 결함 정보를 수집하는 과정 수집된 정보를 분석하여 현재의 신뢰성과 미래의 신뢰성를 추정 및 예측하는 과정 1. 정보 수집 프레임 워크 소프트웨어 신뢰성 공학을 적용할 때에 프로젝트에 대해 너무 자세한 정보를 모두 유지하려는 생각은 버려야한다. 많은 사람들이 정확하게 정의된 정보 수집의 목적을 알지 못하는 경우가 많다. 그 결과, 노력에 비해서 얻어지는 이익은 미비한 경우가 많이 발생하게 된다. 어떤 조직에서는 얻어진 정보를 분석하는 능력을 고려하지 않은 채 정보 수집에 많은 자원을 투입한다. 이런 이득 없이 낭비되는 시간 및 인력은 제품 개발 기간..

일반적으로 소프트웨어 측도는 규모 측도, 복잡도 측도, 품질 측도, 사용 품질 측도와 같이 구분될 수 있다. (이는 절대적인 것은 아니고, 다양한 구분이 존재하고 있으나, 여기서는 일부만을 간략히 소개한다.) 1. 규모 측도 LOC (Line Of Code) 크기 중심의 소프트웨어 측정 기준으로 직접 소프트웨어 코드의 라인수를 측정하는 방식이다. (이것이 수작업으로 이루어지지 않는다는 것은 모두 알고 있으리라 생각됨..) 기능점수 소프트웨어의 크기를 결정하는 소프트웨어 기능 유형별 수량과 성능 및 품질 영향도를 고려하여 계산되는 수치로, 기능 점수 요소들은 소프트웨어 정보 영역의 가산적 척도들과 소프트웨어 복잡성에 대한 주관적인 측정을 기초로 한 실험, 관찰에 의한 관계성을 이용하여 유도된다. Bang ..

문득 나도 글을 잘 쓰고 싶다는 생각이 들었다. 사실 글을 잘 쓰고 싶다기 보다는 말을 잘 하고 싶다는 생각이 먼저였다. 그래서 생각과 생각이 꼬리에 꼬리를 물다보니 글을 잘 쓰고 싶다는 생각에 도달했고, 예전에 읽었던 유시민 작가님의 "유시민의 글쓰기 특강" 이란 책이 생각나서 한번 곱씹으며 정리해 보고자 글을 쓴다. 말을 하고 글을 쓸 때 단순한 취향 고백과 논증해야 할 주장을 분명하게 구별해야 한다. 이것이 논증의 미학을 구현하는 첫번째 규칙이다. 블로그, 페이스북, 밴드, 카카오톡, 동호회 게시판, 업무혁신보고회, 학술세미나, 논술시험, 어떤 매체에 어떤 목적으로 어떤 성격의 글을 쓰든 이 규칙을 지켜야 한다. 너무 당연한 말인듯 한데, 다시 읽어 보니 마음에 와 닿는다. 때론 사람들과 이야기를 ..

사실 요구사항 재사용이란 말은 아주 유용해 보이지만, 실제로 요구사항을 재사용함으로써 얻을 수 있는 장점은 그리 크지 않다고 생각한다. 특히 자체개발 조직에서 요구사항의 재사용은 애자일 프로세스를 도입하는 경우 거의 무용지물이 된다고 볼 수 있으며 또한 개발 성숙도가 낮은 조직에서의 요구사항 재사용은 사실상 요구사항을 신규로 작성하는 것의 생산성과 비교 했을때 큰 차이가 없다고 생각한다. (물론 개인적 생각이다.) 나름의 근거를 대자면, 1. 자체 개발 조직에서의 요구사항 재사용 문제점 자체 개발 조직은 요구사항과 설계, 그리고 모델로 이어지는 프로세스가 애자일로 돌아가야 하는 상황에 놓이기 쉽다. 이는 자체개발 조직의 목적과도 부합된다고 볼 수 있는데, 예를 들면, 외주 개발로 소프트웨어 개발이 이루어..

인터넷을 하다가, 우연히 글을 보게 되었다. 잊지 않고 싶어서 적어 본다. 한 사람을 만나고, 그래서 그 사람이 마음에 들어 오고 비단 연애의 감정을 떠나, 새로운 직장, 모임 속에서 새로운 관계를 만들어 가다보면 그렇게 또 사람을 만나고, 마음에 들어 오고, 때론 누군가의 마음으로부터 떠나기도 하고... 남는건 그리고 중요한건 나 자신 요즘 넋나간 사람처럼 지내고 있는 스스로가 안타깝다. 방문객 - 정현종 사람이 온다는 건 실은 어마어마한 일이다 그는 그의 과거와 현재와 그리고 그의 미래가 함께 오기 때문이다. 한 사람의 일생이 오기 때문이다. 부서지기 쉬운 그래서 부서지기도 했을 마음이 오는 것이다 그 갈피를 아마 바람은 더듬어 볼 수 있을 마음 내 마음이 그런 바람을 흉내낸다면 필경 환대가 될 것이다

COQ (Cost Of Quality) 란? 고객이 제품을 사용하는데 결함이 없다는 것(Defect-Free)을 보증하는데 드는 비용 초기 품질 보증을 위한 예방 및 평가 비용 이외에 결함을 보완하기 위한 재작업(Rework)/복구(Repair) 등의 모든 활동을 포함하는 비용 보이지 않는 비용들에 대한 고찰이 필수적 COPQ에 대한 오해 COPQ는 프로세스 내의 오직 결함(Defect)과 관련된 비용 외부 실패로 발생한 부가적 비용 제외 COPQ만을 통해 제품 품질 보증 가능 소프트웨어 품질 관련 비용 - COGQ (Cost Of Good Quality) 프로세스 개선을 위한 비용 Consulting, Quality Planning, 프로젝트 개발 방법 설정, 데이터베이스 계획, Standards와 요..

시스템 안전성 분석의 주요 목적은 기능적 요구사항과 연관된 안전성을 시스템이나 장비, 설비, 이들간의 인터페이스 설계에 안전 요구사항을 추가/고려하는 것이다. MIL-HDBK-338B (Electronic Reliability Design Handbook)에는 안전성이 자세하게 언급되어 있는데 다음과 같은 지침을 제공하고 있다. 시스템 위험을 식별하기 위한 안전성 프로그램을 구현하고, 개발할 수 있는 가이드 위험 요소를 제거함으로써 사고를 막거나 허용할 수 있는 수준의 활동을 관리하여 관련된 위험을 축소 시킬 수 있는 설계 요구사항과 관리 및 통제에 대한 가이드 Terminologies of Safety Fail Safe A design feature that either ensures that the ..