정보처리기사/소프트웨어 개발
애플리케이션 테스트 관리 10
RangA
2023. 5. 24. 00:10
성능 분석 및 품질 평가
04. 소프트웨어 유지보수
1) 소프트웨어 유지보수의 종류
- 하자 보수(Corrective maintenance, 수리 보수)
- 소프트웨어 버그나 잠재적 오류의 원인을 찾아 정상적으로 가동되도록 하는 보수 작업
- 기능 개선(Perfective maintenance, 완전 보수)
- 소프트웨어 유지보수의 비용 분포 중 가장 많은 부분을 차지하는 보수로 성능의 문제를 수정, 보완하여 최상의 소프트웨어로 유지하게 함
- 새로운 성능과 기능에 맞게 요구사항을 충족할 수 있도록 개선하는 작업
- 환경 적응(Adaptive maintenance, 적응 보수)
- 소프트웨어 수명 기간 중에 발생하는 환경의 변화를 기존의 소프트웨어에 반영하기 위하여 수행하는 활동의 보수
- 예비 조치(Preventive maintenance, 예방 보수)
- 사용자의 요구를 미리 예측하여 준비하는 활동
2) 소프트웨어 유지보수가 어려운 경우
- 주관적으로 작성된 소프트웨어인 경우
- 표준화되지 않은 소프트웨어인 경우
- 유지보수를 염두에 두지 않은 소프트웨어인 경우
- 개발자가 없는 경우
- 문서가 없는 경우
- 15년 전에 개발된 소프트웨어인 경우(외계인 코드)
- 유지보수가 어려울 뿐이지 불가능한 것은 아님
3) 외계인 코드(Alien Code)
- 외계인 코드를 간단히 정의하면 15년 이전에 개발된 소스 코드로 정의할 수 있음
- 아주 오래되었거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램을 의미
- 대부분 개발할 때 문서화를 하지 않았거나 개발자가 없거나 비구조적으로 작성한 경우를 말함
- 외계인 코드는 유지보수를 상당히 어렵게 만드는 문제점 중의 하나이고 이러한 문제를 최소화하기 위해서는 유지보수를 고려한 표준화된 기술 사용과 문서화를 철저하게 해 두어야 함
4) 문서화
- 프로그램 내용을 보기에 앞서 문서를 통해 시스템에 대해 쉽게 이해할 수 있음
- 시스템 개발자 이외의 사람에게 쉽게 시스템을 이해시킬 수 있어야 함
- 문서가 없으면 시스템의 유지보수가 어려움
- 문서는 개발자, 사용자에게 모두 필요함
- 문서는 보고서 기능을 할 수 있도록 함
- 다른 프로그램을 작성하기 위한 지침서로도 사용할 수 있도록 함
- 표준화를 통해 통일성 있게 프로그래밍할 수 있도록 함
- 표준화는 문서화의 기본 목적 중의 하나인 효율적인 의사소통을 위하여 가장 크게 고려해야할 사항
5) 유지보수 비용 측정 방법
- BL 방법(Belady와 Lehman에 의해서 제안한 방법)
- M = P + K * E(c - d)
- M : 유지보수를 위한 노력(인원/월)
- P : 생산적인 활동에 드는 비용(개발 비용)
- K : 통곗값에 구한 상수(주관적 평가)
- 과거에 개발한 경험이 있는가를 주관적으로 평가하는 수치
- 1 ~ 10이 있다면 경험이 전혀 없으면 10, 경험이 많이 있다면 1값을 줌
- c : 복잡도
- d : 소프트웨어에 대한 지식 정도(주관적 평가)
- COCOMO 방법
- M = ACT * DE * EAF
- M : 유지보수를 위한 노력(인원/월)
- ACT : 유지보수 비율
- 한 해 동안 원시 코드 한 줄에 가해지는 변경 횟수 또는 유지보수 비율
- DE : 생산적인 활동에 드는 비용(개발 비용)
- 개발 시 투입된 노력 또는 생산적인 활동에 드는 비용
- EAF : 노력 조정 수치(주관적인 평가)
- 유지보수작업을 위한 보정 노력 또는 노력 조정 수치
6) 소프트웨어의 유지보수 부작용
- 코딩의 부작용
- 부프로그램이 삭제되거나 수정되었을 경우
- 구문 페이블이 삭제되거나 수정되었을 경우
- 확인자가 삭제되거나 수정되었을 경우
- 파일을 OPEN하고 CLOSE하지 않는 경우
- 논리 연산자가 삭제되거나 수정되었을 경우
- 설계 수정 후 코드를 변경하지 않았을 경우
- 데이터 부작용
- 지역 상수 및 전역 상수를 재정의할 경우
- 레코드 구조를 변경할 경우
- 배열의 크기를 변경할 경우
- 플래그 변수를 수정할 경우
- 포인터 변수를 수정할 경우
- 프로그램의 매개 변수를 수정할 경우
- 문서 부작용
- 원시 코드는 변경하고 문서를 변경하지 않았을 경우
05. 소프트웨어 품질 평가
1) 품질 보증(QA : Quality Assurance)
1. 품질 보증의 개념
- 어떤 항목이나 제품에 설정된 기술적인 요구사항과 일치하는가를 적절하게 확인하는 데 필요한 체계적이고도 계획적인 유형의 활동
2. 품질 보증 활동(SQA)
- 소프트웨어 엔지니어들은 실질적인 기술적 방법과 측정을 적용해서 정형화된 기술 검토(FRT)와 잘 계획된 검사를 수행해서 품질을 설명하고 품질 보증을 수행함
- SQA의 궁극적인 목적은 소프트웨어 품질 향상
3. 구체적인 품질 보증 활동
- 소프트웨어 품질 확보를 위한 요구사항을 제정함
- 소프트웨어를 개발, 운용, 유지보수하기 위한 절차를 제정하고 실행함
- 소프트웨어의 품질에 영향을 미치는 액티비티를 평가하기 위한 절차를 제정하고 실행함
2) 품질 목표 항목
- 정확성(Correctness) : 사용자의 요구사항을 충족시키는 정도
- 신뢰성(Reliability) : 소프트웨어 품질 목표 중 주어진 시간 동안 주어진 기능을 오류 없이 수행하는 정도
- 효율성(Efficiency) : 최소의 작업으로 요구되는 기능을 수행하는 정도
- 무결성(Integrity) : 허용하지 않은 사용이나 자료의 변경을 제어하는 정도
- 유지보수 용이성(Maintainability) : 소프트웨어의 오류를 쉽게 수정할 수 있는 정도
- 사용 용이성(Usability) : 소프트웨어를 쉽게 사용할 수 있는 정도
- 검사 용이성(Testability) : 소프트웨어를 쉽게 검사할 수 있는가의 정도
- 이식성(Portability) : 다양한 하드웨어 환경에서도 운용 가능하도록 쉽게 수정될 수 있는 정도
- 상호 운용성(Interoperability) : 다른 소프트웨어와 데이터 교환이 가능한가의 정도
- 유연성(Flexibility) : 소프트웨어를 쉽게 수정할 수 있는가의 정도
- 재사용성(Reusability) : 전체나 일부 소프트웨어가 다른 응용 목적으로 사용될 수 있는 정도로 객체지향 프로그램 기술 중 소프트웨어 개발 생산성에 가장 영향을 주는 요소
06. 소프트웨어 신뢰성 측정
1) 신뢰성 측정의 기본 개념
- 소프트웨어 신뢰성은 주어진 시간 동안 주어진 환경에서 프로그램이 고장이 없이 운영될 확률을 말함
- 소프트웨어 신뢰성은 과거의 데이터와 개발 시점의 데이터를 사용해서 측정되고, 예측될 수 있음
- 신뢰성 평가를 위한 검토 항목은 시스템 전체의 가동률, 시스템을 구성하는 각 요소의 신뢰도, 신뢰성 향상을 위해 시행한 처리의 강제 효과 등이 있음
- 소프트웨어 실패는 설계 또는 구현상의 문제로 발생함
- 최종 사용자는 실패에 관심이 있는 것이지 총 오류 수에는 관심이 없음
2) 평균 시간의 종류
- 평균 무장애 시간(MTTF : Mean Time To Failures)
- 상호 인접한 고장 사이의 가능된 시간 평균, 고장 수리가 끝난 시간부터 다음 고장이 발생할 때까지의 시간 평균치
- 사용 중인 시간들의 평균치를 의미
- MTTF = (사용1 + 사용2 + ... + 사용n) / n
- 평균 복구 시간(MTTR : Mean Time To Repair)
- 고장이 일어난 시점부터 고장 수리가 완료되는 시점까지의 평균치를 의미
- MTTR = (고장1 + 고장2 + ... + 고장n) / n
- 가용성
- 시스템의 전체 시간 중에서 실제 가동하여 사용 중인 시간의 비율
- 가용성 = MTTF / (MTTF + MTTR)