소프트웨어 품질 보증

• 소프트웨어 품질 보증의 개념
  • 품질 보증의 정의
    • ISO 8402
      어떤 물건이 품질 요구 사항을 만족하고 있다는 것에 대해 충분한 신뢰성을 주기 위해 품질 시스템 중에서 실시되고 필요에 따라 실증되는 모든 계획적이고 체계적인 활동
    • ANSI/IEEE
      물품 또는 제품을 정해진 기술적 요구 사항에 적합하게 함으로써 충분한 신뢰를 얻는 데 필요한 모든 계획적이고 체계적인 활동의 유형
    • 일반적 정의
      소비자가 만족하는 제품 또는 서비스의 품질을 보증하기 위한 조직적.체계적 활동
  • 품질 보증의 특성

소프트웨어 특징	품질 보증 관점	방법
논리의 대규모 집합체	논리의 구조화 논리의 검증 논리의 명확한 표현	구조 설계법 디자인/코드 검토, 테스트 도식화 설계 기법
비가시성	프로그램의 시각화 프로세스의 시각화	CASE 툴의 지원 품질 관리 및 공정 관리 데이터의 도식화
다양한 사용자 요구	사용자 요구 사항의 파악 사양 변경의 대처 사용 조건하의 테스트	사양화 기법, 프로토타이핑 변경 관리 시스템 시뮬레이션 테스트
개인 생산성	표준화 및 자동화 개인의 능력 향상	표준 개발 절차의 확립 개발 지원 도구(CASE)의 채택 재사용 기술, 부품화 교육 강화 기본 철저

• 소프트웨어 품질 보증의 필요성
  • 사용자 요구 사항의 최대 만족을 통한 생산성 향상
  • 개발 과정에서 품질 문제점 조기 발견 및 제거
  • 납기 준수, 제품의 견고성 제품의 확장성 지원
  • 비용 및 노력 절감, 생산성 향상, 재사용성 증가
• 품질 측정
  • 제품 평가(Product Evaluation) : 의도한 기능
  • 공정 평가(Process Assessment) : 최적의 방법 이용
       

• 검증(Verification)와 Validation) : ANSI/IEEE
  • 검증
    • 소프트웨어 개발 사이클의 각 과정에서의 성과가 그 전반의 과정에서 확립된 요구 사항을 만족 시키고 있는가를 결정하는 과정(Build the Product Right)
    • 검증은 각 개발 공정이 바르게 실시되고 있는지 아닌지를 해당 공정이 종료되기 전에 검토나 테스트 수단을 통해 검사하는 것
  • 확인
    • 소프트웨어 개발 과정의 최후에 소프트웨어가 요구 사항에 따랐는지를 확인하기 위해 소프트웨어를 평가하는 과정(Build the Right Product)
    • 확인은 최종 테스트나 최종 공정에서 소프트웨어 제품이 사용자의 요구 사항 정의를 충족시키는지의 여부를 사용자 입장에서 확인하는 것
         
• 검증(Verification) - 제품을 올바르게 만들고 있는가를 평가하는 것
• 확인(Validation) - 올바른 제품을 만들고 있는가, 즉 개발 과정의 종료 시 소프트웨어가 요구 사항에 맞게 제작되었는가를 평가 하는 것
     
