12/13 15주차 수업내용 정리

12/6 14주차는 발표를 수행했기 때문에 따로 수업을 진행하지 않았다.

 

 

12장. 품질 보증

   

1. 품질이란?

  소프트웨어 품질

    - 좋은 소프트웨어를 판단하는 기준

 

  외부 품질

    - 사용자의 요구에 부합하는 것

    - 기능, 성능, 보안, 확장성, 신뢰성, 유지보수성, 이식성

 

  내부 품질

    - 좁은 의미의 '결함 없음'

 

품질의 정의

  IEEE의 품질 정의

    - 시스템이나 컴포넌트, 프로세스가 명시된 요구를 만족시키는 정도

    - 시스템이나 컴포넌트, 프로세스가 사용자, 고객의 요구나 기대를 만족시키는 정도

 

  프레스먼의 품질 정의

    - 소프트웨어가 외부에 제공하는 계산 결과는 설계 당시 명시된 기능 요구를 만족시켜야 한다.

    - 계약에 명시된 소프트웨어 품질 표준을 따라야 한다.

    - 개발자가 따라야 할 최신의 좋은 개발 방법(good software engineering practice)을 사용해야 한다.

 

품질의 관점

  사용자 관점

    - 사용자의 요구와 목적을 얼마나 만족시키느냐

  제조자 관점

    - 프로세스 표준 적합성

  제품 관점

    - 제품이 가진 원천적 특성에 초첨을 두고, 외부 품질을 개선하는 것

  가치 중심 관점

    - 소프트웨어에 대해 지불하려는 고객의 가치를 소프트웨어 품질로 보는 관점

  초월적 관점

    - 사용자를 만족시키는 보이지 않는 특성

 

품질 특성

  - 소프트웨어의 여러 속성을 그룹화하여 정리한 것

  - 맥콜의 품질 모델

    - 제품 운영에 관련된 특성 : 정확성, 신뢰성, 효율성, 통합성, 사용성

    - 제품 개정에 관련된 특성 : 유지보수성, 융통성, 테스트 용이성

    - 제품 전환에 관련된 특성 : 이식성, 재사용성, 상호 운용성

 

품질 관점과 품질 특성의 관계

  - 소비자, 사용자(외부) 관점

    - 정확성 : 고장 관련 특성

    - 사용성, 유지보수성, 이식성, 성능, 설치 용이성, 가독성

  - 생산자(내부) 관점

    - 정확성 : 결점 관련 특성

    - 설계, 크기, 변경, 복잡성 등

 

1. 품질이란?

 

- 품질 보증

  -소프트웨어 결함을 다루는 모든 활동

  - 개발 프로세스와 밀접한 관련

    - 개발 전, 중, 후 활동

    - 코드 분석

    - 소프트웨어의 동작을 테스트하는 것이 핵심

      - 코드 분석 -> 정적인 활동, 테스트 -> 동적인 활동

 

품질 보증의 정의

  제품이나 부품이 기술적인 요구를 만족시킨다는 확신을 주는 데 필요한, 계호획되고 체계적인 여러 가지 활동

  제품의 개발 또는 제조 과정을 평가하기 위해 설계된 작업

    - 기술적 요구에 대한 확신을 줌 

    - 개발 프로세스와 관련

    - 기술적인 요구 명세와 관련된 작업

 

  정의

    - "소프트웨어 개발 과정이나 유지보수 과정을 고려한 기능적 요구뿐만 아니라 일정과 예산 범위를 준수하는 관리적 요구도 만족시킨         다는 확신을 주기 위한 체계적이고 계획적인 활동"

 

품질 보증의 원리

  현황 파악

    - 현재 무엇을 하고 있는지 알아야 함

  목표 파악

    - 앞으로 무엇을 해야 하는지 알아야 함

  차이 인식

    - 현황과 목표의 차이를 인식

    - 정형적 방법

    - 테스트 ( 목표와 실제 동작을 일치하는지 비교하는 것 )

    - 인스펙션

    - 매트릭스

 

결합도는 낮은게, 응집도는 높은게 좋다.

결합도 : 한 클래스가 다른 클래스의 메소드나 속성과 얼마나 연관되어 있는지를 나타낸다.

응집도 : 한 클래스에 있는 메소드와 속성들이 얼마나 긴밀한지를 나타낸다.

 

개발 프로세스와 품질 보증

  - 품질 보증 활동은 테스트 단계에 초점을 두고 수행

  - 각 단계에서 다음 단계로 전환되는 과정에도 수행, 특히 테스트와 릴리스 사이의 리뷰는 인수 테스트와 함께 진행

  - 품질 보증 활동은 S/W 개발 프로세스 전 단계에 걸쳐 수행

    - 결함 방지

    - 결함 제거

    - 결함 허용성

 

