Archive for the ‘Fact and Fallacies of Software Engineering’ tag
소프트웨어 공학의 사실과 오해 9 – 품질
http://www.yes24.com/24/goods/1418676
품질
소프트웨어 분야에서 품질이란 좋은 품질의 소프트웨어 제품이 가져야하는 7개의 속성의 집합을 말한다. 이 집합은 이식성(portability), 신뢰성(reliability), 효율(efficiency), 사용 편의성(usability), 테스트 용이성(testability), 이해 용이성(understandability), 수정 용이성(modifiability)으로 구성된다.
p.233
사실 여기 나오는 속성 7개가 중요하다기 보다는 품질이란 여러 가지 속성의 집합이라는 사실이 요점인 것 같다.
이 속성에 우선순위를 매기는 것은 불가능하다. 즉, 소프트웨어 품질 속성을 모두 만족시키기 위한 시도에서 일반적인, 올바른 순서는 없는 것이다. 그러나 이 말이 속성에 순서를 매기면 안 된다는 뜻은 아니다. 어떤 프로젝트든 시작할 때부터 이 속성에 우선순위를 정해두는 것은 매우 중요하다.
p.234
이 일은 정말 중요하다! 그렇지 않으면 모두가 자기만의 우선순위를 가지고 개발을 하게 되므로 어떤 사람이 봤을 때는 좋은 코드인데 다른 사람이 봤을 때는 나쁜 코드가 될 수 있다. 리드 프로그래머와 같이 전체 품질에 책임을 지는 사람이 품질 속성에 우선순위를 매겨서 모두가 합의하게 되면, 매번 설계할 때마다 고민할 일도 줄어들고, 피어 리뷰에서 싸우는 일도 줄어들게 된다.
품질은 사용자 만족, 요구사항 충족, 비용과 일정 목표 달성, 또는 신뢰성이 아니다.
p.238
사용자 만족 = 요구사항 충족 + 납기일 준수 + 적절한 비용 + 좋은 품질의 제품
p.238
사용자 만족의 정의에서 볼 수 있듯이 사용자 만족, 요구사항 충족, 비용과 일정 목표 달성은 품질에 속하는 것이 아니다. 신뢰성 역시 품질의 한 가지 속성일 뿐인데, 신뢰성(오류 존재 여부)만을 품질이라고 생각하는 사람도 있다.
이런 개념이 정리되어 있지 않으면 “사용자가 만족하지 못하니 품질이 나쁜 것”이라고 단정하는 실수를 하기 쉽다.
오류는 항상 남아 있다. 심각한 오류를 제거하거나 최소화하는 것이 목표가 돼야 한다. (…) 심각한 오류는 반드시 소프트웨어 에서 제거돼야 한다. 다른 오류도 모두 제거하면 좋겠지만(예를 들면 문서화 오류, 중복된 코드 오류, 도달할 수 없는 경로 오류, 알고리즘에서 무시할 수 있을 정도의 수치상 오류 등), 항상 그럴 필요는 없다.
p.248
개인적으로 “리펙토링할 코드는 항상 남아 있다.”는 생각을 가지고 있는데, 이런 생각은 100% 완벽한 코드를 만들려는 강박관념을 없애주고, 좋지 못한 코드를 발견했을 때 “아, 이 소스코드는 엉망진창이군. 대충 필요한 코드나 추가해야지.”라고 생각하기 보다는, “소스코드란 영원히 부족한 법이지. 우선 이부분만 리펙토링 해볼까.”라고 생각하도록 도와준다.
얼마나 많은 사람들이 제품의 품질을 관리 쪽 책임이라 믿든, 소프트웨어 품질이란 주제에는 기술적 요소가 너무 많아 이를 관리만의 책임으로 미룰 수는 없다는 것이 내 대답이었다. 그리고는 거의 모든 품질 속성이 기술자만이 해결할 수 있는 상당히 기술적인 면을 갖고 있다는 것을 지적했다.
p.281
경영진은 ‘품질 제일’과 같은 슬로건을 걸고 ‘총체적 품질 관리(TQM, Total Quality Management)’와 같은 방법론을 사용하는 것이 소프트웨어 제품의 품질 달성을 위한 주요 접근방법이라 생각하는 것 같다. (…) 경영진은 한 손에는 동기부여와 방법론을 들고 다른 쪽 손에는 일정 압박이란 반 품질적 요소를 적용하려 한다. 두 가지를 모두 하는 것은 불가능하고, 대부분의 기술자들도 이를 알 만큼은 똑똑하다.
p.281, 282