ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 과제#02 :: TESTING EVALUATION ASSESSMENT MEASUREMENT 에 대한 조사
    정리필요1 2008. 6. 9. 13:29

    과제2 : TESTING, EVALUATION, ASSESSMENT, MEASUREMENT 에 대하여 조사하여라.


    1. TESTING (시험)

    시스템이나 시스템 구성 요소(component) 또는 소프트웨어 프로그램을 실행하고 시험하는 과정. IEEE 정의에 따르면 수작업 또는 자동화된 방법으로 규정된 요구 사항을 만족시키고 있는지 검증하고, 기대되는 결과와 실제 결과의 차이를 식별하는 작업을 말한다. G.J. Myers의 정의에 따르면 테스트라고 표기하기도 하며 일반적으로 결함이 없음을 증명하는 것이 아니라 결함이 있음을 발견하기 위하여 체계적으로 수행하는 일련의 작업을 말한다.

    평가(Evaluation)의 한 과정, 평가수행을 말한다. 평가 요구사항 정의, 평가 명세, 평가 설계의 기준, 평가모듈에 따라 Testing 하는 것이다.  




    2. EVALUATION (평가)

    소프트웨어 개발과정 또는 개발된 제품형태의 소프트웨어의 품질을 객관적으로 측정과 평가하는 전체과정.
    품질 평가 절차를 “평가 요구사항 설정”, “평가명세”, “평가설계”, “평가수행” 등 4 단계로 구분한다.
     
    -      Planning and Management
    -      소프트웨어 제품 평가를 위한 지원 기능의 역할에 대한 권고 및 지침
    -      평가 관리 개념(지원 기능의 역할) : 표준설정, 데이터 수집 및 분석, 도구 개발, 평가 기술 확보 및 이전
    -      소프트웨어 평가지원 요구사항
    ·        평가 계획 수립의 주요사항
    ·        조직적인 차원에서 평가 기술 관리
    ·        프로젝트 관리를 위한 지원개요

    -      Process for Developers
    -      소프트웨어 개발단계에서 개발자가 준수해야 할 내용에 대한 표준
    -      조직 및 프로젝트 요구사항
    ·        평가요구사항의 도출 및 타당성 분석
    ·        평가내용의 명세화
    ·        External 및 Internal Quality 요구사항(Attributes, Target Values 정의)
    ·        평가 계획 설계(Internal 및 External Evaluation)
    ·        평가 수행(중간단계 제품 및 최종 제품) 및 평가 결과 도출

    -      Process for Acquirers(획득자 프로세스)
    -      Off-the-Shelf 소프트웨어 및 기존 소프트웨어 수정에 관하여 구매자가 준수해야할 내용에 대한 표준(ISO 12207의 구매절차와 연계하여 수행)
    -      Off-the-Shelf 소프트웨어 구매시 평가
    ·        시스템, 소프트웨어 평가 요구사항 도출
    ·        평가내용의 명세화
    ·        메트릭스 및 평가방법 선택
    ·        평가 계획 설계
    ·        평가 수행 및 결과 분석
    ·        결과 도출
    -      기존 소프트웨어 수정의 경우 평가
    ·        평가 요구사항 도출
    ·        평가내용의 명세화
    ·        평가 계획 설계
    ·        평가 수행 개요

    -      Process for Evaluators(평가자 프로세스)

    3. ASSESSMENT (심사)

    소프트웨어 프로세스 심사(Software Process Assessment) 프로세스의 목적은 소프트웨어 시스템 개발 조직에서 소프트웨어 프로세스 개선(Software Process Improvement)활동을 수행하는 조직의 소프트웨어 프로세스 능력을 이해하기 위해 사용 가능한 체계적인 방법을 제공하는 것이며, SPI활동을 수행하는 조직과 그 조직이 수행하고 있는 프로젝트에 대해 적용한다. 소프트웨어 프로세스 심사(SPA)를 통해 프로세스의 능력을 알아 볼 수 있고, 심사 결과를 토대로 조직내 프로세스에 내재한 장점, 단점, Risk를 식별하고, 대응하여 프로세스의 개선을 기대할 수있다.

    SPICE is?
    SPICE(또는 ISO/IEC 15504)는 소프트웨어 프로세스 전반을 망라한 심사를 실시하여 조직의 소프트웨어 개발 프로세스를 개선하고 개발자의 개발 능력을 향상시킴으로써 개발 위험을 통제하기 위한 목적으로 ISO에서 추진하는 소프트웨어 품질 표준화 심사 평가 모형으로 소프트웨어 프로세스 전반을 망라하여 심사를 하고 그 결과에 따른 조직의 프로세스를 개선하여 나가는 활동에 대한 표준화 방법이다.
     
    SPICE 평가 방식
    프로세스 능력 수준
    ISO/IEC 15504는 CMM과 마찬가지로 조직의 프로세스를 개선하기 위한 활동을 지원하기 위하여 현재의 프로세스 상태를 파악하여 성숙한 능력 수준을 측정한다. SPICE에서 정의하고 있는 프로세스는 5개의 카테고리로 구분되며 세부 프로세스는 40개로 정의한다. 또한 이들의 능력수준은 각 수준별 측정관점에 따라 6개의 수준으로 구분한다.
    - CUS(고객-공급자 프로세스 범주):소프트웨어를 개발하여 고객에게 전달하는 것을 지원하고, 소프트웨어를 정확하게 운용하고 사용하도록 하기 위한 프로세스로 구성되어 있다.
    - ENG(공학 프로세스 범주):시스템과 소프트웨어 제품을 직접 명세화, 구현, 유지 보수하는 프로세스로 구성되어 있다.
    - SUP(지원 프로세스 범주):소프트웨어 생명주기에서 다른 프로세스(지원 프로세스 포함)에 의해 이용되는 프로세스로 구성되어 있다.
    - MAN(관리 프로세스 범주):소프트웨어 생명 주기에서 프로젝트 관리자에 의해 사용되는 프로세스로 구성되어 있다.
    - ORG(조직 프로세스 범주):조직의 업무 목적을 수립하고, 조직이 업무 목표를 달성하는데 도움을 주는 프로세스로 구성되어 있다.



    4. MEASUREMENT (척도)


    ISO 9126의 정의
    1.        소프트웨어 품질의 특성을 정의하고 품질 평가의 Metrics를 정의한 국제표준
    2.        사용자 관점에서 본 소프트웨어의 품질 특성에 대한 표준
     
    ISO 9126의 필요성
    1.        사용자, 평가자, 시험관, 개발자 모두에게 소프트웨어 제품의 품질을 평가하기 위한 지침의 마련 필요
    2.        평가대상 소프트웨어의 품질을 직접 측정하기 위해 필요한 평가 Metrics의 준비
    3.        소프트웨어의 품질을 객관적이고 계량적으로 평가할 수 있는 기본적 틀 필요

Designed by Tistory.