20장: 소프트웨어 품질

20장 소프트웨어 품질

내용

• 20.1 소프트웨어 품질의 특성
• 20.2 소프트웨어 품질을 향상시키기 위한 기법들
• 20.3 품질 향상 기법의 상대적 효과성
• 20.4 품질 보증 활동 시기
• 20.5 소프트웨어 품질의 일반적인 원칙

관련 주제

• 협력 구현: 21장
• 개발자 테스트: 22장
• 디버깅: 23장
• 구현 선행 조건: 3장과 4장

• 선행 조건이 최신 소프트웨어 프로젝트에도 적용되는가?: 3.1절

• 이 장에서는 구현 관점에서 소프트웨어 품질과 관련된 기법을 설명한다. 실무 중심의 기법보다는 전반적인 관점에서 품질과 관련된 내용을 다룬다.

20.1 소프트웨어 품질의 특성

• 소프트웨어는 외적인 품질 특성과 내적인 품질 특성을 모두 갖고 있다. 외적인 특성은 소프트웨어 제품의 사용자가 느끼는 다음과 같은 특성을 말한다.

• 정확성(correctness) 시스템의 사양과 설계, 구현에 오류가 없는 정도
• 사용성(usability) 사용자가 시스템을 배우고 사용하는 데 있어서의 용이함
• 효율성(efficiency) 메모리와 실행 시간 같은 시스템 리소스의 최소 사용
• 신뢰성(reliability) 정해진 상황에서 언제든지 필요한 기능을 수행할 수 있는 시스템의 능력. 고장 사이의 시간
• 무결성(integrity) 시스템이 프로그램이나 데이터에 대해 허용되지 않거나 잘못된 접근을 막는 정도.
• 적응성(adaptability) 시스템을 변경하지 않고 설계된 환경뿐만 아니라 다른 응용 프로그램이나 환경에서 사용될 수 있는 정도
• 정밀성(accuracy) 특히 양적 결과 면에서 구성된 시스템에 오류가 없는 정도. 정밀성은 정확성과 다르다.

• 견고성(robustness) 시스템이 잘못된 입력이나 악조건에서도 기능을 계속해서 수행할 수 있는 정도

• 몇 가지 특성은 의미가 겹치기도 하지만, 모든 특성이 상황에 따라 다른 특성에 비해 더 많이 적용되거나 적용되지 않는 식의 의미상 차이가 있다.

• 품질의 외적인 특성은 사용자가 관심을 두는 유일한 소프트웨어의 특성이다.

• 개발자는 외적인 특성뿐만 아니라 내적인 특성에도 관심을 둔다. 이 책은 코드를 중점적으로 다루기 때문에 다음과 같이 품질의 내적인 특성에 중점을 둔다.

• 유지보수성(maintainability) 소프트웨어 시스템의 기능을 변경하거나 기능을 추가하거나 성능을 향상시키거나 결함을 수정하기 위해 시스템을 변경할 때의 편의성
• 유연성(flexibility) 시스템이 설계된 환경이 아닌 다른 목적이나 환경으로 변경할 수 있는 정도
• 이식성(portability) 시스템이 설계된 환경이 아닌 다른 환경에서 작동할 수 있도록 시스템을 변경할 때의 편의성
• 재사용성(reusability) 시스템의 일부분을 다른 시스템에서 사용할 수 있는 정도나 편의성
• 가독성(readability) 시스템의 소스코드를 상세한 명령문 수준에서 읽고 이해할 때의 편의성
• 테스트 용이성(testability) 시스템을 단위 테스트나 시스템 테스트할 수 있는 정도. 시스템이 요구사항을 충족하는지 검증할 수 있는지에 대한 정도

• 이해 용이성(understandability) 시스템 구성과 코드 수준에서 시스템을 이해할 때의 편의성. 이해 용이성은 가독성보다 더 일반적인 수준에서 시스템의 일관성과 관련되어 있다.