3. 확인과 검증(V&V)

  확인

    - Are we building the product right? (소프트웨어를 올바르게 만들고 있는가?)

  검증

    - Are we building the right product? (올바른 소프트웨어를 만들고 있는가?)

  

  정적 V&V의 대표적인 예 : 인스펙션

  동적 V&V의 대표적인 예 : 테스팅

 

 

  인스펙션

    배경

      - 1976년 Fagan의 논문 발표

      - 품질 개선과 비용 절감을 위한 기법으로 사용

      - 소프트웨어 품질 보증에 탁월한 효과

      - 사전에 적은 노력으로 결함 발견

    목적

      - 준비하는 동안 예상되는 결함을 찾아내고 이를 확인

      - 발견된 아이템이 실제 결함이라는 사실을 확인

      - 결함이 있다는 사실을 기록

      - 개발자가 수정하도록 기록을 제시

 

  설계 인스펙션

    목적 : 모듈의 전반적인 설계나 기능을 점검

    주관심사 : 소프트웨어 요구, 성능 명세 관련 사항과 인터페이스 설계

    시스템 설계 명세서에 포함된 인스펙션 대상

   

  코드 인스펙션

    찾아내는 오류

      - 초기화되지 않은 변수, 객체 참조 또는 포인터

 

  인스펙션 과정

    - 기술 스태프만 참석

    - 인스펙션 주재자가 책임

    - 체크리스트를 만들어 미리 배포하고 발견된 이슈를 논의, 결함 판정

    - 해결책을 논의하는 것이 아니라 결함을 판별하고 수정을 지시

 

  워크스루

    테스트 케이스를 이용하여 제품을 수작업으로 수행해보는 것

    절차

      - 필요하다면 참석자에게 제품의 개요를 설명

      - 개발자가 결과물을 소리 내어 읽고 필요하면 설명

      - 다른 팀원은 질문하고 문제를 제기, 개발자가 문제를 수정할 예정 기간을 정한다.

      - 개발자가 문제를 고친 뒤 정리 리스트를 작성하고 참석자들에게 사인을 받는다.

 

  동료 검토

    동료가 제품을 검토

    제품의 여러 측면을 정성적으로 평가

    평가자의 지식과 배경에 따라 다를 수 있어 토론이 필요하며 되도록 같은 배경의 전문성을 가진 검토자가 참여

 

 

4. 품질 측정

  객관적인 측정 방법

    - 메트릭과 수치적 가시화 방법

  모듈의 크기 측정

    - 바이트 크기

    - 원시코드 줄 수

    - 원시코드 문장 수

  복잡도 측정

 

요구 메트릭

  - 요구의 비모호성

  - 요구 완전성 메트릭

    - 요구 명세서에 기술된 시스템의 상태와 시스템에 대한 외부자극이 완전하다는 가정에 근거

    - 시스템의 모든 가능한 상태와 모든 가능한 외부자극을 포함

           

               f(state, stimulus) -> (state, response)

    - f 함수가 완벽하게 매핑된다면 SRS는 완벽한 것으로 간주

    - 완벽하게 매핑된다는 것이란 요구 기술서에 모든 필요 내용이 들어가는 것을 의미한다.

 

객체지향 품질 메트릭

   책 필기 참조

 

5. 프로세스 품질 개선

  S/W의 품질저하는 프로세스 정립 부재

  프로젝트의 실패

    - 비용초과, 납기 지연

    - 1991 미국 정부조사 1%만이 목표 달성

  프로세스 품질에 좌우

  프로세스 개선 모델

    - CMM

    - ISO SPICE

 

  CMM

    배경

      - 1992년 미 국방성의 지원으로 설립된 CMU(카네기 멜론 대학)의 SEI가 제시

      - 1998년 버전 2.0으로 발전

    목적

      - 현재의 프로세스 상태를 벤치마킹하고 어떤 부분을 향상시킬것인지 전략을 선택하여 프로세스를 개선하려는 소프트웨어 개발 조            직에 도움을 주기 위함

    특징

      - 한정된 작업에 초점을 두어 공격적으로 활동함으로써 개발 조직의 계속적인 프로세스 향상 도모

      - 소프트웨어 엔지니어링 및 관리를 조직에 정착

    사용 방법 두 가지

      - 미래의 고객이 소프트웨어 공급자의 강점과 약점 파악

      - 갭라자 스스로 프로세스 능력 평가 후 개선 방향 설정

 

  CMM 레벨

    책 555페이지부터 참조

 

 

  SPICE

    Software Process Improvement and Capability dEtermination

 

  SPICE와 CMM

    유사점

      - 프로세스 심사를 위한 참조모형을 제공

        - 개발 성숙도에 따라 차별화된 수준을 정의

        - 각 수준의 특징을 제시하여 기관의 수준을 판단 기준 제공

 

    차이점

      - 성숙도 레벨과 심사 영역의 구분

        - CMM : 레벨 1부터 5까지 5개의 성숙도 수준을 정의

        - SPICE : 레벨 0부터 5까지 6개의 수준으로 나누어 정의

   

    단계별 능력 수준

       책 561페이지부터 참조

 

6. 품질 보증 계획과 품질 제어

  품질 보증 계획

    - 프로젝트 초반 계획

    - 목적, 관리, 표준과 관례, 리뷰와 감리, 형상 관리, 프로세스 방법론, 메트릭

  품질 제어

    - 프로젝트 전반에 걸쳐 이루어지는 모니터링, 수정

    - 품질 교육

    - 품질 관리 데이터베이스 이용