성능분석 및 품질평가

목차

1.성능 분석
2.성능 저하 원인 분석
3.소스 코드 품질 분석 도구
4.소프트웨어 유지 보수
5.소프트웨어 품질 평가

---

1.성능 분석

1-1. 성능 측정 지표

1. 처리량(Throughput): 정해진 시간에 처리할수 있는 연산, 트랜잭션의 수
2. 응답시간(Response Time): 명령이 입력된 후 응답 출력이 개시될때 까지의 시간
3. 반환시간(Turnaround Time): 사용자가 데이터 및 명령을 입력한 시점부터 트랜잭션 처리후 결과의 출력이 완료할때 까지 걸리는 시간
4. 자원사용률(Resource Usage): 트랜잭션을 처리하는 동안 사용하는 CPU사용량, 메모리 사용량, 네트워크 사용량

1-2. 성능 분석 도구

1. 성능(Performance) 점검 도구
    * 시스템의 최대한 부하(Load)를 걸어 스트레스(Stress) 줌으로써 각 성능 측정지표의 최대값을 구할수있는 도구
2. 성능감시(Monitoring) 도구
    * 특정 프로그램 실행시 자원의 사용량을 실시간 또는 주기적으로 확인하고 분석하는 도구

---

2.성능 저하 원인 분석

2-1. 데이터베이스의 성능저하 원인

1. 데이터베이스 잠금(Lock)
    * 대량의 데이터조회, 과도한 갱신, 무분별한 인덱스 생성시 성능이 저하
2. 불필요한 데이터베이스 패치(Fetch)
    * 필요한 데이터보다 많은 대량의 데이터 요청이 들어올 경우 성능이 저하
3. 연결누수(Leak) / 부적절한 연결 풀 크기(Pool Size)
    * 연결 누수는 데이터베이스 연결과 관련한 JDBC 객체를 사용후 종료하지 않을 경우 발생
4. 불안전한 완료(Commit)
    * 트랜잭션이 확정되지 않고 연결 풀에 반환되는 경우 성능이 저하된다

2-2. 소프트웨어 내부 로직의 성능 저하 원인

1. 웹 애플리케이션의 인터넷 접속 불량
2. 특정 파일의 업로드, 다운로드로 인한 성능 저하
3. 정상적으로 처리되지 않은 오류 처리로 인한 성능 저하

2-3. 외부 호출로 인한 성능 저하 원인

* 임의의 트랜잭션이 수행되는 동안 외부 호출이 장시간 수행되거나, 타임아웃이 일어나는 경우 성능이 저하된다

2-4. 시스템 환경의 성능 저하 원인

1. 환경 설정으로 인한 성능 저하
    * 스레드 풀, 힙 메모리의 크기를 너무 작게 설정하면 Heap Memory Full 현상 발생으로 성능 저하
2. 네트워크 장비로 인한 성능 저하
    * 라우터, 스위치등 네트워크 관련 장비간 데이터 전송 실패시 성능이 저하된다

---

3.소스 코드 품질 분석 도구

3-1. 소스코드 최적화

1. 소스코드의 최적화의 개념
    * 코드의 구조를 개선하여 성능을 개선하는 모든 활동
    * 나쁜코드를 찾아서 읽기 쉽고 개선이 쉬운 클린코드를 작성
    * 프로그래밍 언어의 이해를 바탕으로 소스품질 분석도구를 활용
    * 소스코드는 지속적으로 변경되므로 최적화 역시 지속적으로 진행해야 한다
2. Clean Code
    * 중복을 최소화한 가독성이 좋고 단순한 코드
    * 로직의 이해가 빠르고 수정속도가 빨라진다
    * 오류를 찾기 용이하고 유지보수 비용이 낮아진다
3. Bad Code
    * 로직을 이해하기 어렵게 작성된 스파게티 코드
    * 변수, 함수 등의 이름으로 그 역할을 한번에 이해하기 어려운 코드
    * 서로 다른 코드로 같은 기능을 수행하는 코드
    * 소스코드 이해가 어려워 유지보수 비용이 높아지는 코드
4. 클린 코드 작성 원칙
    * 가독성: 이해하기 쉬운 식별자, 명령어를 사용
    * 단순성: 기능을 최소단위로 분리하여 하나의 기능만 수행하도록 프로그래밍
    * 의존성 배제: 수정된 코드가 다른코드에 영향이 없도록 결합도를 최소화
    * 중복성 제거: 중복된 코드를 제거
    * 추상화: 각 기능들의 공통된 부분을 재사용 모듈로 구성

3-2. 코드 품질 향상 기법