• 품질의 외적인 특성처럼 몇 가지 내적인 특성들은 의미가 겹치지만 이 특성들 역시 가치를 두고 있는 부분이 서로 다르다.

• 시스템 품질의 내적인 특성은 이 책에서 전반적으로 설명하고 있으므로 이 장에서는 더는 설명하지 않는다.

• 어떤 수준에서는 내적인 특성이 외적인 특성에 영향을 미치기 때문에 내적인 특성과 외적인 특성 사이의 차이가 완전히 분명하지는 않다.

• 어떤 특성만 부각시키려고 하면 분명히 다른 특성을 부각시키려는 시도와 충돌하게 되어 있다. 이러한 관계는 소프트웨어 품질의 내적인 특성 사이에서도 발견할 수 있다.

그림 20-1 소프트웨어 품질의 외적인 특성에 초점을 맞추면 다른 특성에 미치는 영향

(긍정적: ↑, 부정적: ↓)

• 이 표에서 가장 흥미로운 부분은 어떤 특성에 초점을 맞추는 것이 항상 다른 특성과의 트레이드오프를 의미하지는 않는다는 점이다.

• 이 표는 품질 특성들 사이의 전형적인 관계만을 보여준다. 어떤 프로젝트에서는 두 특성이 전형적인 관계와 다른 관계를 맺을 수도 있다.

20.2 소프트웨어의 품질을 향상시키기 위한 기법

• 소프트웨어 품질 보증은 시스템의 특성이 바람직한지를 보장하기 위해서 설계된 계획적이고 체계적인 활동 프로그램이다. 소프트웨어의 품질 향상 프로그램의 몇 가지 요소를 다음과 같이 소개하고자 한다.

• 소프트웨어 품질의 목표 소프트웨어의 품질을 향상시키는 가장 강력한 기법은 앞에서 설명한 외적인 특성과 내적인 특성 중에서 명확한 품질의 목표를 설정하는 것이다.

• 명확한 품질 보증 활동 품질 보증에 있어서 한 가지 일반적인 문제는 품질이 부차적인 목표로 인식되는 것이다.

• 테스트 전략 테스트 수행은 제품의 신뢰성에 대한 상세한 평가를 제공할 수 있다. 이 장의 나머지 부분은 테스트만으로 모든 것을 감당하기에는 너무나 부담이 크다는 것을 상세하게 보여준다.

• 소프트웨어 공학 가이드라인 가이드라인은 개발 당시 소프트웨어의 기술적인 특성을 관리해야 한다. 어떤 면에서 보면 이 책에서 소개하는 가이드라인들은 구현에 적용할 수 있는 소프트웨어 공학 가이드라인의 모음이다.

• 비형식적인 기술적 검토 많은 소프트웨어 개발자는 형식적인 검토 단계 전에 자신이 작업한 내용을 검토한다. 비형식적인 검토에는 설계나 코드를 책상에서 검사하거나 동료와 함께 코드를 살펴보는 방법이 포함된다.

• 절차를 따르는 기술적 검토 소프트웨어 공학 프로세스 관리 작업의 하나는 투자 비용과 문제 해결 비용이 가장 적은 시기인 “최저 비용” 단계에서 문제를 찾는 것이다. “관문”은 정밀 검토, 동료 검토, 고객 검토, 감사가 될 수 있다.

• “관문”은 아키텍처나 요구사항이 100% 완벽하지 않으면 안 된다는 것을 의미하는 것이 아니라, 요구사항이나 아키텍처가 실제 코드 개발을 진행할 수 있을 정도로 충분한지 결정하기 위한 관문으로 사용할 것이라는 뜻이다. 여기서 “충분”하다는 것은 요구사항이나 아키텍처의 가장 핵심적인 20%를 설명했는지 의미하거나 프로젝트의 고유한 특성에 따라서 목표로 하는 규모의 95%를 명시했는지를 의미한다.

