20장 - 소프트웨어 품질

Edited by / 임수형 (sulogc)

이 장에서는 구현 관점에서 소프트웨어 품질과 관련된 기법을 설명한다.

20-1 소프트웨어 품질의 특성

소프트웨어 품질의 특성은 외적인 품질 특성과 내적인 품질 특성을 모두 갖고 있다.

외적 특성은 사용자 관점에서 소프트웨어가 정확하게 작동하고 사용하기 쉬운지에 관심을 둔다.
내적 특성은 개발자 관점에서 소프트웨어가 읽고 변경하기 쉬운지 구조가 좋은지에 관심을 둔다. 물론 개발자는 외적 특성 또한 고려한다.

a. 외적 품질 특성

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

b. 내적 품질 특성

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

어떤 수준에서는 내적인 특성이 외적인 특성에 영향을 미친다. 특성들이 어떻게 상호작용하는지 이해하는 것이 중요하다. 유지보수성이 정확성과 신뢰성에, 유연성이 사용성에 영향을 준다. 정확성(정확한 상황만 수용)은 내구성(예상치 못할 때도 작동)과 트레이드 오프 관계가 될 수 있다. 다음은 소프트웨어 품질 특성간 전형적인 관계를 나타낸다. 절대적이지는 않다.

20-2 소프트웨어 품질을 향상시키기 위한 기법들

소프트웨어 품질 보증은 시스템의 특성이 바람직한지를 보장하기 위해 설계된 체계적인 활동 프로그램이다. 소프트웨어 품질 보증에는 소프트웻어 개발 프로세스에 초점을 맞추어야 한다.

a. 소프트웨어 품질 향상 프로그램의 몇 가지 요소

소프트웨어 품질의 목표 : 소프트웨어 품질 특성 중 중점적인 특성을 정한다.
명확한 품질 보증 활동 : 품질이 부차적인 목표가 아닌 우선순위로 설정해야한다.
테스트 전략 : 물론 테스트만으로 부족하지만 제품의 신뢰성에 대한 상세한 평가를 제공할 수 있다.
소프트웨어 공학 가이드라인 : 소프트웨어의 기술적 특성을 관리하는 가이드라인을 설계한다. 이 책에서 소개하는 가이드라인들은 구현에 적용할 수 있는 소프트웨어 공학 가이드라인의 모음이다.
비형식적인 기술적 검토 : 책상에서 검사하거나 동료와 함께 코드를 살펴보는 방법.
절차를 따르는 기술적 검토 : 소프트웨어 공학 프로세스 관리 작업의 하나는 최저 비용 단계에서 문제를 찾는 것이다. 이를 위해 요구사항 분석에서 아키텍처, 아키텍처에서 구현, 구현에서 시스템 테스트로 넘어가기에 충분하지 품질 관문을 두어야 한다. 관문이라해서 완벽을 요하는 것은 아니고 특정 요구사항 정도에 충분한지만을 판단한다.
외부 감사

b. 개발 프로세스

이전 요소는 명시적으로 소프트웨어 품질 보증과 관련이 되어있고, 암시적으로 소프트웨어 개발 프로세스와 관련이 있다.

변경 관리 과정 : 통제 되지 않은 변경은 내부 모순을 초래하거나, 설계와 코드 작성에 혼란을 줄 수 있다. 변경을 효과적으로 관리하는 것이 높은 품질을 유지하는 지름길이다.
결과 측정 : 폼질 보증 계획을 통해 계획 성공, 실패에 따라 프로세스가 어떻게 향상될 수 있는지 조정된 방법을 제시 가능하다. 더불어 품질 특성 자체를 측정 가능하다.
프로토타이핑 : 프로토타이핑은 시스템의 핵심 기능에 대한 실질적인 모델을 개발하는 것이다. 사용성을 위해 사용자 인터페이스의 일부, 수행 시간 결정을 위해 핵심적이 부분을 계산, 필요 메모리 크기 결정을 위해 데이터 집합을 프로토타이핑 할 수 있다.

목표 설정