1. 테스트(Test): 가장 일반적인 코드 검증 방법
2. 코드 인스펙션(Code Inspection): 코드에 존재하는 결함을 확인하는 검사
3. 정적분석(Static Analysis): 프로그램을 실행하지 않고 코드 구조를 분석하는 도구
4. 동적분석(Dynamic Analysis): 프로그램을 실행하여 결과를 분석하는 도구
5. 증명(Proof): 소프트웨어 품질이 아주 중요한 경우에 활용되는 가장 이상적인 방법

3-3. 리팩토링(Refactoring)

* 코드의 기능 자체는 바뀌지 않은 상태에서 구조를 개선하는것
* 완성된 코드의 구조를 좀 더 안정되게 설계하는 기술
* 소프트웨어의 디자인을 개선하여 가독성을 높인다

3-4. 정적 분석 지원 도구

* 작성한 소스 코드를 실행하지 않고 코딩 표준이나 스타일, 결함등을 확인하는 도구
- pmd: Java 및 다른 언어의 버그와 데드코드를 분석하는 도구
- cppcheck: C/C++ 에 대한 결함 및 오류를 분석하는 도구
- SonarQube: 소스코드의 품질을 체크하는 통합 플랫폼 도구
- checkstyle: Java 코드의 표준준수 여부를 분석하는 도구

3-5. 동적 분석 지원 도구

* 작성한 소스크도를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함등을 분석하는 도구
- Avalanche: 프로그램의 결함 및 취약점을 분석하는 도구
- valgrind: 메모리누수, 쓰레드 결함등을 분석하는 도구

---

4.소프트웨어 유지보수

4-1. 소프트웨어 유지보수의 종류

1. 하자보수(수리보수, Corrective maintenance)
    * 소프트웨어 버스나 잠재적 오류의 원인을 찾아 정상적으로 작동되도록 하는 복구 작업
2. 기능개션(완전보수, Perfective maintenance)
    * 소프트웨어 유지보수의 비용 분포중 가장 많은 부분을 차지하는 보수로 성능의 문제를 수정, 보완하여 좋은 소프트웨어 유지
3. 환경적응(적응보수, Adaptive maintenance)
    * 소프트웨어 수명기간 중에 발생하는 환경의 변화를 기존의 소프트웨어에 반영하기 위하여 수행하는 활동의 보수
4. 예비조치(예방보수, Preventive maintenance)
    * 사용자의 요구를 미리 예측하여 준비하는 활동

4-2. 소프트웨어 유지보수가 어려운 경우

* 표준화되지 않은 주관적으로 작성된 소프트웨어인 경우
* 오래 전(15년 이상)에 개발되어 개발자나 문서가 없는 경우

4-3. 문서화의 필요성

* 시스템 개발자 이외의 사람에게 쉽게 시스템을 이해시킬수 있어야 한다
* 문서는 개발자, 사용자 모두에게 필요하며 다른 프로그램 개발에 필요한 지침서로 사용
* 문서를 통한 효율적인 의사소통을 위해 표준화를 진행

4-4. 유지보수 비용 측정 방법

1. BL(belady와 lehman)방법
2. COCOMO(Constructive Cost Model)방법
3. Vessey & Webber 방법

4-5. 소프트웨어 유지보수 부작용

1. 코딩의 부작용: 코딩 내용의 변경으로 인하여 발생하는 부작용
2. 데이터 부작용: 자료구조 변경으로 인하여 발생하는 부작용
3. 문서 부작용: 자료코드에 대한 변경이 설계 문서나 사용자가 사용하는 메뉴얼에 적용되지 않을때 발생하는 부작용

---

5.소프트웨어 품질 평가

5-1. 소프트웨어 품질 목표 항목

1. 정확성(Correctness)
2. 신뢰성(Reliability)
3. 효율성(Efficiency)
4. 무결성(Integrity)
5. 유지보수 용이성(Maintainability)
6. 사용 용이성(Usability)
7. 검사 용이성(Testability)
8. 이식성(Portability)
9. 상호 운용성(Interoperability)
10. 유연성(Flexibility)
11. 재사용성(Reusability)

5-2. 소프트웨어 신뢰성 측정

* 소프트웨어 신뢰성은 주어진 시간동안 주어진 환경에서 프로그램이 고장없이 운영될 확률
* 소프트웨어 신뢰성은 과거의 데이터와 개발시점의 데이터를 사용해서 측정되고, 예측될수 있다
* 소프트웨어 실패는 설계또는 구현상의 문제로 발생

참고자료 : 이기적 환상콤비 정보처리기사