• 외부 감사 외부 감사는 개발 중인 프로젝트의 상태나 제품의 품질을 결정하기 위해서 사용되는 특정한 형태의 기술적 검토다. 감사팀은 외부 조직으로부터 구성하고 감사 결과는 감사를 의뢰한 사람, 일반적으로 경영진에게 보고한다.

• 개발 프로세스 지금까지 언급한 요소는 명시적으로 소프트웨어의 품질 보증과 관련되어 있고 암시적으로 소프트웨어 개발 프로세스와 관련이 있다. 명시적으로는 품질 보증 활동이 아닌 다른 프로세스도 소프트웨어의 품질에 영향을 미친다.

• 변경 관리 과정 소프트웨어 품질을 유지하는 데 있어서 한 가지 큰 걸림돌은 통제되지 않은 변경이다. 변경의 본질적인 결과가 품질을 불안정하게 만들고 떨어뜨리는 것이기 때문에 변경을 효과적으로 관리하는 것이 높은 품질을 유지하는 지름길이다.

• 결과 측정 품질 보증 계획의 결과를 측정하지 않는다면 계획대로 되고 있는지 알지 못할 것이다. 품질 특성의 측정에 대한 자세한 내용은 (Gilb 1988)의 9장을 살펴본다.

• 프로토타이핑(prototyping) 프로토타이핑은 시스템의 핵심 기능에 대한 실질적인 모델을 개발하는 것이다. 비교 결과, 프로토타이핑이 설계와 사용자 요구에 대한 부합성 면에서 더 좋고 유지보수성도 향상되었음이 드러났다(Gordon and Bieman 1991).

목표 설정

• 품질 목표를 명확하게 설정하면 개발자는 합리적이고 일관된 목표를 실제 작업의 우선순위로 삼는다.

• 와인버그와 슐만은 다섯 팀에 서로 다른 품질 목표를 최적화하도록 지시하고 수행 결과를 비교했다(Weinberg and Schulman 1974).

표 20-1 목표에 대한 팀 순위

출처: “Goals and Performance in Computer Programming” (Weinberg and Schulman 1974)

• 이 연구의 결과는 주목할 만했다. 다섯 팀 중 네 팀이 최적화하도록 지시받은 목표를 가장 먼저 끝냈다. 다른 한 팀은 지시받은 목표를 두 번째로 끝냈다. 어떤 팀도 모든 목표를 일관되게 잘하지는 못했다.

• 이 놀라운 결과의 의미는 사람들이 실제로 자기에게 주어진 일을 한다는 점이다. 개발자는 높은 성취동기를 갖고 있다.

20.3 품질 향상 기법의 상대적 효과성

• 다양한 품질 보증 습관이 모두 같은 효과가 있지는 않다. 여기서 품질 보증의 “효과”에 대한 여러 가지 측면을 설명한다.

발견된 결함의 비율

• 어떤 방법은 다른 방법보다 결함을 잘 발견하고 방법에 따라 찾아내는 결함의 종류도 다르다.

표 20-2 결함 감지 비율

출처: 《Programming Productivity》(Jones 1986a), 《Software Defect-Removal Efficiency》(Jones 1996), 《What We Have Learned About Fighting Defects》(Shull et al. 2002)

• 이 데이터가 보여주는 가장 흥미로운 사실은 한 가지 기법을 사용해서는 최빈수 비율이 75%를 넘지 않는다는 것과 기법의 평균이 약 40%라는 것이다. 선진 조직은 다양한 기법을 광범위하게 사용하여 95% 이상의 결함 제거 비율을 달성하고 있다(Jones 2000).

• 이 표를 보면 프로젝트 개발자가 더 높은 비율로 결함을 감지하고 싶다면 여러 기법을 조합하여 사용해야 한다는 것을 알 수 있다. 글렌포드 마이어스의 연구는 이러한 사실을 뒷받침하고 있다(Myers 1978b).