• 소프트웨어 품질 보증 기법
  • 소프트웨어 검토 개념
    • 소프트웨어 검토의 의미
      소프트웨어 공학 과정에서의 여과기로서, 개발 기간 중 제거할 수 있는 결점들을 찾는 과정
    • 검토의 필요성(Freedman and Weinberg)
      • 기술적인 일은 당연히 검토를 필요로 하며 오류의 원인은 사람
      • 개발자가 자신의 몇몇 오류를 찾아내는데 능숙하지만 대부분의 오류는 다른 사람들보다 오히려 찾기 어려움
    • 소프트웨어 오류의 비용 영향
      • 기술 검토의 이익은 후속 단계 이전에 오류를 조기에 발견하는 것
      • 설계 활동이 모든 오류의 50~60%를 차지하며, 기술 검토는 설계 오류의 75% 지적 효과를 가져옴(설계 시 오류 수정에 1$가 소요된다며 유지보수 시 발견된 오류 수정에 평균 67$ 소요)
      • 결함 증폭 모델 : 소프트웨어 공학 과정의 설계 및 코딩 단계에서 결함의 발생과 검출을 나타내는 데 이용
  • 정형적 기술 검토(FTR; Formal Technical Reviews)
    • FTR의 정의
      FTR이란 검사 리스트(Check List)를 미리 작성하고, 검사 리스트에 근거하여 검토자와 함께 산출물이 정확하게 작성되었는지를 검증하는 방법
      • FTR - 소프트웨어 공학 실무자에 의해 수행되는 소프트웨어 품질 보증 활동으로, 요구사항과 일치하는지, 미리 정의된 표준에 따라 표현되었는지, 균일한 방식으로 개발되고 있는지, 철저한 관리가 이루어지고 있는지를 검토 하는 것
    • FTR의 목적
      • 소프트웨어 표현을 위한 기능, 논리,구현의 결함 도출
      • 소프트웨어가 요구 사항과 일치하는지 검증
      • 정의된 표준에 따라 표현되었는지 보증
      • 균일한 방식의 소프트웨어 개발 지원
      • 프로젝트의 효과적 관리 지원
    • FTR의 종류
      • 검토(Review)
        • 부적절한 정보나 누락되거나 관련 없는 정보의 발견
        • 요구 명세서와의 일치성 검토
        • 시스템 개발 요원, 관리자, 사용자, 외부 전문가 참여
      • 워크스루(Walk-through)
        • 결함을 찾고 대안을 시험하는 수단
        • 비공식적인 검토 과정
        • 개발에 참여한 팀들로 구성
          • 워크스루(Walk-through) - 이미 작성된 산출물의 결함을 발견하기 위해 개발 업무에 관련된 여러 동료 집단이 수행하는 재검토 작업으로 문제점의 조기 발견을 목적으로 운영되며, 분석가가 주체가 되어 적은 인원으로 짧은 시간 내에 검토하는 것
      • 검사(Inspection)
        • 소프트웨어 구성 요소들의 결함을 찾고 해결책 검증 및 정확한 평가
        • 검토보다 엄격하고 정형화 됨
        • 검사 리스트(Check List) 등을 사용
        • 전문 지식을 가진 팀으로 구성
          • 검사(Inspection) - 워크스루와 비슷하나 결함을 발견하여 수정하기 위한 것으로, 각 과정의 산출물에 대한 완성 기준을 정해 놓고 각 과정이 끝날 때마다 제대로 안성 되었는지를 확인
            중재자가 주체가 되고 검열팀이 구성될 수 있으며, 검사 리스트를 사용
     
• 소프트웨어 품질 보증 프로세스
  • 소프트웨어 품질 보증 절차

순서	활동 내역
품질 보증 계획 수립	품질 보증 활동 계획 수립 및 평가 대상 산출물 설정 품질 보증 프로세스와 기준선(Baseline) 설정
엔지니어링 활동 검토	개발 활동에 대한 검토 산출물을 생산하기 위한 프로세스들의 운용 검토
품질 측정 평가	품질 복표에 따라 실제 품질 평가 및 측정 소프트웨어 감리 및 감사와 연관
문서화	품질 평가에 대한 문서 기록
숭인	문서화된 평가 결과 승인 품질 보증 활동에 대한 최고 결정권자의 승인
보고 및 통보	승인된 품질 평가 결과를 개발 할동에 반영 관련 조직 및 관련 인원에 통보

• 소프트웨어 품질 보증 활동

품질 보증 활동	세부 내용
형상관리	형상 항목 식별, 변경사항 관리
문서관리	문서 관리 절차 수립, 문서 작성 / 보관 / 폐기
품질 기록	품질 보증 계획 / 수행 / 결과 기록
합동 검토	마일스톤에 따라 프로젝트의 진행 상황을 공동 검토
검증 및 확인	단계별 검증 및 테스트
시정 조치	해결 방안 수립 및 조치
위험 관리	예상 위험 발견 / 평가 / 통제
쟁점 관리	고객 요구 사항 변경 등의 쟁점 분석 대안 설정 및 실행

   

