•
구현 관점에서 소프트웨어 품질과 관련된 주요 개념들을 설명한다. 품질과 품질 보증 자체를 중점으로 다루며 실무 중심의 기법보단 전반적인 관점에서 품질과 관련된 내용을 다룬다.
소프트웨어 품질의 특성
•
소포트웨어는 외적인 품질과 내적인 품질로 나뉜다.
•
외적인 특성은 소프트웨어 제품의 사용자가 느끼는 특성들을 의미하며 다음과 같다.
◦
정확성: 시스템의 사양과 설계, 구현에 오류가 없는 정도
◦
사용성: 사용자가 시스템을 배우고 사용하는 데 있어서의 용이함
◦
효율성: 메모리와 실행 시간 같은 시스템 리소스의 사용의 효율성
◦
신뢰성: 특정 상황에서 언제든지 필요한 기능을 수행할 수 있는 시스템의 능력과 고장 사이의 시간
◦
무결성: 시스템이 프로그램이나 데이터에 대해 허용되지 않거나 잘못된 접근을 막는 정도
▪
여기엔 적절한 데이터 접근을 보장하는 것뿐만 아니라 권한이 없는 사용자의 접근 제한도 포함된다.
◦
적응성: 시스템을 변경하지 않고 설계된 환경뿐만 아니라 다른 응용 프로그램이나 환경에서 사용될 수 있는 정도
◦
정밀성: 양적 결과 면에서 구성된 시스템에 오류가 없는 정도
◦
견고성: 시스템이 잘못된 입력이나 악조건같은 엣지 케이스 등에서도 기능을 계속해서 수행할 수 있는 정도
•
내적인 특성은 프로그램 내적인 품질을 의미하며 구현에 가까운 프로그래머라는 특성상 이에 더 중점을 둔다.
◦
유지보수성: 소프트웨어 시스템의 기능을 변경, 추가, 향상, 수정 등 변경할 때의 편의성
◦
유연성: 시스템이 설계된 환경이 아닌 다른 목적이나 다른 환경으로 변경할 수 있는 정도
◦
이식성: 시스템이 설계된 환경이 아닌 다른 환경에서 작동할 수 있도록 시스템을 변경할 때의 편의성
◦
재사용성: 시스템의 일부분을 다른 시스템에서 사용할 수 있는 정도나 편의성
◦
가독성: 시스템의 소스코드를 구체적인 명령문 수준에서 읽고 이해할 때의 편의성
◦
테스트 용이성: 시스템을 단위 테스트나 시스템 테스트할 수 있는 정도, 시스템이 요구사항을 충족하는지 검증할 수 있는지에 대한 정도
◦
이해 용이성: 시스템 구성과 코드 수준에서 시스템을 이해할 때의 편의성
•
어떤 수준에서 내적인 특성이 외적인 특성에 영향을 미치기도 하므로 내적인 특성와 외적인 특성 사이의 차이가 완전히 분명하지는 않다.
◦
가독성, 유지보수성이 낮은 경우 결함 수정에 영향을 미치므로 정확성과 신뢰성으로 이어진다.
•
일반적으로 어떤 특성을 중시하는 경우, 다른 특성을 약화시키게되는 상충 관계가 존재하듯이, 외적인 품질 특성에도 이러한 관계가 존재한다.
•
서로 상충하는 목적과 결과 사이에서 가장 바람직한 방법을 찾는 것은 현재 상황을 명확하게 인식하고 목적을 명확하게 하는 것이다.
2. 소프트웨어의 품질을 향상시키기 위한 기법
•
소프트웨어 품질의 목표
◦
외적인 특성과 내적인 특성 중 명확한 품질의 기준이 되는 목표를 설정하는 것이다.
◦
명확한 목표를 설정하지 않으면 개발자가 예상과 다른 특성을 최대화하기 위해 작업할 수도 있다.
•
명확한 품질 보증 활동
◦
품질 보증에 있어서 보편적인 문제 중 하나는 품질이 부가적인 목표로 인식되는 것이다.
▪
실제로 어떤 조직에서는 품질보다 빠르게 처리하는 것을 미덕으로 여긴다.
◦
품질이 중요함을 이해하고 특정 목표를 세우고 달성하기 위해 노력해야 한다.
•
테스트 전략
◦
테스트 수행은 제품의 신뢰성에 대한 상세한 피드백이 가능하다.
•
소프트웨어 공학 가이드라인
◦
가이드라인은 개발 당시 소프트웨어의 기술적인 특성을 관리한다. 문제 정의, 요구사항 개발, 아키텍처, 구현, 시스템 테스트를 포함한 모든 소프트웨어 개발 활동에 적용된다.
•
비형식적인 기술적 리뷰
◦
많은 소프트웨어 개발자는 형식적인 리뷰 전에 자신이 작업한 내용을 리뷰한다.
◦
비형식적인 리뷰에는 설계나 코드를 책상에서 검사하거나 동료와 함께 코드를 살펴보는 방법이 포함된다.
•
절차를 따르는 기술적 검토
◦
소프트웨어 공학적으로 프로젝트를 접근했을때, 프로세스 관리 작업 중 하나는 투자 비용과 문제 해결 비용이 가장 적은 시기인 최저 비용 단계에 문제를 찾는 것이다.
◦
이를 위해 개발자들은 품질 관문, 주기적인 테스트 리뷰를 통해 제품의 품질을 유지한다.
개발 프로세스
•
변경 관리 과정
◦
통제되지 않은 변경은 설계와 코드 작성에 혼란을 줄 수 있다.
◦
변경을 효과적으로 관리하는 것이 높은 품질을 유지하는 지름길이다.
•
결과 측정
◦
품질 보증 계획의 결과를 측정하지 않는다면 계획대로 되고 있는지 확인하지 못하고 피드백도 불가하다.
◦
측정은 계획이 성공인지, 실패인지를 알려주고 프로세스가 어떻게 향상될 수 있는지 알 수 있게 조정된 방법으로 프로세스를 변경할 수 있게 해준다.
•
프로토타이핑
◦
시스템의 핵심 기능에 대한 실질적인 모델을 개발하는 것이다.
목표 설정
•
품질 목표를 명확하게 설정하는 것은 고품질 소프트웨어를 작성하기 위한 가장 간단하고 명확한 과정이다.
3. 품질 향상 기법의 상대적 효과성
•
품질 향상 기법의 효과에 대한 여러 측면을 설명한다.
발견된 결함의 비율
•
기법들에 따라 결함을 발견하는 효율도 다르고 찾아내는 결함의 종류도 다르다.
•
결함 감지 기법을 판단하는 한 가지 방법은 프로젝트에 그 당시 존재하는 전체 결함의 수를 기준으로 이 기법을 사용해 발견한 결함의 비율을 계산하는 것이다.
제거 단계 | 최하 비율 | 최빈수 비율 | 최고 비율 |
비형식적 설계 검토 | 25% | 35% | 40% |
형식적 설계 정밀 검토 | 45% | 55% | 65% |
비형식적 코드 검토 | 20% | 25% | 35% |
형식적 코드 정밀 검토 | 45% | 60% | 70% |
모델링 또는 프로토타이핑 | 35% | 65% | 80% |
코드에 대한 개인 검사 | 20% | 40% | 60% |
단위 테스트 | 15% | 30% | 50% |
컴포넌트 테스트 | 20% | 30% | 35% |
통합 테스트 | 25% | 35% | 40% |
회귀 테스트 | 15% | 25% | 30% |
시스템 테스트 | 25% | 40% | 55% |
소량 베타 테스트 | 25% | 35% | 40% |
대량 베타 테스트 | 60% | 75% | 85% |
•
이 표를 보면 개발자들이 더 높은 비율로 결함을 감지하고 싶다면 여러 기법들을 조합하여 사용해야 함을 알 수 있다.
•
결론적으로 결함 감지 기법은 단독으로 사용했을 때보다 함께 사용할 때 더 좋은 결과를 가져온다.
◦
존스는 단위 테스트와 기능 테스트, 시스템 테스트를 조합해 사용하면 종종 60% 이하의 결함 감지 효율을 가져오는데 부적당하다고 지적했다.
•
익스트림 프로그래밍에서 사용되는 일련의 결함 제거 기법은 결함 제거 효율이 평균 90%에서 최고 97%에 이른다.
◦
비형식적인 설계 검토(페어 프로그래밍), 비형식적인 코드 검토(페어 프로그래밍), 코드에 대한 개인 탁상 검사, 단위 테스트, 통합 테스트, 회귀 테스트
결함 발견 비용
•
어떤 결함 감지 기법은 다른 감지 기법에 비해 효과가 더 좋듯이, 비용이 더 들기도 한다.
•
가장 경제적인 기법을 사용하면 다른 조건이 모두 같은 경우에 결함 감지당 최소 비용이 든다.
•
대부분의 연구에서 정밀 검토가 테스트보다 비용이 저렴하다는 사실을 발견했다.
◦
소프트웨어 공학 연구소가 실시한 한 연구에서 코드를 읽는 것이 테스트하는 것보다 시간 당 약 80%의 결함을 더 발견한다는 것을 알아냈다.
•
정밀 검토를 수행하고 테스트를 수행하자..
결함 수정 비용
•
오류를 초기에 찾아내는 감지 기법이 결과적으로 더 낮은 수정 비용이 든다.
◦
결함 감지 같은 기법들은 결함의 증상과 원인을 한 번에 발견하지만 테스트같은 기법들은 증상은 찾아내지만 결함의 원인을 진단하고 수정하기 위한 별도의 작업을 거쳐야 한다.
•
효과적인 소프트웨어 품질 향상 프로그램에는 개발의 전 과정에 적용되는 기법들을 조합해 사요해야 한다. 다음은 평균 이상의 품질을 얻기 위해서 추천할 만한 조합이다.
◦
모든 요구사항, 아키텍처, 시스템의 주요 부분의 설계에 대한 형식적인 정밀 검토
◦
모델링이나 프로토타이핑
◦
코드 리뷰와 정밀 검토
◦
수행 테스트
4. 품질 보증 활동 시기
•
소프트웨어에 오류가 더 일찍 추가될수록 소프트웨어의 다른 부분과 더 많이 얽히고 오류를 제거하는 데 더 큰 비용이 든다.
◦
요구사항에서의 결함을 설계에서 하나 이상의 결함을 만들고 코드에서는 수많은 오류를 만들 수 있다.
◦
요구사항의 오류는 추가적인 아키텍처나 잘못된 아키텍처 선택으로 이어질 수 있다.
•
결함은 소프트웨어의 모든 단계에 숨어드는데, 초기 단계에서뿐만 아니라 프로젝트의 나머지 전반적으로 품질 보증 작업을 수행해야 한다.
◦
작업을 시작할 때, 품질 보증 작업이 계획에 포함되어 있어야 하고 작업을 진행 중일 때는 기술적 특성의 한 부분이어야 하며 작업이 끝날 대는 제품의 품질을 검증하여 마무리해야 한다.
5. 소프트웨어 품질의 일반적인 원칙
•
소프트웨어 품질의 일반적인 원칙은 품질의 향상으로 개발 비용을 줄일 수 있다는 것이다.
•
생산성과 품질을 향상시키기 위한 가장 좋은 방법은 수정 작업이 요구사항의 변경이나 설계상의 변경인지에 상관없이 코드를 다시 작성하는 데 걸리는 시간을 줄이느 것이다.
•
대부분의 프로젝트에서 가장 큰 활동은 정상적으로 작동하지 않는 코드를 디버깅하고 수정하는 것이다.
◦
디버깅과 리팩토링, 다른 수정 작업이 전형적인 소프트웨어 개발 주기에서 약 50% 정도의 시간을 차지한다.
•
이는 곧 오류를 예방하여 디버깅을 줄이면 생산성이 향상된다는 의미다. 따라서 개발 일정을 줄이는 가장 확실한 방법은 처음부터 천천히 안전하게 가는 것이다.
요점 정리
•
결함을 비싸게 고치는 대신 저렴하게 예방하기 위해서 품질을 확보하는 데에도 비용을 충분히 들이는 것이 중요하다.
•
품질 보증과 관련된 모든 목표를 동시에 달성할 수는 없다. 달성하고자 하는 목표를 분명히 결정하고 결정된 목표를 팀원들과 공유하여 일관된 상태를 유지하라.
•
어떠한 단일 결함 감지 기법도 그 자체만으로는 완벽하지 않다. 성공적인 품질 보증 프로그램은 서로 다른 오류를 발견하기 위해 다양한 기법을 활용하라.
•
구현 중에 효과적인 기법을 적용할 수 있고, 구현 전에도 강력한 기법들을 적용할 수 있다. 결함을 초기에 발견할수록 수정 비용을 줄일 수 있다.
•
소프트웨어의 품질 보증은 프로세스 지향적이다. 소프트웨어 개발은 제조업과 같이 최종 제품에 영향을 미치는 일련의 단계가 없다. 따라서 결과물의 품질은 소프트웨어를 개발하는 데 사용되는 모든 프로세스에서 관리해야 한다.