• 명세에 대한 실행 테스트
• 소스코드가 있는 명세에 대한 실행 테스트

• 명세와 소스코드를 이용한 검토와 정밀 검토

• 마이어스는 프로그램에서 발견된 결함의 수가 1.0부터 9.0까지 매우 다양하다는 것을 발견하였다. 발견한 평균 결함 수는 5.1개였고, 알려진 결함의 약 1/3이었다.

• 이 기법을 개별적으로 사용했을 때는 어느 기법도 다른 기법에 비해 통계적으로 큰 이점이 없었다. 발견된 버그가 겹치는 경우는 20% 정도였다(Kouchakdjian, Green, and Basili 1989; Tripp, Struck, and Pflug 1991; Schneider, Martin, and Tsai 1992).

• 글렌포드 마이어스는 인간의 처리 과정(예: 정밀 검토와 검토)은 특정한 종류의 오류를 찾는 데 컴퓨터 기반의 테스트보다 우수한 경향이 있고 다른 오류에서는 그 반대의 경우도 있다고 지적했다(Myers 1979).

• 결론적으로 결함 감지 기법들은 단독으로 사용했을 때보다 함께 사용할 때 더 좋은 결과를 가져온다. 존스는 단위 테스트와 기능 테스트, 시스템 테스트를 조합해 사용하면 종종 60% 이하의 결함 감지 효율을 가져오는데, 이는 판매되는 소프트웨어로서는 부적당하다고 지적했다.

• 또한 이 데이터는 익스트림 프로그래밍과 같은 결함 제거 기법으로 작업을 시작한 사람들이 그렇지 않은 사람들보다 결함 제거 수준이 뛰어난 이유를 이해하는 데도 사용될 수 있다. 다른 조합도 이와 비슷하거나 더 나은 결과를 가져올 수 있으며 원하는 품질 수준을 달성하기 위해서 어떤 결함 제거 방법을 선택할지 결정하는 것도 효과적인 프로젝트 계획 수립에 속한다.

표 20-3 익스트림 프로그래밍의 예상 결함 감지 비율

• 대부분의 연구에서 정밀 검토가 테스트보다 비용이 저렴하다는 사실을 발견했다. IBM의 연구에서는 코드 정밀 검토를 사용할 때는 각 오류를 찾는 데 3.5시간이면 되지만, 테스트를 통해서 각 오류를 찾는 데는 15.25시간이 필요하다는 것을 발견했다(Kaplan 1995).

결함 수정 비용

• 결함 발견 비용은 비용 방정식의 한 부분일 뿐이다. 그 방정식에는 결함 수정 비용도 들어간다. 얼핏 보면 결함을 발견하는 방법에 상관없이 수정 비용은 항상 같은 것처럼 보일 것이다.

• 결함이 시스템에 남아있는 시간이 길면 길수록 제거하는 데 더 큰 비용이 들기 때문에 실제로는 그렇지 않다. 따라서 오류를 초기에 찾아내는 감지 기법이 결과적으로 더 낮은 수정 비용이 든다.

• 마이크로소프트의 애플리케이션 부서는 한 단계 기법인 코드 결함 감지를 사용하면 결함을 찾아서 수정하는 데 3시간이 걸리지만, 두 단계 기법인 테스트를 사용하면 12시간이 걸린다는 사실을 알아냈다(Moore 1992). 그들은 코드 검토가 테스트보다 비용 효과가 여러 배 크다는 사실을 발견했다(1.38 대 0.17).

• 결론적으로 효과적인 소프트웨어 품질 향상 프로그램에는 개발의 전 과정에 적용되는 기법들을 조합해 사용해야 한다. 다음은 평균 이상의 품질을 얻기 위해서 추천할 만한 조합이다.

• 모든 요구사항, 모든 아키텍처, 시스템의 주요 부분의 설계에 대한 형식적인 정밀 검토
• 모델링이나 프로토타이핑
• 코드 읽기나 정밀 검토
• 수행 테스트