매일 변경되거나 실행 불가능한 목표에는 개발자가 응할 수 없지만, 품질 목표를 명확하게 설정하는 것은 고품질 소프트웨어 작성이 가능하다. 제럴드 와인버그와 에드워드 슐만은 품질 목표 설정이 개발자의 수행 능력에 미치는 영향을 조사하는 실험을 수행했다. 목표를 다르게 제시하여 진행된 실험의 결과로, 사람들이 실제로 자기에게 주어진 일을 한다는 점, 일반적으로 목표가 상충하여 모든 목표에 대해 잘하기란 불가능 하다는 점을 파악할 수 있다.

20-3 품질 향상 기법의 상대적 효과성

다양한 품질 보증 습관이 모두 같은 효과가 있지는 않다. 많은 기법들은 결함을 발견하고 제거하는 데 효과가 있고, 효과에 대한 여러 측면을 설명한다.

a. 발견된 결함의 비용

프로젝트에 존재하는 전체 결함의 수를 기준으로 특정 기법을 사용해 발견한 결함의 비율을 계산하여 결함 감지 기법을 평가 할 수 있다.

프로젝트 개발자가 더 높은 비율로 결함을 감지하고 싶다면 여러 기법을 조합하여 사용해야 한다. 글렌포드 마이어스는 연구를 통해 두 가지 기법을 조합해 사용할 때 발견하는 전체 경함의 수가 거의 2배로 증가함을 보였다.

b. 결함 발견 비용

결함 감지 기법은 결함 감지당 최소 비용을 계산하여 비용을 비교할 수 있다. 대부분의 연구에서 정밀 검토가 테스트보다 비용이 저렴하다는 사실을 발견했다. 코드를 읽는 것이 테스트하는 것보다 시간당 약 80%의 결함을 더 발견한다는 것을 알아냈다.

c. 결함 수정 비용

결함 발견 비용은 비용 방정식의 한 부분일 뿐이다. 결함 수정 비용도 결함 발견 비용에 포함된다. 결함 감지 기법에 따라 오류를 발견하는 시점이 달라지기 때문에 결함 수정 비용이 달라진다. 또한 테스트 같은 기법은 증상은 찾아내지만 결함의 원인을 진단하고 수정하는 별도의 단계로 인해 비용이 더 발생한다. 다음은 평균 이상의 품질을 얻기 위해서 추천할 만한 조합이다.

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

20-4 품질 보증 활동 시기

3장 선행조건에서 말한 바와 같이 소프트웨어에 오류가 더 일찍 삽입될수록 소프트웨어의 다른 부분과 더 많이 얽히고 오류를 제거하는 데 더 큰 비용이 든다. 연쇄적인 오류는 큰 비용을 초래하므로 요구사항과 아키텍처에 있는 오류를 잡아내는 것이 좋다.

20-5 소프트웨어 품질의 일반적인 원칙

소프트웨어 품질의 일반적인 원칙은 품질의 향상으로 개발 비용을 줄일 수 있다는 것이다. 대부분의 프로젝트에서 가장 큰 활동은 정상적으로 작동하지 않는 코드를 디버깅하고 수정하는 것이다. 디버깅과 리팩터링, 다른 수정 작업이 전형적인 소프트웨어 개발 주기에서 약 50% 정도의 시간을 차지한다. 오류를 예방하여 디버깅을 줄이면 생산성이 향상된다.

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

다음 1985년에 진행된 한 연구에서 166명의 전문 개발자들이 같은 명세로 프로그램을 작성했다. 작성된 프로그램의 평균 코드 길이는 200줄, 작성 시간은 5시간 이었다. 흥미로운 사실은 평균 시간이 걸린 개발자들이 오류가 가장 많은 프로그램을 작성했다는 사실이다.

이는 결함이 없는 소프트웨어를 작성하는 것이 결함이 있는 소프트웨어를 작성하는 것보다 더 많은 시간이 걸리는 것은 아니다는 것을 보여준다. 이어지는 세 단원에서 소프트웨어 품질의 일반적인 원칙에 대한 더 많은 예를 보게 될 것이다.