• 소프트웨어 형상 관리
  • 소프트웨어 형상 관리의 개요
    • 정의
      • 소프트웨어 라이프사이클 단계의 산출물을 체계적으로 관리하고, 소프트웨어 가시성 및 추적성을 부여하여 품질 보증을 향상시키는 기법
      • 소프트웨어를 이루는 부품의 기준선을 정하고 변경을 철저히 통제하는 것
    • 필요성
      • 소프트웨어 개발 및 유지보수 통제의 어려움
      • 소프트웨어 추적의 결여 및 무절제한 변경
      • 소프트웨어 가시성(Visibility)의 결핍
    • 목표
      • 소프트웨어 형상 관리의 효율성 제고
      • 소프트웨어의 가시성 및 통합 정보 제공
      • 소프트웨어 재사용성 향상
      • 소프트웨어 유지 보수성 향상
  • 소프트웨어 형상 관리의 업무는 식별, 형상통제(변경 관리), 형상 감사, 형상 기록 등인데, 이 중 가장 중요한 것은 형상 통제(변경 관리) 이다.
  • CCB[Configuration Control Board, 협상 통제 위원회] - 협상 기준선의 승인과 변경 승인 등의 역할을 수행
       
  • 소프트웨어 형상 관리 기본 용어
    • 형상항목(Configuration Item)
      소프트웨어 라이프사이클 중 공식적으로 정의되어 기술되는 관리 기본 대상
    • 형상 관리 기준선
      • 각 형상 항목들의 기술적 통제 시점
      • 모든 변경을 통제하는 시점의 기준
    • 형상물(Configuration Product)
      소프트웨어 라이프사이클 중 공식적으로 구현되는 형체가 실현된 형상 관리의 대상으로 기술 문서, 하드웨어 제품 소프트웨어 제품 등이 있음
    • 형상 정보(Configuration Information)
      형상 정보 = 형상 항목 + 형상물
  • 소프트웨어 형상 관리 개념도 및 관리 활동
    • 소프트웨어 형상 관리 개념도
      
    •    
    • 소프트웨어 형상 관리 활동

절차	내역
형상 식별	형상 관리 대상들을 구분하고, 관리 목록에 대한 번호 부여 형상 식별 내용 : 제품/각종 문서/ 형상 항목 번호
형상 통제 (변경 관리)	소프트웨어 형상 변경 제안을 검토하여 승인하고 현재 소프트웨어 기준선에 반영될 수 있도록 통제하는 것 변경 요구 관리/변경 제어/형상 관리 조직의 운영 및 개발업체와 외주업체에 대한 통제 및 지원
형상 감사	소프트웨어 기준선의 무결성 평가 수단 성공적인 형상 감사는 소프트웨어 기준선을 성공적으로 설정 검증 및 확인
형상 기록	소프트웨어 형상 및 변경 관리에 대한 각종 수행 결과를 기록하고, 데이터베이스에 의한 관리를 하며, 보고서를 작성하는 기능

• 소프트웨어 변경 관리
  • 변경 관리의 정의
    소프트웨어 라이프사이클 각 단계에서 형상 항목을 변경 시 효과적이고 체계적으로 통제와 관리를 위한 제반 활동
  • 변경 관리/형상 관리 조직
    • 분석가
      • 사용자와 협의를 통한 문제점 도출
      • 기능 향상 및 변경 사항 결정
    • 프로그래머
      변경의 형태와 내용을 알아내고, 실제 프로그램을 수정
    • 프로그램 Librarian
      문서와 코드에 대한 변경을 계속 보관 및 관리
    • 형상(변경) 통제 위원회(CCB; Configuration or Change Control Board)
      • 개발 요청자와 개발 수행자로 구성
      • 소프트웨어 형상 기준선 승인
      • 소프트웨어 변경 승인
      • 소프트웨어 변경 후 무결성 감사
  • 변경 관리 제문서
    사고 보고서 / 변경 요청서
  • 변경 관리 절차
       
• 소프트웨어 형상 관리의 효과
  • 프로젝트 측면
    • 프로젝트의 체계적이고 효율적인 관리의 기준을 제공
    • 프로젝트의 원활한 통제 가능
    • 프로젝트에 대한 가시성과 추적성 보장
  • 소프트웨어 측면
    • 소프트웨어의 무절제한 변경 예방
    • 소프트웨어 변경에 따른 부작용 최소화 및 관리의 용이성
    • 소프트웨어의 품질 보증
    • 소프트웨어의 적절한 변경 관리 기능
    • 소프트웨어의 유지보수성 향상
    • 소프트웨어의 유연한 외주 관리 가능
