내 머리속 지우개

일반적으로 소프트웨어 측도는 규모 측도, 복잡도 측도, 품질 측도, 사용 품질 측도와 같이 구분될 수 있다. (이는 절대적인 것은 아니고, 다양한 구분이 존재하고 있으나, 여기서는 일부만을 간략히 소개한다.) 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 ..