20.4 품질 보증 활동 시기

• 3장(“준비는 철저하게: 선행조건”)에서 말한 것처럼 소프트웨어에 오류가 더 일찍 삽입될수록 소프트웨어의 다른 부분과 더 많이 얽히고 오류를 제거하는 데 더 큰 비용이 든다. 콘크리트로 기반을 만들기 전에 설계도에서 결함을 해결하는 것이 좋은 생각인 것처럼 나중의 활동에 영향을 미치기 전에 요구사항과 아키텍처에 있는 오류를 잡아내는 것이 좋다.

• 게다가 요구사항이나 아키텍처에 있는 오류는 구현 오류보다 제거하기 쉬운 경향이 있다.

• 결함은 소프트웨어의 모든 단계에 몰래 스며든다. 그것이 작업을 시작할 때 프로젝트의 계획에 포함되어 있어야 하고 작업을 진행 중일 때는 기술적 특성의 한 부분이어야 하며 작업이 끝날 때는 제품의 품질을 검증하여 프로젝트의 끝을 마무리해야 한다.

20.5 소프트웨어 품질의 일반적인 원칙

• 이 세상에 공짜 점심과 같은 것은 없다. 소프트웨어 품질의 일반적인 원칙은 품질의 향상으로 개발 비용을 줄일 수 있다는 것이다.

• 이 원칙을 이해할 수 있느냐는 다음의 핵심적인 내용을 이해하느냐에 달려있다. 생산성과 품질을 향상시키기 위한 가장 좋은 방법은 수정 작업이 요구사항의 변경이나 설계상 변경, 아니면 디버깅으로 인한 것인지에 상관없이 코드를 다시 작성하는 데 걸리는 시간을 줄이는 것이다.

• 이렇게 생산성이 낮아 보이는 이유는 업계 평균값을 낼 때 개발자가 아닌 사람들이 하루에 작성하는 코드 줄 수도 계산하기 때문이다. 하지만 이런 작업은 그렇게 많은 시간을 차지하지 않는다.

• 대부분의 프로젝트에서 가장 큰 활동은 정상적으로 작동하지 않는 코드를 디버깅하고 수정하는 것이다. 따라서 개발 일정을 줄이는 가장 확실한 방법은 제품의 품질을 향상시키고 디버깅과 소프트웨어의 수정 작업으로 낭비되는 시간을 줄이는 것이다.

• 이러한 분석은 현장 데이터에 의해서 뒷받침된다. 400시간 이상의 노력과 300만 줄의 코드를 포함하는 50개의 개발 프로젝트를 검토한 NASA의 소프트웨어 공학 연구소의 한 연구에서는 품질 보증의 향상이 오류율은 줄여주지만, 전체적인 개발 비용을 증가시키지는 않는다는 것을 발견했다(Card 1987).

• IBM의 연구에서도 이와 유사한 결과가 나왔다.

• 결함 수준이 매우 낮은 소프트웨어 프로젝트는 개발 일정도 가장 짧고 생산성이 가장 높았다. 소프트웨어 결함 제거가 실제로 소프트웨어 개발에 있어서 가장 큰 비용을 유발하고 가장 많은 시간을 낭비하는 작업 형태다(Jones 2000).

• 같은 효과가 더 작은 규모에서도 발생한다. 1985년에 진행된 한 연구에서 166명의 전문 개발자들이 같은 명세로 프로그램을 작성했다.

그림 20-2 개발 접근 방법에 따른 평균 결함 수

• 너무 빠르지도 너무 느리지도 않은 개발 접근 방법이 가장 결함이 많은 소프트웨어를 만든다. (DeMarco and Lister 1985)

• 가장 느린 두 그룹은 가장 빠른 그룹에 비해 약 다섯 배의 시간이 더 걸렸지만 대략 같은 수의 결함을 가진 프로그램을 작성했다.