• 소프트웨어 형상 관리의 문제점 및 해결 방안
  • 소프트웨어 형상 관리의 문제점
    • 형상 항목의 불명확 및 형식적인 식별 관리, 관행적인 통제 수행
    • 형상 상태의 기록 및 형상 변경 관리 등의 절차 미비
    • 형상 보고 활동의 미흡 및 간과
    • 관리 조직의 부재 및 형상 관리 적용의 비 현실화
    • 형상 관리가 너무 많으면 제품 생산성 저하, 너무 적으면 제품 품질 저하
  • 소프트웨어 형상 관리의 해결 방안
    • 적절한 형상 관리 도구의 활용
    • 소규모 프로젝트 일수록 형상 관리 정도를 적절히 조정
    • 형상 항목을 정하고 모든 변경사항은 공식적인 합의에 의해 실시
    • 가동중인 소프트웨어의 변경은 신중을 기해야 함
• 소프트웨어 형상 관리의 동향
  • 형상 관리는 효율적인 프로젝트 진행, 소프트웨어 개발, 유지보수 관리를 위해 반드시 필요 → 전체적인 TCO 절감
  • 효율적인 형상 관리를 위해서는 적절한 조직 구성, 관리 도구 활용, 지속적인 관리 및 명확한 관리 기준 설정 등이 필요
  • 형상 관리 자동화를 위한 도구 분야의 발전과 지능화가 진행 중
    • TCO[Total Cost of Ownership, 총 소유 비용] - 투자 의사 결정을 도와주기 위해서 사용되는 TCO는 초기 비용이나 구매 가격만이 아니라 형상 항목을 소유하는 모든 수명 주기 비용을 평가함
         

• 소프트웨어 신뢰도
  • 소프트웨어 신뢰도의 개념
    • 소프트웨어를 믿고 사용할 수 있는 정도로 모든 품질 가운데 가장 중요한 요소
    • 주어진 시간 동안 주어진 환경하에서 프로그램이 고장(Failure) 없이 운영될 확률
    • 고장은 소프트웨어 요구 사항에의 불일치
    • 신뢰도가 낮으면 소프트웨어 품질도 낮음
  • 소프트웨어 고장의 분류
    • 초기 고장
      계산 오류, 논리 오류, 인터페이스 오류 등과 같이 설계나 코딩의 잘못으로 발생되는 오류
    • 우발 고장
      사용자의 요구 사항 변화, 운용 조건의 변화 등으로 인한 오류
  • 소프트웨어 신뢰도의 척도
    • 신뢰도 측정
      • 고장들 사이의 평균 시간(MTBF; Mean Time Between Failure)
      • MTBF = MTTF + MTTR

	MTTF ; Mean Time To Failure → 평균 가동 시간
	MTTR ; Mean Time To Repair → 평균 복구 시간

• 유효성(Availability)
  • 프로그램이 주어진 시점에서 요구 사항에 따라 작동되는 비율
  • 유효성 = MTTF / (MTTF + MTTR) * 100%
    • MTBF는 고장과 고장 사이의 평균 시간으로 클수록, 좋고, MTTR은 고장이 나서 복구하는데 사용된 평균 시간으로 적을수록 좋음

• 소프트웨어 신뢰도의 측정 모델
  • 고장들 간의 시간 모델(Time between Failure Models)
    • 고장 시간 간격 모델화
    • 오류를 제거하면 고장 간격이 길어진다고 기대하는 모델
  • 오류 계수 모델(Error Count Models)
    • 시간 간격도안의 오류 수를 모델화
    • 오류가 제거되면 시간 간격당 오류 수는 감소
  • 오류 파종 모델(Error Seeding Models)
    • 임의의 오류를 삽입
    • 주어진 시간 동안 잔재 오류와 파종된 오류의 확률은 동일
  • 입력 영역 모델(Input Domain Models)
    하나의 입력에 대해 고장 없이 정상 작동하는 확률을 측정