• 누구나 다 알고 있듯이 특정 종류의 프로젝트에서는 품질 보증에 비용이 든다. 우주선이나 의료용 생명 유지 시스템에 사용할 코드를 작성하고 있다면 요구되는 신뢰도가 프로젝트를 비싸게 만든다.

• 전형적인 코드-테스트-디버깅 과정보다 개선된 소프트웨어 품질 프로그램을 사용하면 비용이 절약된다.

체크리스트: 품질 보증 계획

• 프로젝트에 중요한 품질 특성을 확인했는가?
• 다른 사람들에게 프로젝트 품질의 목표를 설명했는가?
• 외적인 품질 특성과 내적인 품질 특성을 구분했는가?
• 어떤 특성이 다른 특성과 어떻게 경쟁하고 보완하는지에 대해 생각해 봤는가?
• 프로젝트에서 다양한 종류의 오류를 발견하는 데 적합한 여러 가지 오류 감지 기법을 사용해야 하는가?
• 프로젝트가 소프트웨어 개발의 각 단계에서 소프트웨어의 품질을 보증하기 위한 과정을 적용할 계획을 하고 있는가?
• 품질이 개선되거나 낙후되는지 알 수 있도록 어떤 식으로든 품질을 측정하는가?
• 경영진이 품질 보증에는 나중의 비용 절감을 위해서 초기에 추가 비용이 발생한다는 사실을 이해하고 있는가?

참고 자료

• 사실상 효과적인 소프트웨어 방법론을 다루는 모든 책이 품질과 생산성을 향상시키는 기법을 설명하고 있기 때문에 이 분야와 관련된 서적을 소개하는 것은 어렵지 않다.

• 프랭크 기낙(Frank Ginac) 《Customer Oriented Software Quality Assurance》(Prentice Hall, 1998). 이 책은 품질의 특성, 품질의 척도, QA 프로그램, 품질에서 테스트의 역할, 품질 향상 프로그램, 소프트웨어 공학 연구소(Software Engineering Institute)의 CMM과 ISO 9000에 관해서 설명하는 매우 간결한 책이다.
• 윌리엄 루이스(William Lewis) 《Software Testing and Continuous Quality Improvement》 2판(Auerbach Publications 2000).

관련 표준

• IEEE Std 730-2002, IEEE Standard for Software Quality Assurance Plans.
• IEEE Std 1061-1998, IEEE Standard for a Software Quality Metrics Methodology.
• IEEE Std 1028-1997, Standard for Software Reviews.
• IEEE Std 1008-1987 (R1993), Standard for Software Unit Testing.
• IEEE Std 829-1998, Standard for Software Test Documentation.

요점 정리

• 따지고 보면 품질은 무료지만, 결함을 비싸게 고치는 대신 저렴하게 예방하기 위해서 자원의 재분배가 요구된다.
• 품질 보증과 관련된 모든 목표를 동시에 달성할 수는 없다. 달성하고자 하는 목표를 분명히 결정하고 결정된 목표를 팀원들과 공유하라.
• 어떠한 단일 결함 감지 기법도 그 자체만으로는 완벽하게 효과적이지 않다. 성공적인 품질 보증 프로그램은 서로 다른 오류를 발견하기 위해 다양한 기법을 사용한다.
• 구현 중에 효과적인 기법을 적용할 수 있고 구현 전에도 마찬가지로 여러 가지 강력한 기법을 적용할 수 있다. 결함을 초기에 발견할수록 소스코드의 나머지 부분에 미치는 영향도 적고 피해도 작을 것이다.
• 소프트웨어의 품질 보증은 프로세스 지향적이다. 소프트웨어 개발은 제조업과 같이 최종 제품에 영향을 미치는 반복적인 단계가 없다. 따라서 결과물의 품질은 소프트웨어를 개발하는 데 사용되는 프로세스로 관리해야 한다.