'분류 전체보기'에 해당되는 글 1478

  1. 2005.11.02 품질도구 - 시스템 및 소프트웨어편
  2. 2005.11.02 리눅스 신뢰성 테스트
  3. 2005.11.02 이용자 인터페이스 설계 원칙과 평가방법
  4. 2005.11.02 S/W 품질 시험 • 인증 제도 및 기술 동향
  5. 2005.11.02 소프트웨어 벤치마크 활성화 방안
  6. 2005.11.01 벤치마크 관련 사이트
  7. 2005.11.01 내게 맞는 업스캔컨버터 6종 비교분석
  8. 2005.11.01 기종 평가
  9. 2005.11.01 s/w시험의 종류
  10. 2005.11.01 컴퓨터 성능 평가
  11. 2005.10.31 웹의 사용성(Usability)을 어떻게 평가할 것인가?
  12. 2005.10.31 CAD/CAM 시스템의 평가기준.
  13. 2005.10.31 소프트웨어 품질 등급 부여 방안 연구
  14. 2005.10.31 Project Quality Management
  15. 2005.10.31 소프트웨어 품질의 평가
  16. 2005.10.31 조엘 테스트: 소프트웨어팀 평가 테스트 방법
  17. 2005.10.31 소프트웨어 기술성 평가 기준 해설서
  18. 2005.10.31 Windows XP의 성능
  19. 2005.10.28 웹오피스 3종 벤치마킹
  20. 2005.10.28 7,200RPM 80GB HDD 4種 完全分析

품질도구 - 시스템 및 소프트웨어편

품질혁신 활동을 신속하고 효과적으로 지원해 주는 Tool로서 품질 선진기업들이 이용하고 있는 Software들을 한 자리에 모았습니다.


종래 인해전술 방식의 품질개선 활동에서 이제는 똑똑한 Software를 잘 이용하는 것 - 6 Sigma 수준의 품질혁신이 결코 일본이나 구미 선진국만의 독점물이 아닐 것입니다.


DATA의 해석이나 통계적 품질관리를 위해 복잡한 계산식을 일일이 대입하거나 표계산 기능의 엑셀 프로그램과 같은 것으로 서툴게 그래프를 그리는 등의 후진성으로는 결코 그들을 따라 잡을 수 없습니다.


ISO QS-9000 시스템의 효율적인 운영, 품질 혁신 활동의 선진화!...... 그것은 SQC에서 부터 Taguchi method, 실험계획법, 다변량해석 등과 같은 고도의 품질도구 적용과 이를 간단히 처리해 주는 System Software의 활용일 것입니다.


 


자세한 내용은 첨부 문서 참고


리눅스 신뢰성 테스트






리눅스 신뢰성 테스트


Linux Technology Center의 리눅스 장기 신뢰성 평가

developerWorks














문서 옵션













이 페이지를 이메일로 보내기

이 페이지를 이메일로 보내기

JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.



난이도 : 초급


Li Ge, Staff Software Engineer, Linux Technology Center, IBM
Linda Scott, Senior Software Engineer, Linux Technology Center, IBM
Mark VanderWiele, Senior Technical Staff Member, Linux Technology Center, IBM


2003 년 12 월 01 일


리눅스 커널과 다른 핵심 OS 컴포넌트-라이브러리 및 장치 드라이버 부터 파일 시스템과 네트워킹 까지-의 테스트 결과와 분석을 정리했다. 모든 테스트들은 매우 극단적 조건 속에서 긴 시간동안 수행되었다. IBM Linux Technology Center는 세 달 간의 테스트를 끝내고 그 결과를 이 자리에서 나눈다.

IBM Linux Technology Center (LTC)는 1999년 8월에 설립되어 리눅스 개발 커뮤니티와 함께 활동했다. 약 200여명의 직원들이 하나의 오픈 소스 개발자 그룹을 형성하고 있다. 패치 부터 구조적 커널 변경에 이르기까지 코드를 기여하고 있다. 또한 IBM 내의 리눅스 관련 개발을 트래킹하고 있다.


LTC의 주요 관심 분야는, 리눅스 확장성, 신뢰성, 시스템 관리 등으로 이는 리눅스를 엔터프라이즈 급으로 향상시키는데 중요한 요소들이다.


LTC의 또 다른 핵심 미션은 상용 프로젝트가 테스트 되는 방식 대로 연구실에서도 전문적으로 리눅스를 테스트하는 것이다. LTC는 LTP Linux Test Project (LTP)에 기여하고 있다.










테스트 결과 요약



다음은 실행 시간 동안 수행한 테스트 및 관찰 결과에 기반한 요약이다:


  • 리눅스 커널과 기타 핵심 OS 컴포넌트(라이브러리, 장치 드라이버, 파일 시스템, 네트워킹, IPC, 메모리 관리)는 지속적으로 실행되고 치명적인 시스템 오류 없이 실행을 완료했다.
  • 모든 실행은 높은 성공률(95% 이상)을 보였는데 간헐적인 오류도 거의 없었다.
  • 리눅스 시스템 퍼포먼스는 장기 실행 중에도 낮아지지 않았다.
  • 리눅스 커널은 하드웨어 리소스(CPU,메모리, 디스크)를 사용하기 위해 적절히 조정되었다.
  • 리눅스 시스템은 전체 CPU 로드(99% 이상)와 높은 메모리 스트레스를 훌륭히 처리했다.
  • 리눅스 시스템은 오버로드된 환경을 정확히 핸들했다.


리눅스 커널과 기타 핵심 OS 컴포넌트들은 30일, 60일, 90일이 넘어도 신뢰성과 안정성을 유지한다. 또한 강력하고 엔터프라이즈용 으로도 손상이 없는 환경을 제공한다.


목표


리눅스 신뢰성 테스트의 목표는 LTP 테스트 슈트를 사용하여 오랜 기간 동안 리눅스 고객환경과 유사한 워크로드를 주어 리눅스의 안정성과 신뢰성을 측정하는 것이다. (참고자료). 여기에서 오류 규명은 주요 목표는 아니다.


테스트 환경 개요


여기에서는 LTP 테스트 슈트를 사용하여 30일과 60일 동안의 리눅스 신뢰성 측정 테스트에 대한 분석과 테스트 결과를 설명한다. 테스팅 커널로는 SuSE Linux Enterprise Server v8 (SLES 8)을 , 테스팅 하드웨어로는 IBM pSeries 서버가 사용되었다. 특별히 고안된 스트레스 테스트 시나리오에는 광범위한 커널 컴포넌트-네트워킹과 메모리 관리 같은 광범위한 커널 컴포넌트의 실행과 테스팅 시스템에 높은 스트레스의 워크로드를 만드는 것 등이 포함되어 있다. 리눅스 커널, TCP, NFS, I/O 테스트 컴포넌트들은 높은 스트레스 워크로드를 받게된다.

















위로



테스트



30일


30일 LTP 스트레스 실행 결과 (pSeries)


  • 머신: p650 LPAR
  • CPU: (2) Power4- 1.2 GHz
  • 커널: Linux 2.4.19-ull-ppc64-SMP (SLES 8 SP 1)
  • LTP version: 20030514
  • 99.00 percent Average CPU utilization (User: 48.65 percent, System: 50.35 percent)
  • 80.09 percent Average memory utilization (8GB)



  • SLES 8 PPC64 30일 스트레스 실행은 p650 LPAR에서 성공적으로 완료됨.
  • LTPstress는 테스트 툴이었다. 테스트 케이스는 병렬과 시퀀스 방식으로 실행되었다.
  • Kernel, TCP, NFS, I/O 테스트 컴포넌트들은 높은 스트레스 워크로드를 받았다.
  • 성공 비율: 97.88 percent
  • 주요한 시스템 오류 없음.

그림 1. 30일 LTP 스트레스 실행 결과
30-day LTP stress execution results for the pSeries


  • 머신: B80
  • CPU: (2) Power3- 375 MHz
  • 커널: Linux 2.4.19-ull-ppc64-SMP (SLES 8 SP 1)
  • LTP version: 20030514
  • 99.96 percent average CPU utilization (User: 75.02 percent, System: 24.94 percent)
  • 61.69 percent average memory utilization (8GB)
  • 3.86 percent average swap utilization (1GB)

관찰:


  • SLES 8 PPC64 60일 스트레스 실행은 pSeries B80에서 성공적으로 완료됨.
  • 테스트 툴: LTPstress. 테스트 케이스는 병렬과 시퀀스 방식으로 실행되었다.
  • Kernel, TCP, NFS, I/O 테스트 컴포넌트들은 높은 스트레스 워크로드를 받았다.
  • 성공 비율: 95.12 percent
  • 주요한 시스템 오류 없음.


그림 2. 60일 LTP 스트레스 실행 결과
60-day LTP stress execution results for the pSeries

하드웨어 및 소프트웨어 환경



표 1. 하드웨어 환경
























시스템 프로세서 메모리 디스크 스왑 파티션 네트워크
pSeries 650 (LPAR) Model 7038-6M2 2 - POWER4+(TM) 1.2GHz 8GB (8196MB) 36GB U320 IBM Ultrastar (다른 디스크도 있지만 사용되지 않음) 1GB Ethernet controller: AMD PCnet32
pSeries 630 Model 7026-B80 2 - POWER3(TM)+ 375 MHz 8GB (7906MB) 16GB 1GB Ethernet controller: AMD PCnet32

표 2. 소프트웨어 환경















컴포넌트 버전
Linux SuSE SLES 8 with Service Pack 1
Kernel 2.4.19-ul1-ppc64-SMP
LTP 20030514
















위로



방법


시스템 안정성 및 신뢰성은 지속적인 실행 시간과 시스템의 확실한 업로드로 측정된다.


xSeries와 pSeries 서버에서 기본적으로 30일 테스트가 수행되고 60일과 90일로 나아갔다. 초기 주안점은 커널, 네트워킹, I/O 테스팅이다.


테스트 툴
Linux Test Project (LTP; 참고자료)는 SGI, IBM, OSDL, Bull, Wipro Technologies와의 합동 프로젝트이다. 리눅스의 신뢰성, 강도, 안정성을 테스트 하는 오픈 소스 커뮤니티에 테스트 슈트를 제공하는 것이 목표이다. Linux Test Project는 리눅스 커널과 관련 기능들을 테스트 하기 위한 툴 컬렉션이다. 커널 테스팅의 자동화를 실현시켜 리눅스 커널을 향상시키는 것이 목적이다.


현재 LTP 슈트에는 2000개의 테스트 케이스가 있다. 대부분 syscall, 메모리, IPC, I/O,파일시스템, 네트워킹 같은 커널 인터페이스를 다루고 있다. 테스트 슈트는 업데이트 되고 월간 배포되며 다양한 아키텍쳐에서 실행된다.

















위로



테스트 전략


24 시간 "초기 테스트"와 "스트레스 테스트" 단계가 있다


초기 테스트를 통과하는 것은 엔트리 요구사항 같다. 초기 테스트는 하드웨어와 OS에서 LTP 테스트 슈트의 24 시간동안의 성공적인 실행이 이루어져야 한다. 드라이버 스크립트인 runalltests.sh는 커널을 확인하는데 사용된다. 이 스크립트는 순서대로 패키지 테스트를 실행한다. 병렬로 동시에 실행되는 여러 인스턴스들을 시작하는 옵션도 가지고 있다. 이 스크립트는 디폴트 실행이다:


  • 파일시스템 스트레스 테스트
  • 디스크 I/O 테스트
  • 메모리 관리 스트레스 테스트
  • IPC 스트레스 테스트
  • 스케줄러 테스트
  • 명령어 함수 확인 테스트
  • 시스템 호출 함수 확인 테스트


스트레스 테스트는 시스템 사용도가 높을 때 제품의 강도를 확인하는 것이다. runalltests.sh 외에 ltpstress.sh 라고 하는 테스트 시나리오는 광범위한 커널 컴포넌트들을 메모리 관리 및 네트워킹과 병행하여 실행하고 테스팅 시스템에 높은 스트레스 워크로드를 만들도록 특별히 고안되었다. ltpstress.sh는 LTP 테스트 슈트의 일부이다. 이 스크립트는 비슷한 테스트 케이스들을 병렬로 실행하며 다른 테스트 케이스들은 순차로 실행한다. 이 스크립트도 디폴트로 실행된다:


  • NFS 스트레스 테스트
  • 메모리 관리 스트레스 테스트
  • 파일시스템 스트레스 테스트
  • Math (floating point) 테스트
  • pthread 스트레스 테스트
  • 디스크 I/O 테스트
  • IPC (pipeio, semaphore) 테스트
  • 시스템 호출 함수 확인 테스트
  • 네트워킹 스트레스 테스트

















위로



시스템 감시


변경된 top 유틸리티는 시스템 감 시 툴로 사용되었다. top은 실시간으로 프로세서 액티비티를 계속 관찰한다. 향상된 top 유틸리티는 추가 기능이 있는데 top 결과의 스냅샷을 파일에 저장할 수 있고 결과 파일의 평균을 요약 할 수 있다.


우리의 테스트에서 시스템 사용에 대한 스냅샷(또는 top 아웃풋 파일)은 10초 마다 찍히며 결과 파일에 저장된다. 게다가 시스템 사용과 LTP 테스트 아웃풋 파일은 매일 또는 주 마다 찍힌다. 이 기능은 cron 잡과 스크립트에 의해 제어되었다.


테스트 전
선택된 모든 테스팅 시스템은 가능한 한 서로 비슷하게 설정되었다. 여분의 하드웨어는 잠재적인 하드웨어 오류를 줄이기 위해 제거되었다. 최소한의 보안 옵션이 이미지 설치 동안 선택되었다. 최소 2GB의 디스크 공간이 top 데이터 파일과 LTP 로그 파일을 저장하도록 보유되었다.


테스팅 중간
테스트 중에는 시스템은 방해받지 않았다. 테스트가 실행되는지 확인하기 위한 임시 액세스는 허용했다. ps 명령어 사용, top 데이터 체크, LTP 로그 데이터 확인 등이 그것이다.


테스팅 후
테스트가 완료되면 시스템 감시 툴인 top은 갑자기 멈춘다. 모든 top 데이터 파일들은 저장되고 분석을 위한 데이터를 제공하는 프로세스가 시작된다.

















위로



참고자료


















위로



필자소개










Li Ge: Staff Software Engineer in the IBM Linux Technology Center.











Linda Scott: Senior Software Engineer, IBM development lab.











Mark VanderWiele: Senior Technical Staff Member & Architect, IBM Linux Technology Center.

이용자 인터페이스 설계 원칙과 평가방법

첨부 문서 참고

S/W 품질 시험 • 인증 제도 및 기술 동향

소프트웨어 벤치마크 활성화 방안

소프트웨어 벤치마크 활성화 방안 PDF 파일

벤치마크 관련 사이트

내게 맞는 업스캔컨버터 6종 비교분석

첨부 문서 참고

기종 평가

 ⑴. 성능평가요소
hardware 요소
CPU, CACHE,  MEMORY,   DISK,  I/O  등

software 요소
OS, LANGUAGE,  DBMS,  NETWORK,  APPLICATION 등

MIPS
Million Instruction Per Second
1초당 평균 명령 실행 횟수

MFLOPS
million floating point oeration per second
1초당 부동소수점(실수) 연산 횟수

TPC
MIPS를 대치하기 위한 새로운 성능 평가 기준


⑵. 평가방법
POED 법
performance organization for evaluation and decision
h/w, s/w, 메이커 측의 서비스 체제, 가격 등 주요 항목별로 가중치를 부여한다. 이때 각 항목들의 중요도에 따라 weight를 달리하며 각각의 소항목에 대하여도 서로 다른 weight를 부여하여 소항목에만 채점을 함으로써 대항목은 자동으로 집계가 이루어진다.

AUER BACH 법
사무적인 데이타 처리를 중심으로 몇가지의 표준문제를 만들어 놓고 처리에 소요되는  시간으로부터 컴퓨터의 종합적인 성능을 판별한다.

BENCH MARK 법
표준문제를 사용자측이 준비하고 메이커 측에서 프로그램을 작성하여 실제로 그 문제를 풀게하여 결과를 비교하는 방법이다. 사용자가 필요한 사무처리를 각 회사별 기종으로  처리함으로써 소요되는 시간을 측정할 수 있기 때문에 이상적인 방법이긴 하지만 프로 그램을 작성하는 메이커 측의 Software Engineer나 프로그래머의 능력에 좌우되기 때문에 올바른 기계의 우열을 가릴 수 없는 단점이 있다.

CHECK LIST 법
h/w, s/w, 메이커 측의 서비스 체제, 가격 등 항목별로 점수를 배정하고 체크리스트에 기입된 내용을 평가 채점하여 상대적인 컴퓨터의 성능우열을 비교검토하는 방식이다.

GIBSON MIX 법
미국 항공우주국(NASA)에서 개발한 방법으로 컴퓨터의 내부 처리 능력을 비교하기 위하여 특별히 빈도가 높게 사용되는 명령을 선택하여 그 실행 시간에 가중치를 곱한 값을 합산한 결과가 가장 작은 쪽이 우수한 시스템으로 평가된다.

s/w시험의 종류

시험 試驗
test, testing

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


 


사용자 인터페이스 시험 使用者 - 試驗
user interface test, user interface testing

시스템이나 시스템 구성요소 (component) 또는 소프트웨어 프로그램에서 사용자 인터페이스 (user interface)가 일관성을 유지하는지 또는 표준을 준수하여 적절히 설계되고 개발되었는지 확인하는 시험. 사용자의 혼동 또는 사용상의 불편을 초래하는 경우도 체크하는 것이 일반적이다.


신뢰성 시험 信賴性試驗
reliability test, reliability testing

모든 기능에 대해 시스템이나 시스템 구성요소 (component) 또는 소프트웨어 프로그램이 다운되지 않고 안정적으로 수행되는지를 확인하는 시험.


 


 


스트레스 시험 -試驗 ((응력 시험 應力 試驗))
stress test, stress testing

시스템이나 시스템 구성요소 (component) 또는 소프트웨어 프로그램에 다양한 스트레스를 가할 시에도 안정적으로 작동하는지를 확인하는 시험. 즉, 짧은 시간 동안에 많은 사용자가 동시에 접속 (access) 하는 것과 같은 스트레스에 시스템이 안정적으로 작동하는지를 확인하는 과정이다.


 


성능 시험 性能試驗
performance test, performance testing

개발된 시스템이나 시스템 구성요소 (component) 또는 소프트웨어 프로그램이 주어진 환경 하에서 응답속도, 처리량, 처리속도 등의 항목에 대하여 요구되어진 목표치를 달성하는지를 확인하는 시험.


 


기능 시험 -試驗
functional test, functional testing

시스템이나 시스템 구성요소 (component) 또는 소프트웨어 프로그램의 요구분석 시 정의된 요구 기능이 잘 작동하는지를 확인하는 시험. 화면 단위의 기능 뿐 아니라 데이터의 관점도 고려하여 수행하는 시험이다.


 


시스템 시험 -試驗
system test, system testing

시스템 구성요소 (component)나 소프트웨어 프로그램의 모듈이 하나의 시스템으로 동작하게 되면서 시스템 성능과 관련된 고객의 요구사항이 완벽하게 수행되는지를 평가하는 시험. 현장에서 적용 가능한 시스템 시험으로 스트레스 시험과 볼륨 시험을 들 수 있다. 시스템 시험을 성공적으로 수행하기 위해서는 성능 요구사항을 명확히 하여야하며, 단위/통합 시험이 완료되어 기능상 문제가 없는 상태여야 하며, 실 사용 환경과 동일한 모의 시스템을 구성하여야 하는 것은 물론 개발자와 시험전문가가 원활히 정보를 공유하고 협력하여야 한다.


 


통합 시험 統合試驗
integration test, integration testing [약어 없음] 컴

시스템이나 시스템 구성요소 (component) 또는 소프트웨어 프로그램의 데이터 및 기능의 인터페이스가 정상적으로 작동하는지에 중점을 두고 수행하는 시험.


 


단위 시험 單位試驗
unit test, unit testing

하나의 소프트웨어 모듈이 정상적으로 기능을 수행하는지의 여부를 시험하는 최소수준의 시험. 원시 코드를 시험 대상으로 하며 단위 시험을 수행하는데 사용하는 주된 시험 방법은 화이트 박스 시험 (white box test)이다. 단위 프로그램별로 설계서 상에 정의된 기능을 제대로 수행하는지 검증하는 것을 목적으로 한다. 단위 시험은 해당 개발자에 의해서도 수행될 수 있으나 타개발자나 제3자에 의해서도 실시된다.

컴퓨터 성능 평가

  1. 컴퓨터 성능 평가 개요


      1) 컴푸터 성능 평가의 목적


         - 사용자 측면 -  응답시간, 작업수행 시간의 감소


         - 운영자 측면 - 동일한 시간 내에 많은 일을 처리하여 작업 처리량(Throughput), 대역폭


                                (Bandwidth)의 증가


      2) 컴퓨터 성능 평가의 방법


         - 성능 평가 목적을 기술하고 대상 시스템을 선정한다.


         - 시스템 서비스아 가능한 결과 (출력)을 열거한다.


         - 성능지수를 선정한다.


         - 시스템 파라미터와 작업부하 파라미터를 설정한다.


         - 성능요소와 그 값을 설정한다.


         - 평가 방법을 설정한다.


         - 작업부하를 산정한다.


         - 실험을 계획한다.


         - 데이터를 해석하고 분석한다.


         - 결과를 제시한다.


      3) 컴퓨터 성능의 정의


         - 수행시간


         - 처리량


         - Amdahl 법칙의 속도 향상 지수


         등 성능 평가의 목적및 컴푸터 시스템의 구성에 따라 다양한 측면을 지닌다.


   2. 컴퓨터 성능 평가 척도


      1) CPU 성능


         - CPI(Cycle Per Instruction), 클럭 속도, MIPS(Million Instruction Per Second),


            Mflops, Dhrystone 결과, Whestone 결과


      2) TPS(Transaction Per Second)


         - OLTP system, DBMS 성능 평가 척도


      3) SPEC(System Performance Evaluation Cooperative)


         - 유닉스의 세계에서는 업계 표준이었지만 적절한 지표라고는 말할 수 없는 Shrystone 벤치


            마크를 대체하는 표준 벤치마크 개발을 목적


         - 주로 응용 때 관련된 벤치마크를 지향하고 프로세서 및 시스템의 전반적인 성능 측정 지향


         - Unix 용 CPU, 캐쉬, 메모리의 성능 평가 척도 개발


      4) TPC(Transaction Processing Performance Council)


         - 트랜잭션 처리 시스템 보급이 확대됨에 따라, 트랜잭선 처리 벤치마크를 좀더 상세하게 정


            의하는 노력으로 결성됨


         - OLTP 시스템은 일반적으로 컴포터 시스템의 하드위에(본채와 주변기기), 운영체체,


            DBMS, 통신 등으로 구선된다. TPC 벤치마크는 여러 시스템 구성요소를 조합한 구체적인


            시스템 구성을 평가 대상으로 하고 컴퓨터 본체만을 대상으로 하지 않음


         - TPC-A : 온라인 업무용 벤치마크


            TPC-C : 제조업체용 상용업무 벤치마크


            TPC-D : 의사결정 시스템 벤치마크


      5) KLIPS


          인공지능 컴퓨터의 성능 평가 척도, 기호조작, 논리추론 능력에 중점


   3. 컴퓨터 성능 평가 기준


      1) 성능평가 지수


         - 속도 성능 지수 : 성공적으로 수행했을 때의 지수. 시간, 빈도, 자원의 사용량 등


         - 가용성 성능 지수 : 실패했을 때의 지수로서 고장시간, 평균 서비스 시간 등


         - 신뢰성 성능 지수 : 수행했으나, 에러가 발생한 경우의 지수로서 에러빈도, 에러시간 등


              OLTP 시스템은 일반적으로 컴퓨터 시스템의 하드웨어(본체와 주변기기), 운영체제,


              DBMS통신 등으로 구성된다. TPC 벤치마크는 여러 시스템구성요소를 조합한 구체적인


              시스템 구성을 평가 대상으로 하고 컴포터 본체만을 대상으로 하지 않는다.


      2) 컴푸터 성능 퍙가 기준의 중요성 및 의존도


           CPU 성능 > 메모리 성능 > 시스템간 연결 방식


   4. 속도 향상 성능 모델


      1) 고정부하에 대한 Amdahl의 법칙


         - 실시간 응답을 원하는 작업량과 문제의 크기가 이미 정해져 있는 응용 환경


      2) 스케일 문제에 대한 Gustafson의 법칙


         - 문제의 크기가 컴퓨터의 크기와 같이 증가하는 확장성있는 응용환경


      3) 한계 메모리 속도 향상 모델


         - CPU와 메모리 용량을 최대한 이용하기 위한 확장성 있는 응용환경

웹의 사용성(Usability)을 어떻게 평가할 것인가?

웹의 사용성(Usability)을 어떻게 평가할 것인가?

- NIST 기준을 중심으로 -


웹사이트 평가의 관점

요즘 여러 가지 형태의 웹사이트 평가가 이루어지고 있고 이에 대한 다양한 평가 모델과 방법이 제시되고 있다. 웹사이트의 평가기준은 어떻게 정해질까? 여기서 닭이 먼저 일까? 달걀이 먼저 일까? 하는 원초적인 질문을 가진다. 간단히 생각해보자. 우리는 어떤 웹사이트가 좋은 것인가를 미리 정의하고 웹사이트를 만들었는가? 아니면 성공한 웹 사이트로부터 좋은 웹사이트의 요소를 찾아내어 이를 정리하였는가? 어느쪽이 먼저라고 말하기 어렵다. 하지만 현재 일반적으로 행해지는 웹사이트 평가기준 들은 성공한 웹사이트의 사례에서 성공의 요소들을 정리하고 이를 기준으로 웹사이트를 평가하고자 하는 흐름이다.


네티즌들로부터 시작된 웹사이트 평가

웹사이트 평가는 네티즌들 사이에서부터 시작되었다. 디자인이 기분 좋은 사이트, 네비게이션이 쉬운 사이트, 분야별로 가치 있는 정보가 넘치는 사이트, 언제나 빠른 사이트, 언제나 느린 사이트 등으로 분류되어 알려져 왔고 이들 사이트를 기준으로 디자인, 성능, 기술, 컨텐츠 등에 대한 향상을 추구하여 왔다. 그 후 이러한 여러 요소들을 중심으로 종합적인 평가를 하게 되었고, 시험 평가 영역을 나누고 측정하고 영역별 가중치를 부여하기 시작하였다. 이러한 시도로 분류 되는 것이 해외의 경우 Webby Awards, 국내의 경우 월간 인터넷의 '한국의 베스트 웹사이트' 등이었다.



인터넷 비즈니스 평가와 웹사이트 평가 구분 되어야

요즘은 웹사이트 평가와 인터넷 비즈니스평가가 구분되지 않을 정도로 웹사이트 평가기준이 바뀌었다. 이런 배경에는 첫번째는 웹사이트 평가기준에 참조하는 성공한 웹사이트를 수익을 올린 사이트, 기업가치를 결정적으로 올린 사이트에 국한하였기 때문이다. 따라서 기존의 웹사이트 평가 요소들인 디자인, 성능, 기술, 컨텐츠 뿐만 아니라 소비자 보호, 사업전략, 서비스(오프라인포함)수준, 방문자 수 또는 회원 수, 매출 등의 비즈니스적인 평가요소 들이 추가되고 비중이 높아졌다. 다른 표현을 한다면 투자자 중심의 웹사이트 평가로 바뀐 것이다. 기존의 사용자 중심의 웹사이트 평가는 웹 사이트의 질적 향상을 유도하고 도움을 주었다. 그러나 현재와 같은 비즈니스 평가에 더 가까운 웹사이트 평가는 이를 가로막고 있다. 이제는 웹사이트 평가와 인터넷 비즈니스 평가는 다시 분류되어야 한다.



웹사이트 평가는 사용자 중심으로, 웹 비즈니스평가는 인터넷 기업평가로

우리는 인터넷을 항해하면서 발견한 정말 좋았던 사이트들을 기억하고 있다. 그런 사이트들이 비즈니스에서 흔히 말하는 '성공을 거두었는가?' 즉 '방문자수, 매출, 수익의 관점에서 이익을 창출하고 있는가?' 하는 것은 다른 문제이다. 인터넷 비즈니스 평가와 순수한 웹 사이트 평가는 머지 않아 다시 별도의 다른 길을 가게 될 것이다. 인터넷 기업 평가가 그 중의 한 흐름이다. 비즈니스의 수익모델, 경영, 마켓팅, 성장가능성, 기업신뢰도 등 보다 본격적인 평가기준들이 인터넷 기업 평가에 본격적으로 등장할 것이며 이는 순식간에 웹사이트 평가라는 틀 안에 숨어 있던 인터넷 비즈니스 평가요소 들을 끌어내어 흡수 할 것이다. 이제는 다시 원래의 웹사이트 평가로 돌아가야 한다. 웹사이트 평가는 말 그대로 방문자와 컨텐츠 제공자의 커뮤니케이션의 장인 웹 사이트 자체를 평가하는 것이다. 비즈니스의 포장을 뜯고 사용자 중심의 평가가 되는 것이다.



웹사이트 평가는 사용성과 고객기준의 가치성

우수한 비즈니스 성공 사이트의 성공요소와 관계없이 사용자가 느끼는 만족도를 기준으로 생각하면 의외로 간단한 결론에 다다른다. 평가 요소는 간단히 두가지 이다. 첫째. 얼마나 쉽고 기분 좋게 웹 사이트를 사용할 수 있느냐는 웹페이지의 사용성이다. 둘째, 사용자가 느끼는 정보 또는 서비스의 가치성이다. 이는 사이트의 제공자에 대한 투자자의 가치평가와는 매우 다른 성격을 가지고 있음은 쉽게 짐작할 수 있다.



사용성 평가는 보다 객관적일 수 있다

웹사이트에 대한 사용자 기준의 가치성은 사용자의 그룹, 요구하는 정보 및 서비스의 종류에 따라 매우 달라 질 수 있으며 매우 주관적일 수 있다. 따라서 대상 범위를 좁혀서 대개 동일한 목적을 가진 사용자 그룹에 대한 조사 형태로 이루어 질 수 있다. 그러나 사이트의 사용성 평가는 이에 비하면 훨씬 객관적이고 정량적인 측정이 가능하다고 생각된다. 하지만 사이트의 사용성 역시 사이트의 제공자가 목표로 하는 대상 방문자와 서비스의 종류에 따라 특이성이 존재한다. 따라서 여기에서는 일반 국민들을 대상으로 공공정보를 서비스하는 공공기관의 사이트에 대한 사용성 평가를 중심으로 설명하고자 한다.



사용성 평가는 기준과 지침이 있어야

한국정보통신기술협회에서는 '공공기관의 웹 구축 지침서'를 발행하였다. 공공기관들이 웹을 구축하는데 있어서 필요한 고려사항, 절차, 기술적 해석을 담고 있다. 그러나 웹 사이트의 사용성에 대해서는 부분적인 언급이 있으나 이를 별도로 상세히 정의하고 있지는 않다. 우선 기준과 지침이 있어야 평가를 할 수 있다. 정답표 없이 어떻게 채점을 할 것인가? 사실 이러한 사용성의 기준이나 지침을 마련하는 것은 기본적으로 인터넷 사용자 환경조사와 감성공학적인 통계와 연구가 뒷받침 되어야 한다.



NIST의 사용성 지침과 정량적 측정기준

우선적으로 우리는 미국 NIST(국립 표준 기술 연구소; National Institute of Standards and Technology)에서 제시한 웹사이트 사용성(Usability)에 대한 기술적 정량적 측정 메트릭스(Metrics)를 살펴 보자. NIST는 웹 사이트의 사용성에 대한 지침(Guidelines)들을 제공하고 이러한 지침들 중에 주관적인 부분들을 제외하고 html에서 기술적으로 검사할 수 있는 체크리스트를 제공하고 있다. 이러한 지침들은 웹사이트를 설계하고 구축하는 데 참조할 수 있으며, html등에서 기술적으로 검사할 수 있는 항목들은 사이트의 사용성 평가의 일부로 활용할 수 있을 것이다.


1. 사용성의 분류

사용성은 크게 아래의 6가지로 분류한다.

접근성
Accessibility 모든 사용자들이 물리적 환경에 구애받지 않고 웹사이트를 볼 수 있다는 것은 매우 중요하다. 웹 브라우져와 하드웨어 성능의 차이에 따라 어떤 사용자는 한정된 이용만 허용될 수도 있기 때문이다
성능
Perf ormance 사용자는 참을성이 없다. 따라서 그들이 사이트에서 필요로 하는 정보를 빨리 얻을 수 있도록 하는 것이 중요하다. 여기서는 많은 지연 요소로 인하여 사용성이 떨어지는 것을 막기위한 모든 배려가 이루어 졌는지를 검사한다
네비게이션
Navigation 많은 복잡한 사이트에서도 사용자 중심의 사이트맵이 제공되지 않는다. 따라서 사용자들은 사용하면서 자신이 이해한 맵을 만들어야 한다. 링크는 어떤 내용으로 연결 되는지 잘 설명되어 있어야 하며, 어떻게 이전에 방문했던 곳으로 갈 수 있는지도 잘 보여야 한다.
유지보수성Maintainability 사용자들은 시기 적절한 정보를 원하며 다른 정보와도 실제로 잘 링크되어 있는 것을 원한다. 이러한 것은 단지 유지보수차원의 문제는 아니다. 즉 설계에서부터 잘 고려되어야 하는 것이다.
가독성
Readability 사용자가 산만함 없이 페이지상의 중요한 정보를 쉽게 읽을 수 있어야 한다. 그래픽이나 에니메이션이 흥미를 유발하지만 좋은 것도 너무 많으면 산만하기 쉽다. 또한 한 페이지 이상의 정보도 너무 많으면 사용자가 여러 번 스크롤해야 한다.
양식의 사용
f orm Use
웹사이트에서 양식을 사용한다면, 사용자들이 이러한 양식을 작성하거나, 삭제하거나, 제출하는데 있어서 매우 쉽도록 배려하여야 한다.


2. 접근성

웹 사이트를 보고자 하는 사람은 누구나 볼 수 있어야 한다. 그러나 모든 사용자가 물리적으로 꼭 같은 환경 즉 꼭 같은 소프트웨어와 하드웨어를 가지고 있지는 않기 때문에 접근성을 세심하게 배려하지 않은 사이트를 보는데 장애를 느낄 수 있다. 다음의 리스트는 서로 다른 물리적 능력에 기인하는 접근성의 이슈 들이다.



차이점 이슈
인터넷 브라우져 프레임이 지원되지 않을 수 있으며 색상이 다르게 나타날 수 있다. 공공 웹사이트에서는 특정

브라우져 만의 기능을 사용하는 것을 피해야 한다.
인터넷 접속속도 많은 양의 그래픽 데이터를 다운 받는 시간은 장애가 될 수 있다.
하드웨어 플랫폼 모든 방문자가 오디오와 비디오를 쉽게 사용할 수는 없다.
Screen reader 접속 시각장애자가 스크린 리더를 이용할 때 해당 텍스트 설명이 없는 그래픽과 비디오는 접근이

불가능하다. 아울러 링크에도 적절한 설명이 있어야 한다.




2-1. 접근성의 기술적 체크리스트

기술적 정량적으로 체크 가능한 접근성의 요소를 기술한다. 이들은 해당 페이지의 html로부터 자동 또는 수동으로 검사할 수 있다.

Html 검사항목 중요 문제점
지침: 링크로 쓰여지지 않는 모든 이미지는ALT tags를 가지고 있어야 한다.

메트릭스(Metrics): 링크로 쓰여지지 않는 이미지가 ALT tags를 가지고 있지 않은 숫자 ALT tags 는 시각 장애자들에게 그래픽의 내용을 설명해 줄 뿐 아니라 그래픽 이미지의 전송 등에 장애, 내용파악의 어려움 등에 있어서 이미지의 내용을 전혀 파악 할 수 없다.
지침: 링크로 쓰여지는 모든 이미지는 ALT tags를 가지고 있어야 한다.

메트릭스(Metrics): 링크로 쓰여지는 이미지가 ALT tags를 가지고 있지 않은 숫자 ALT tags 는 시각 장애자들에게 링크의 내용을 설명해 줄 뿐 아니라 링크의 내용을 미리 이해하거나 유지보수에 도움을 준다.
지침: 모든 자바 에플릿은 ALT tags를 가지고 있어야 한다.

메트릭스(Metrics): ALT tags를 가지고 있지 않은 자바 에플릿의 수 ALT tags는 시각 장애자에게 자바에플릿의 내용을 설명해 줄뿐 아니라 작동 내용을 미리 이해하거나 유지보수에 도움을 준다.
지침: 모든 이미지 맵은 텍스트 앵커나 링크를 가져야 한다.

메트릭스 (Metrics): 텍스트 앵커를 가지지 않은 이미지 맵의 수 Text anchors 는 시각 장애자들에게 링크가 있음을 설명해주며, 일반 사용자들도 링크가 있는 이미지 맵을 쉽게 구별하고 그 내용을 미리 파악할 수 있다
지침: 프레임이 사용되었다면 noframe 옵션이 있어야 한다.

메트릭스(Metrics): noframe 옵션이 없이 사용된 프레임의 존재 여부 모든 브라우져가 프레임을 지원하지는 않는다.
지침: 기본 설정 외의 색상을 사용한다면 RGB 값만을 사용한다.

메트릭스(Metrics): nonRGB 값이 사용된 색상의 수 RGB 색상 형식은 모든 하드웨어에서 기본적으로 잘 보여진다.
지침: BG color와 TEXT color속성은 항상 조합적으로 지정되어야 한다.

메트릭스(Metrics): BG color와 TEXT color속성은 항상 조합적으로 지정되었는지 여부 만약 배경색과 문자색을 어느 한 쪽만 지정하였다면 특정 브라우져의 기본 색상 때문에 읽을 수 없게 될 수 도 있다.



3. 성능

사용자들은 다양한 접속환경과 다양한 하드웨어 성능을 가지고 사이트에 접속한다. 많은 그래픽과 한 페이지에 집중된 지나치게 많은 정보는 사용자가 페이지를 다운 받는 시간을 지연시킬 것이다. 사용자들은 20에서 30초가 걸리는 시간을 기다리려 하지 않거나 주의가 분산될 것이다.

3-1. 성능의 기술적 체크리스트

다음은 기술적 정량적으로 체크 가능한 성능의 요소를 기술한다. 이들은 해당 페이지의 html로부터 자동 또는 수동으로 검사할 수 있다.

Html 검사항목 중요 문제점
지침: 그래픽을 포함한 페이지의 사이즈는 30K 이내로 한다.

메트릭스(Metrics): 페이지의 사이즈가 30K 가 넘는 페이지의 수 페이지의 사이즈가 30K 가 넘는 페이지는 저 수준의 접속 사용자의 경우 20~30초가 소요될 수 있다.
지침: 이미지에는 이미지의 폭과 높이에 대한 정보가 포함되어야 한다.

메트릭스(Metrics): 이미지의 폭과 높이 정보가 포함되어 있지 않은 이미지의 수 폭과 높이에 대한 정보가 포함된 이미지는 사이즈를 계산하여야 하는 이미지보다 훨씬 빨리 로드 될 수 있다
지침: 이미지는 JPEG f ormat을 쓰지 않는다.

메트릭스(Metrics): JPEG f ormat 을 사용한 이미지의 수 모든 브라우져가 JPEG를 지원하지는 않는다.
지침: Banner 의 사이즈는 500 pixel이 넘지 않도록 한다.

메트릭스(Metrics): 500 pixel이 넘는 베너의 수 브라우져 페이지의 기본 사이즈는 대개 500 pixel의 폭을 가진다. 따라서 500 이상의 폭을 가지면 가로 방향으로도 스크롤 해야 할지 모른다.



4. 네비게이션

모든 수준의 컴퓨터 사용자가 그들이 원하는 정보를 찾기 위해 웹사이트를 쉽게 돌아다닐 수 있도록 쉬운 네비게이션을 제공해야 한다. 네비게이션 테스트는 최종적인 사용자 테스트와 병행하여 수행할 수 있다. 하지만 모든 소프트웨어 시험에서그러하듯이 커버리지 테스팅이 중요하다. 따라서 웹사이트 상의 모든 가능한 네비게이션 경로를 분석하고 하나도 빠짐없이 검사하여야 한다. 이때 패스 리버스도구를 이용하는 것이 유용하다.

4-1. 네비게이션의 기술적 체크리스트

기술적 정량적으로 체크 가능한 네비게이션의 요소를 기술한다. 이들은 해당 페이지의 html로부터 자동 또는 수동으로 검사할 수 있다.

Html 검사항목 중요 문제점
지침: 모든 페이지는 최소한 한 개의 링크는 있어야 한다.

메트릭스(Metrics): 하나의 링크도 없는 페이지의 수 네비게이션에서의 막다른 골목이 될 것이다. 브라우져상의 '뒤로' 버튼 만이 유일한 탈출구인 셈이다.
지침: 링크에는 브라우져에서 기본설정된 색상을 이용하여야 한다.

메트릭스(Metrics): 링크에 다른 색상을 이용하였는지 여부 사용자들은 푸른색에 밑줄 쳐진 부분을 기본적으로 링크로 인식한다.
지침: 링크에는 적당한 설명이 부가되어야 한다.

메트릭스(Metrics): 링크의 설명에 사용된 단어가 2개 이하이거나 10단어 이상인 링크의 수 링크에 "click here"라는 단순한 기본 설명은 사용자가 무엇을 기대해도 좋은지 가이드를 주지 못한다. 또한 두줄에 걸쳐 표시되는 링크도 사용자에게 1개의 링크인지 2개의 링크인지 혼란을 준다.
지침: 링크는 숨겨져서는 안된다.

메트릭스(Metrics): 링크 전단 또는 후단에 line break 가 없는 링크의 수 의도적이든 실수든 사용자를 당황하게 한다. 특히 이미지 링크의 경우 화면 상에 잘 안보이면 제대로 지우지 않는 경우가 있다.
지침: 링크를 새로운 창을 뛰워서 열지 않도록 한다.

메트릭스(Metrics): 새로운 창을 띄우는 링크의 수 능숙한 사용자가 아닌 경우에 새로운 창이 자동적으로 생겼을 때 혼란을 일으킬 수 있고 다른 사이트로 네비게이션 하는 경우가 아니라면 바람직하지 않다.



5. 유지보수성

웹사이트를 개발하는 것 뿐만 아니라 지속적으로 유지 관리하는 것도 중요하다. 웹사이트를 설계하는 사람은 웹사이트의 생명이 다할 때 까지 웹 사이트를 쉽게 확장하고 유지할 수 잇는지를 고려하여야 한다. 웹사이트 유지의 중요 이슈 중의 하나는 얼마나 쉽게 다른 서버로 이식할 수 있느냐 하는 것이다. 사이트 내에서 상대적인 링크를 사용하면 이식이 쉬워진다. 또 다른 이슈는 자주 업데이트 되는 부분을 쉽게 교체할 수 있도록 적당한 덩어리로 분리되어 있는가 하는 것이다. 즉 적당한 수준에서 쉽게 업데이트 할 수 있도록 구성하는 것이 중요하다. 웹사이트의 확장은 설계 단계에서부터 세심하게 고려하여야 한다. 이미지와 아이콘을 디자인 할 때부터 새로운 이미지나 아이콘을 쉽게 바꾸거나 대체할 수 잇도록 고려하여야 한다. 만약 정보의 시간성이 중요하다면 모든 페이지에 최근 업데이트 날짜를 반드시 명기하여야 한다. 또한 접촉할 사람의 전화와 이메일을 명시하여야한다. 만약 주기적으로 정보를 갱신하거나 홈페이지를 개편한다면 이러한 일정도 공시하는 것이 좋다.

5-1. 유지보수성의 기술적 체크리스트

기술적 정량적으로 체크 가능한 유지보수성의 요소를 기술한다. 이들은 해당 페이지의 html로부터 자동 또는 수동으로 검사할 수 있다.

Html 검사항목 중요 문제점
지침: 가능한 한 상대적인 링크를 이용한다.

메트릭스(Metrics): 절대적 링크의 수 내부 링크의 경우 상대적인 링크를 사용하는 것이 이식성이 좋다. 현재의 서비스가 확장되는 사이트의 부분이 될 수도 있고 서버를 옮길 수도 있다.
지침: 내부 또는 외부로 연결된 링크가 끊어져서는 안된다.

메트릭스(Metrics): 끊어진 링크의 수 내부 링크의 경우 사이트의 구조 변경시 관련된 링크를 완벽히 끊어진 곳이 없도록 한다. 삭제된 페이지는 반드시 서버 상에서 제거하여 잘못된 링크가 양산되는 것을 막아야한다. 외부링크도 주기적으로 체크하여 반영하여야한다. 고객은 내부든 외부든 같이 평가한다.
지침: 모든 페이지에는 Head tag가 있어야 한다.

메트릭스(Metrics): Head tag가 없는 페이지의 수 모든 페이지에는 페이지 제목, 작성자, 작성일을 포함한 태그가 있다. 이러한 페이지 제목은 사용자가 사용 시 브라우져 상에도 표시되고, 나머지 정보는 다른 사람이 사이트를 관리하게 되더라도 사이트의 정보를 줄 수 있다.



6. 가독성

웹의 기능성은 하루가 다르게 좋아지고 있다. 멀티미디어를 이용한 웹페이지 마다 멀티미디어를 이용하여 호소력을 높이고 있다. 하지만 부적절하게 사용된 경우에는 오히려 가독성을 떨어뜨리고 있다. 기술적/ 정량적 체크에서는 에니메이션이나 블링킹 텍스트의 량을 측정하는 정도이다. 하지만 이러한 기술의 과도한 사용은 웹사이트를 직관적으로 이해하기 어렵게 만든다는 것은 사용자 시험을 통하여 입증되었다. 페이지의 정보 밀도도 페이지의 가독성에 영향을 미친다. 인쇄매체의 경우에도 페이지의 여백과 강조 부분이 중요하듯이 백색 공간과 강조 확대 글씨체부분이 중요하게 이용된다. 링크는 웹 페이지에 있어서 중요한 요소중의 하나이고 이를 잘 보이게 하는 것도 필요하다. 하지만 너무나 많은 링크와 기본 설정보다 작은 글씨들로 채워진 페이지는 점점 읽기 힘들게 만든다. 웹 페이지의 길이는 최대 3~4회 스크롤을 최대로 하는 것이 좋다. 또한 이런 가운데 수평의 선들이 들어가면 더욱 혼란스럽게 된다. 가독성은 결국 사용자를 통한 주관적이고 정성적인 평가 결과가 많이 필요한 부분이다. 따라서 가독성의 기술적 체크 부분은 단지 참고 사항으로 하여도 좋다.

6-1. 가독성의 기술적 체크리스트

기술적 정량적으로 체크 가능한 가독성의 요소를 기술한다. 이들은 해당 페이지의 html로부터 자동 또는 수동으로 검사할 수 있다.

Html 검사항목 중요 문제점
지침: 웹페이지의 밀도를 제한하도록 노력하여야 한다.

메트릭스(Metrics): 링크를 표현하는 전체 단어 수 / 전체 단어 수 한 페이지에 링크가 상대적으로 많으면 많을수록 특정 링크를 인식하기 어려워진다.
지침: 페이지의 scrolling text, blinking text, 그리고 marquee style text를 제한하라.

메트릭스(Metrics): 에니메이션 되는 개체의 수 하이라이팅 (as in scrolling, blinking, marquee style)은 일정 수준을 넘을수록 사용자가 중요한 정보에 집중하거나 일반적인 텍스트를 읽기 어렵다.



7. 양식의 사용

양식은 방문자의 정보를 취득하는 좋은 방법이다. 그러나 양식을 입력하는 작업은 사용자에게 적지 않은 부담을 준다. 따라서 사용자의 편의성을 최대한 고려하여야 하는 부분 중의 하나가 이 부분이다. 하지만 이러한 지침들을 정량적으로 측정하는 부분은 아직 많이 발전하지 않았다.

- 어떤 정보를 넣어야 할지 명확하게 알 수 있도록 항목명을 기록한다.

- 어떤 필드가 필수적인지 명확히 알 수 있도록 한다.

- 어떤 특정형식으로 입력해야 한다면 (생년월일, 주민등록번호 등) 이를 분명히 알 수 있도록 하여야 한다.

- 약 양식이 스크롤 되어야 한다면 상부와 하부에 모두 '제출', '삭제' 버튼을 넣는다.

- 양식에 가로지르는 수평선을 넣지 않는다. 사용자는 거기까지가 끝으로 인식할 수 있다.

- 자동적으로 알 수 있는 어떠한 것이라도 (날짜, 생년눨일, 주소 등) 다시 입력하도록 하지 않는다.

7-1. 양식사용의 기술적 체크리스트

기술적 정량적으로 체크 가능한 양식사용의 요소를 기술한다. 이들은 해당 페이지의 html로부터 자동 또는 수동으로 검사할 수 있다.

Html 검사항목 중요 문제점
지침: 양식을 완료하고 완성된 양식을 보내는 기능을 포함하여야 한다.

메트릭스 (Metrics): '제출' 또는 '보내기' 버튼이 있는지 여부 사용자는 양식을 완료하고 보내진 것으로 인식할 수 있다.
지침: 양식을 작성 중 양식을 새로 깨끗이 지우는 기능을 포함하여야 한다.

메트릭스 (Metrics): '삭제' 또는 '새로고침' 버튼이 있는지 여부 사용자가 쉽게 양식을 재작성하는 방법을 모를 수 있다.



웹사이트의 품질이라는 접근방식

지금까지 미국의 공공부분에 대한 웹 사용성 지침과 기술적인 정량적 측정방법에 대한 자료를 살펴보았다. 여기에는 공공적 측면에서 장애인, 웹 환경의 약자에 대한 배려가 너무 지나치지 않은가 할 정도여서 다소 한국적 정서에 맞지 않는 느낌이 들기도 한다. 하지만 정보화 시대의 정보독점, 정보불평등의 이야기가 심심찮게 나오는 요즘 우리나라도 공공정보 부분에서라도 참조할 점이 있을 것 같다. 지나치게 기술적, 정량적 측정이 가능한 부분에 집착하는 형태로 전개되기는 하였지만 비즈니스 목적과 영역에 따라서 사용자 만족도 조사와 같은 정성적 평가도 더불어 해야 함을 이야기 하였고 많은 민간의 연구가 병행된 점을 알 수 있다. 이러한 배경에는 비즈니스적 접근보다는 소프트웨어공학적인 접근, 비즈니스의 성공요소보다는 웹사이트의 품질이라는 접근방식이 근간이 되었음을 알 수 있다.



우리나라 실정에 맞는 기준과 지침의 개발필요

우리의 웹 사용환경은 미국과 다르다는 것은 명확하지만 구체적인 사용환경에 대한 상세한 정보는 부족한 형편이다. 우선 공공기관을 중심으로 대상이 되는 국민 전체의 사용환경에 대한 오늘과 미래를 조망하고, 공공 웹사이트의 기본적인 사용성에 대한 정책과 지침이 확정되어 공공 웹사이트의 설계단계에서부터 일반 사이트에서도 기본적인 사용성에 대한 지침을 사전에 확정하는 것이 바람직할 것이다. 인터넷비즈니스의 총아라고 할 수 있는 전자상거래, 쇼핑몰이나 금융사이트 보다 더 무겁고 화려한 공공기관의 웹사이트에 대한 인식의 전환이 필요하다.



위니비즈의 웹사이트 품질측정 메트릭

위니비즈는 웹사이트 품질의 관점에서 접근하여 실증적, 정량적 메트릭(Metrics)을 제공하고 있다. 웹사이트 전체의 끊어진 링크, 끊어진 앵커, 기준 이상의 네비게이션이 필요한 깊은 페이지, 규모 이상의 크기를 가진 느린 페이지, 일정기간 이상이 경과한 오래된 페이지, 제목이 누락된 페이지, 속성이 누락된 이미지와 개체들을 분석 측정하여 사용성의 여러 측정 가능한 요소에 대한 자료를 제공하고 있으며, 사용자의 관점에서 측정대상 사이트의 주기적인 첫 페이지 속도측정, 핵심 프로세스 속도측정, 핵심 프로세스 부하 속도측정을 하여 자료를 제공하고 있다. 이러한 정량적 메트릭은 웹사이트의 품질측정 또는 무결성 측정, 성능 측정의 형태로 표현 될 수 있으며 웹사이트 평가, 웹비즈니스 평가, 인터넷 기업 가치 평가의 요소가 될 것이다.

CAD/CAM 시스템의 평가기준.

CAD/CAM 시스템의 평가기준.




지금까지 다양한 유형의 CAD/CAM 시스템을 설명하였다.
다양한 공급자, 소프트웨어 개발자, 하드웨어 제작자 등에 의한 노력 결과로 광범하게 다양한 시스템이 나오게 되었지만, 사용자의 선택은 더욱 어렵게 되었다. CAD/CAM 선택을 논의할 때는 가능한 선택을 알기 위해 긴 목록의 지침을 개발하고 있다. 이들, 목록은 전형적으로 가격 기준에서 시작하여, 시스템 성능, 능력 시험을 위해 선택된 샘플이나 벤치마킹(benchmark)으로 끝난다. 그 중간에 사내 기존 컴퓨터와의 호환성 요건, 시스템 사용을 계획하는 예상 부서, CAD/CAM 시스템 공급자의 신뢰성 등과 같은 다른 요인들이 수록된다. 부서(또는 조직체)마다 현저히 다른 많은 선택 지침과는 대조적으로 기술 평가 기준은 거의 같다. 이들 기준은 보통, 기존의 CAD/CAM 이론과 기술에 국한되며 그것은 다음과 같다.


시스템 고려사항


-하드웨어
하드웨어에서 고려해야 할 주요 문제 중 하나는 관련 컴퓨터가 얼마만큼 개방적이고 표준에 맞는가 하는 문제이다. CAD/CAM 시스템에서 활용되는 VAX나 SUN 워크스테이션과 같은 일부 표준 컴퓨터는 그 소프트웨어의 성능이 강화되었다. 그러나 이들 컴퓨터는 원래 하드웨어의 일부 기능을 사용 불능의 상태로 할 우려가 있으며, 제3자 소프트웨어를 지원하는 CAD/CAM 컴퓨터를 사용하지 못할 수가 있다. 개방형인 하드웨어 구조는 시스템 확장성과 앞으로 필요한 네트워킹에 중요하다. 시스템에 의해 지원되는 주변 장치의 종류 역시 시스템상에서 수행되는 설계 작업의 문서화 단계에서 중요하게 된다. 두 가지 인기 있는 하드웨어 구성은 디스크 있는 워크스테이션과 디스크 없는 워크스테이션이다. 디스크가 있는 워크스테이션에서는 각 워크스케이션이 독립적이 되도록 충분한 국부 디스크 공간과 기억 장치를 갖는다. 디스크가 없는 워크스테이션에서 각 워크스테이션은 서버라고 불리는 중앙 컴퓨터에 연결되는데, 이 중앙 컴퓨터는 사용자의 파일과 응용 프로그램을 저장할 뿐만 아니라, 실행할 수 있는 충분히 큰 디스크와 기억 장치를 갖춘다. 디스크 없는 구성에서는 반응 시간의 증가를 방지하기 위해 각 워크스테이션이 교환(swapping) 디스크를 갖추도록 하는 것이 바람직하며, 이러한 점은 CAD/CAM에서 더욱 중요하다.


- 소프트웨어
소프트웨어의 세가지 주요 요소는 소프트웨어가 실행되는 운영 체계의 유형과 사용자 인터페이스의유형, 그리고 문서의 질이다. 첫 번째 요인은 일반적으로 제3자의 소프트웨어를 실행하는 컴퓨터 지원 공학 (CAE)수행에 중요하다. 또한, 새로운 CAD/CAM 사용자들이 사전 지식이 없을 경우에는 비표준 운영 체계보다는 표준 운영 체계를 가르치는 것이 심리적으로 더 용이하다 표준 체계는 사내 소프트웨어 개발이 필요할 때도 중요하게 된다.사용자 인터페이스의 종류를 평가할 때는 그 인터페이스가 경험 있는 사용자와 초보자 모두를 수용할 수 있는지의 여부를 고려해야 한다. 예를 들어, 메뉴 구동 시스템은 초보자가 선호하는 반면, 매일매일 실력이 향상되는 운영자에게는 불편스런 딱딱한 구조가 될 수 있다.어떤 시스템은 메뉴 구동 인터페이스와 비메뉴 구동 인터페이스를 모두 제공하기도 한다. 또한, 맞춤 메뉴(customized menu)를 생성하는 능력도 조사되어야 한다. 소프트웨어 문서의 질은 관련 설명서를 읽어 보는 것으로 쉽게 평가할 수 있을 것이다. 조사해 보아야 할 가장 중요한 문제는 문서화의 용이성과 온라인 도움말 기능의 유무이다.


- 보수유지
하드웨어 구성의 수리와 소프트웨어 갱신은 전형적인 보수 유지 계약의 대부분을 차지한다. 이러한계약의 연간 금액은 상당하므로 (초기 시스템 비용의 약 5~10%에 해당한다), 초기 자본 투자에 추가하여 초기 투자비용 결정에 고려되어야 한다. 다양한 공급자는 즉시 서비스에서 전화 중심의 서비스에 이르기까지 다양한 유형의 계약을 제공한다.


- 공급자 지원 및 서비스
공급자 지원은 전형적으로 훈련, 현장 서비스, 기술 지원 등을 포함한다. 대부분의 공급자는 필요한 경우에 현장 교육 과정을 제공한다. 어떤 사내 기술 전문가도 활용할 수 없을 때는 고객의 기술 문제에 대한 공급자 응답 센터의 시의적절한 응답이 시스템 운영 초기에 중요하다. 


형상 모델링을 위한 능력


- 표현기법
CAD/CAM 시스템의 형상 모델링 모듈은 시스템의 심장으로서, 그의 응용 모듈은 시스템이 지원하는다양한 표현과 직접 관련되고 또 그것들에 의해 제한된다. 와이어프레임, 곡면 및 솔리드는 그 모델링의 세가지 종류이다. 대부분의 상업적인 CAD/CAM 시스템은 이들 유형을 제공한다. 그러나, 개개의 표현에서 지원되는 다양한 엔티티를 고려하는 것이 중요하다. 다양한 표현과 응용간의 접합이 핵심적인 과제이다.


- 좌표계와 입력 방법
설계사에게 형상 모델을 만들어 낼 수 있는 적절한 유연성을 제공하려면 다양한 유형의 좌표계와 좌표입력 방법이 제공되어야 한다. 작업 좌표계는 좌표계의 한 가지 예이다. 어떤 구조들의 적절한 평면을 정의할 수 있는 설계사의 능력은 표준 직교 평면(정면, 평면, 우측면)을 따르지 않는 면들의 생성에 필요하다. 좌표 입력은 직교 좌표계, 원통 좌표계, 구형 좌표계의 형식을 취할 수 있다.


- 모델링 엔티티
시스템이 표현 방식을 지원한다는 사실을 아는 것으로만 충분치 않고, 표현 방식이 제공하는 구체적인엔티티를 아느 것이 중요하다. 이러한 엔티티를 생성, 검증, 편집할 때의 난이도가 평가시 고려되어야 한다.


- 형상 편집 및 조정
세 가지 표현 유형을 위해 이러한 형상 정의 기능들이 있어야 한다. 편집 기능은 교차, 트리밍, 투영 등을 포함하며, 조정은 이동, 회전, 복사, 대칭 복사, 오프셋, 크기 변환, 속성 변경 등을 포함한다.


- 그래픽스 표준 지원
형상 모델의 데이터 베이스가 한 시스템에서 다른 시스템으로 전이되기 위해서는 두 시스템이 서로데이터를 교환할 수 있도록 표준을 가지고 있어야 한다. 이러한 표준은 하나의 조직에 다양한 시스템이 존재하거나 공구, 지그, 고정 장치 설계도가 외부로 반출되거나 또는 NC 파트 프로구렘의 생성을 위해 중요하다. 또한, 그래픽스 표준은 CAD/CAM 데이터베이스를 일관성이 없게 하거나 오류를 도입할 가능성이 있다는 점에 유의해야 한다.


  설계문서


- 공학도면의 생성
형상모델이 생성된 후, 보통 공학 도면이나 청사진을 만들기 위해 표준 제도 작업이 수반된다. 다양한 관측 방향(보통 평면도, 전면도 및 우측면도)에 따라 적절한 도면 레이아웃으로 만들어진 다음에 치수가 부여되고 숨은선이 제거되거나 접선화되며 공차가 지정되고 일반적인 추 레이블이 추가된다. 이러한 활동은 시간을 많이 소모한다. 공학 도면을 생성하기 위해서는 형상 모델을 생성하는 것보다 보통 2~3배의 시간이 더 소요된다.


응용


- 조립(모델 합치기)
개별 부품을 가지고 조립품과 조립 도면을 생성하는 것은 필수적인 과정이다. 연구를 필요로 한 두 가지 문제는 조립 과정과 만들어진 조립품에 대한 다듬기이다.


- 설계 응용
질량 특성 계산, 공차 분석, 유한 요소 모델링 및 해석, 사출 모델링 해석, 기구 해서 및 시뮬레이션 등과 같은 응용을 위한 설계 패키지가 있다. 평가되어야 할 항목은 이들 패키지의 능력, 이들 패키지와 형상 데이터베이스간 통합과 인터페이스, 패키지가 사용하는 표현 기법 등이다. 어떤 패키지는 어색한 입력을 요구하기도 하며, 다른 패키지는 결과를 화면에 표시할 때 부적절한 방법을 사용하기도 한다.


- 제조 응용
가능한 보편적인 패키지는 공구 경로 생성 및 검증, NC 파트 프로그래밍, 후처리(post processing), 컴퓨터 지원 공정 계획, 군분류 기술(group technology), 컴퓨터 통합 생산에의 응용, 로봇 시뮬레이션 등이다. CAD와 CAM 응용이 진정으로 통합되도록 시스템에 의해 보장되는 것이 중요하다.


- 지원되는 프로그래밍 언어
시스템이 지원하는 프로그래밍 언어가 어느정도 다양한지 조사하는 것이 중요하다. 그래픽스 명령어가 프로그래밍 언어에서 사용될 때는 그 문법에 주의해야 한다. 만약, 문법이 각 경우마다 현저히 다를 때는 사용자가 혼동하게 된다. 

소프트웨어 품질 등급 부여 방안 연구





소프트웨어 품질 등급 부여 방안 연구

 

 

김 재 웅° 이 공 선   정 영 은

 

 

한국정보통신기술협회 IT시험연구소 S/W시험센터

 

 

A Study on the Method for Software Quality Grade

Jae-Woong Kim° Kong-Sun Lee   Young-Eun Jung

TTA ITTL SQEC

{jwkim, kslee, yejung}@tta.or.kr

 

 

요   약

 

  본 연구에서는 소프트웨어 품질 평가에 관한 사용자들의 관심이 증가함에 따라 현재 TTA의 S/W시험센터에서 수행하고 있는 소프트웨어 인증제도에 대해 제기된 일괄적인 인증 마크 부여와 인증 제품의 우열을 평가할 수 있는 기준의 부재 등에 대한 문제점을 개선하기 위하여 상대적 기준과 절대적 기준을 고려하여 제품에 등급을 부여할 수 있는 방안에 대해 연구하였다.

 

 

 

1. 서론



  소프트웨어의 용도가 확대되고 중요성이 점점 증가함에 따라 품질관리에 대한 요구가 한층 커지고 있다. 특히 최근의 경우에는 소프트웨어 오류가 많은 재산 피해로 직결되는 만큼 고품질 소프트웨어는 정보통신 사회의 필수 불가결한 요소로 자리잡아 가고 있다.


  현재 TTA의 S/W 시험센터에서는 국내 소프트웨어 개발업체의 품질에 대한 인식을 제고하고, 소프트웨어 제품의 품질을 향상시켜 소프트웨어 산업을 발전시키기 위하여 국제 품질 표준에 근거한 품질 평가모듈에 따라 소프트웨어 품질 시험 인증 서비스를 2001년부터 수행하고 있다. 신청된 S/W들은 평가모듈에 제시된 품질 기준을 만족하였을 경우 “Good Software"라는 인증 마크가 부여된다. 그러므로 인증 마크가 가지는 의미는 적정수준의 품질을 만족시켰음을 의미할 뿐, 최고의 품질을 보증하는 것은 아니다. 그러나 최종사용자들은 인증 마크가 부여된 S/W들이 최고의 품질을 가지고 있는 것으로 오인하여 인증 제품에 대한 불만을 토로하고 있다. 또한 동일한 분야에서 인증마크를 획득한 S/W에 대해 우열을 가릴 객관적 기준이 없다는 것에 대해 문제를 제기하고 있다. 따라서, S/W시험센터에서는 이러한 소비자들의 욕구를 해결하기 위해 S/W의 일괄적인 인증 마크 부여를 지양하고, 상대적 기준과 절대적 기준을 마련하여 S/W 품질등급을 부여하는 방안을 연구 중에 있다.


  본 논문에서는 S/W시험센터에서 고려하고 있는 품질 등급 부여 방안과 적용 사례에 대하여 기술하고자 한다. 2장에서는 소프트웨어 제품 품질등급 부여와 관련된 해외 선진기관의 적용방안과 소프트웨어 제품 품질등급 부여가 개발업계 및 소비자에게 미치는 영향에 대해 분석한다. 3장에서는 소프트웨어 제품 품질등급 부여 방안을 제시하고, 4장에서 적용사례의 결과를 분석한다. 마지막으로 5장에서는 결론과 향후 연구과제에 대해 기술한다.




2. 관련 연구




2.1 해외 동향


소프트웨어 품질 등급을 부여하고 있는 기관들에 대해 조사하여 보았다.




2.1.1 TÜViT




 여기서는 ISO 12119나 14598에 근거한 테스트 절차를 마련하여 소수점 자리도 포함하는 1에서 6까지의 점수제를 도입하는 독자적인 품질등급 평가체계를 도입하였다. TÜViT 고객사중 하나인 ComputerBild (http:// www.computerbild.de)사의 의뢰로 이러한 판정등급 시스템을 마련한 바 있다. 이 시스템은 중요도 스킴에 따라 점수를 부여하는 인증검사라 할 수 있는데, 1.00 에서 6.00 까지의 점수를 가격대비 성능을 한눈에 알아볼 수 있도록 인덱스를 정해 점수화시킴으로써 소프트웨어 제품에 대한 가격대비 성능을 소비자가 이해하기 쉽도록 도움을 주고 있다.


sehr gut / gut / befriedigend / ausreichend / mangelhaft / ungenugend 는 각각 최우수 / 수 / 우 / 미 / 양 / 가 로 등급을 부여하는 것이다.


MS Office의 경우 적합성테스트(conformity) 만을 고려할 경우 "적합 / 부적합" 기준을 충족시키지 못했으므로 "부적합" 판정을 받아 이 평가시스템에 따라 점수를 매긴 결과 1에서 6까지의 등급중, "등급3"을 받는 결과가 나왔다.




2.1.1 브라질 CTI




브라질에서는 CTI가 브라질 소프트웨어 산업에서 소프트웨어 품질 평가 서비스를 제공하는 주된 역할을 수행하고 있다. 여기서는 ISO/IEC 9126과 ISO/IEC 12119및 ISO/IEC 14598 초안에 기초를 두고 4598 MEDE-PROS를 개발하였다. 체크리스트 위주의 평가방법은 MicroScope와 유사한데 계속 수정작업을 통해 현재 100개 이상의 설문을 보유하고 있다. 이 방법은 제품명세, 문서화, 프로그램 및 데이터를 사용자의 관점에서 ISO/IEC 12119에 따라 평가한다. 이 평가방법에서 주로 강조하고 있는 평가항목은 소프트웨어의 기능성과 신뢰성이다. 기능성과 신뢰성에 대해 9의 가중치를 부여하고 있고, 유지보수성과 사용성에 대해 8, 효율성에 대해 7, 이식성에 대해 5의 가중치를 부여하고 있다. 각각의 평가 항목에 대해서는 만족정도에 따라 A, B, C, D, I의 등급을 부여하고 10, 7, 4, 1, 0의 점수로 환산한다. 이 평가방법은 브라질 소프트웨어 산업협회 (ASSESPRO)에서 부여하는 올해 최고의 소프트웨어 제품상을 선정하기 위해서 활용되고 있다[5].




2.2 소프트웨어 품질 등급 부여 효과




  S/W시험센터에서 소프트웨어 품질 등급을 부여할 경우 공적 신뢰성을 가진 주체에 의한 등급화, 차별화는 시장 경쟁을 촉진하고, 등급 그 자체가 지향해야 할 품질의 레벨을 시사하는 비전의 기능을 수행한다는 장점이 있다. 또한 제품에 대한 정보가 부족한 소비자에게 가이드라인 제시해주고, 개발업체들은 소프트웨어의 연구, 개발, 생산과정에서 이용자를 중심으로 삼는 시장지향주의라는 중요한 조류를 진작시킬 수 있다. 우수한 소프트웨어를 생산하지 못하는 기업의 퇴출을 앞당길 수 있다. 퇴출할 기업을 조기에 가시화함으로써 사회전체가 지불하는 거래비용(overall social transaction cost)을 줄이고 산업전체의 경쟁력 강화, 자원의 배분을 최적화하는 효과를 가져올 수 있다.


  그러나 소프트웨어는 작동되는 하드웨어나 운영체제에 따라 성능의 변화가 발생할 수 있고, 대상 소프트웨어를 S/W 분류에 따라 분류하기가 어렵기 때문에 문제가 발생할 수 있다. 또한 소프트웨어를 빠르게 개발하기보다 완벽하게 개발하려고 노력할 경우 새로운 기술 개발을 저해할 가능성이 있고, 시장 확보 경쟁에 뒤쳐져 국내 소프트웨어 업체들의 경쟁력을 잠식할 가능성도 존재한다.




3. 소프트웨어 품질 등급 부여 방안




  객관적인 품질등급 부여를 위하여 개발한 품질 등급 프로세스는 그림 1과 같이 4 단계로 구성된다. 제품 유형 식별 과정은 동종의 우수 소프트웨어를 선정하는 과정을 포함한다.


          






3.1 비교대상 S/W 선정




  소프트웨어 등급을 부여하기 위해서는 동일한 도메인에 속하는 제품들을 비교 평가 대상으로 하여야 하므로 우선 제품의 유형을 분류하는 것이 필요하다. 그 후에 제품을 평가하기 위한 품질 모델을 정의하여야 하는데 본 연구에서는 S/W시험센터의 평가 모델을 참조하였다. 등급 부여라는 것이 동일한 도메인의 제품들을 비교하는 것이므로 상대 평가를 수행하는 것이 대상 제품의 포지셔닝을 명확하게 파악하는데 도움이 되므로 상대 평가를 수행하는 것으로 원칙을 정하였다. 물론 현재 틈새시장을 고려하여 출시되는 제품들에 대해서는 비교 대상 제품이 존재하지 않으므로 절대 평가를 수행할 수 있다. 상대 평가를 수행할 경우에는 비교대상 S/W의 선정에 따라 전혀 다른 결과가 나타날 수 있으므로 대상 S/W를 선정하는데 많은 주의가 필요하므로 다음과 같은 선정 기준을 사용하여 선정할 수 있다.


  - 시장 점유율 높은 제품


  - 사용자 평판도 높은 제품


  - 절대평가 등급 높은 제품




3.2 평가항목 선정 및 가중치 부여 방안




  품질모델에 정의되어 있는 평가항목으로부터 제품이 속한 유형에서 평가 대상이 되는 항목을 선정한다.


평가항목은 S/W 특성에 따라 중요 항목에 차이가 있으므로 다음을 고려하여 선정한다.


  - S/W의 특성을 고려한 항목


  - 신청업체의 요청 항목


  - SQEC에서 수행한 동종의 S/W 시험 결과 이용


  - 시험원들의 경험에 의한 선정


  - 전문가 그룹에서 선정한 항목




  또한 제품 분류에 따른 평가항목별 중요도를 고려하여 가중치를 부여한다. 예를 들어 ISP/IEC 14102에서는 다음과 같은 평가 및 선정 방법을 제시하고 있다[4].





































[표 1)] ISO/IEC 권장 가중치 도출 방법


평가 및 선정 방법


주요 특징


비용위주의 평가법


경제적 기준에 따른 평가


점수위주의 평가법


정량화된 평가값 부여


Borda 방법


순위위주의 평가법


특성별 평가법


특성별 우선순위 평가


Condorcet 방법


쌍대비교에 의한 평가


Fishburn 방법


선호정렬법


Dodgson 방법


선호측정법


나열식 평가법


기준비교 평가방법


구조적 방법


계층적 분석 방법




  본 연구에서는 다음을 참조한 가중치를 부여하여 수행하였다.


  - TTA의 소프트웨어 유형별 가중치 부여 자료[1]


  - ISO/IEC 9126-3 부특성별 가중치 부여 자료[2]


  - 축적된 TTA 시험결과 DB 분석


  - AHP 방법론을 이용한 가중치 부여 자료[3]


  - CTI 등 해외 시험기관의 가중치 부여 자료[5]






3.3 품질 등급 부여 방안




  평가 항목별 메트릭에 따라 품질 측정을 하고, 측정치에 가중치를 부여한 후 평가 등급 점수를 환산하고 환산점수를 합산한다.



  그 후 선정되었던 비교 대상 S/W들과의 상대적인 비교를 통하여 등급 부여 대상 S/W의 포지셔닝을 파악하여 품질등급을 부여한다. 비교 대상 소프트웨어 중 가장 우수한 S/W의 점수(B)를 기준으로 점수를 부여하기 위하여 평가대상 소프트웨어의 등급 점수(A)를 A/B의 계산식으로 환산하여 최종 점수를 부여한다. 비교 대상 S/W들의 점수 분포를 고려하여 분야별 S/W의 등급 부여 기준을 선정하고, 평가 S/W의 등급을 부여한다.품질등급의 예는 그림 2와 같다. 품질 등급의 기준은 S/W 분야에 따라 달라질 수 있다.




4. 적용 사례




  본 연구에서는 A 소프트웨어를 대상으로 적용된 평가 항목은 [표 2]와 같다[6].






















































<TD style="BORDER-RIGHT: #000000 0.12mm solid; BORDER-TOP: #000000 0.12mm solid; BORDER-LEFT: #000000 0.12mm solid; BORDER

'QC > 품질관리' 카테고리의 다른 글


[표 2)] 소프트웨어 평가항목


품질특성


부특성


평가항목


1. 기능성


1.1 적합성


1.1.1 기능정보제공


1.1.2 기능구현완전성


1.1.3 경계값 정보제공


1.1.4 경계값처리율


1.2 정확성


1.2.1 기능구현정확성정보제공


1.2.2 기능 구현 정확성


1.3 보안성


1.3.1 접근 통제 가능성


1.3.2 접근 감시 가능성


2. 신뢰성


2.1 성숙성


2.1.1 결함회피율


2.2 결함허용성


2.2.1 다운회피율


2.2.2 고장회피율


2.3 회복성


2.3.1 데이터 회복율


3. 효율성


3.1 시간효율성


3.1.1 평균반응시간


3.2 자원효율성


3.2.1 메모리 사용률


3.2.2 CPU 사용률


4. 사용성

소프트웨어 벤치마크 활성화 방안  (0) 2005.11.02
기종 평가  (0) 2005.11.01
s/w시험의 종류  (0) 2005.11.01
웹의 사용성(Usability)을 어떻게 평가할 것인가?  (0) 2005.10.31
CAD/CAM 시스템의 평가기준.  (0) 2005.10.31
Project Quality Management  (0) 2005.10.31
소프트웨어 품질의 평가  (0) 2005.10.31
조엘 테스트: 소프트웨어팀 평가 테스트 방법  (0) 2005.10.31
소프트웨어 기술성 평가 기준 해설서  (0) 2005.10.31
웹오피스 3종 벤치마킹  (0) 2005.10.28

Project Quality Management

Project Quality Management


성균관대 강석곤 자료


소프트웨어 품질의 평가

정보시스템을 구성하는 요소 중 소프트웨어는 표준화가 가장 어렵고 이에 따라 평가 또한 일관성있는 방법을 적용하기가 어려운 분야로 인식되고 있다. 그러나 최근 산업생산품의 표준화를 위해 국제표준기구에서는 ISO 9000 시리즈를 통해 평준화된 품질관리 체계의 정립을 요구하고 있다.




1. ISO 9000 시리즈의 배경




소비자들의 욕구가 다양해지고 모든 상업분야에서 품질의 중요성이 점점 더 중요하게 인식됨에 따라 이를 충족시키기 위해 국내외적으로 다양한 표준이 개발되어 왔다. 그러나 다양한 표준들은 표준간의 일관성 부족으로 인해 소비자들을 계속적으로 혼란스럽게 하였다. 이와 같은 상황에서 점증하는 품질향상 요구에 부응하고 표준화 미비로 인한 혼란을 배제하기 위해 국제간에 공통으로 사용될 수 있는 품질시스템을 만들고자 하는 노력이 이루어졌다.


1979년에 구성된 '국제 표준화기구 기술위원회 176'은 표준화를 위한 노력의 일환으로 1986년 용어표준인 ISO 8402를 발간하였고, 1987년에는 품질시스템에 대한 표준화된 지침으로 ISO 9000 시리즈를 발간하였다. ISO 9000 시리즈는 <표 1>과 같이 구성된다.


원래 ISO 9000 시리즈는 제조업 분야에서 처음 적용되기 시작하였으나 현재는 적용범위가 컴퓨터 소프트웨어, 건설, 서비스, 환경 등으로 확대되고 있다. 또한 기술 및 제품을 시험하는 기관도 ISO 9000 시리즈의 해당부분을 만족시켜야 한다. 정보기술 분야에서의 ISO 9000 시리즈는 ISO 9001을 소프트웨어산업에 맞게 변형한 ISO 9000-3이란 규정으로 적용되고 있다.


 


<표 1> ISO 9000 시리즈의 구성과 용도























ISO 9000 종류


내 용


ISO 9000-1


ISO 9000 시리즈의 선택을 위한 지침


ISO 9001


설계, 개발, 생산, 설치, 서비스와 관련된 품질보증을 위한 표준지침 제공


ISO 9002


생산 및 설치에 대한 품질보증을 위한 표준지침 제공


ISO 9003


최종검사 및 테스트에 대한 품질보증을 위한 표준지침 제공


ISO 9004-1


제품이나 서비스의 품질에 영향을 미치는 기술적, 행정적, 인적요소에 대한 지침 제공 (공급자를 위한 표준)



 




ISO 9000 시리즈는 국내외 거래에서 품질경영 및 품질보증을 위해 전세계가 공통으로 사용하는 표준으로 정착되고 있다. 현재 ISO 9000시리즈는 많은 국가와 지역 표준단체에 의해 신속하게 채택되고 있으며, 이전의 국가표준이나 산업표준들을 급속하게 대체하고 있다. 1992년 초의 통계를 볼 때 50개국 이상이 이미 ISO 9000 시리즈를 국가표준으로 채택하였으며, 30개국 이상이 ISO 9000 시리즈 인증제도를 시행하고 있는 것으로 나타났다.


이제 국제 표준화환경은 제품의 규격에 대한 표준화를 넘어서 조직이 수행해야 하는 일까지 표준화의 대상으로 삼고 있다. 기업이 표준으로 규정한 일을 수행하지 않으면 생산한 제품의 품질이 아무리 좋아도 신뢰할 수 없다는 개념이다. 이것이 국내외 거래에서 품질에 대한 기본개념이며, 이를 구체적으로 규정하고 있는 것이 바로 ISO 9000 시리즈인 것이다.




2. 소프트웨어 품질의 평가




정보기술의 발달과 함께 소프트웨어 품질에 대한 문제는 체계적으로 개선되지 못하고 있다. 예를 들어 인도 지연, 과다한 유지보수 비용, 그리고 사용상의 불편 등과 같은 소프트웨어의 개발과 사용에 있어서의 문제들을 미연에 방지하고 개선하기 위해서는 소프트웨어에 대한 체계적이 품질경영이 요구된다. 즉 소프트웨어에 대한 품질경영시스템(quality management system)이 정립되어야 한다.


공급자와 구매자간의 계약에서 총체적인 품질시스템에 대한 요구사항은 이미 ISO 9001 국제 표준으로 규정되어 있다. 그러나 ISO 9001은 제조업을 위한 규정으로 이를 소프트웨어 분야에 직접 적용하기에는 여러 가지 어려움이 있다. 소프트웨어는 일반적인 산업 생산품과는 다음과 같은 차이가 있기 때문이다.


 



소프트웨어 그 자체와 개발공정이 눈에 보이지 않고,


· 구매자가 요구사항을 규정하기 어려우며,


· 소프트웨어의 변경이 용이하고 설계내용을 파악하기 어려우며,


· 소프트웨어를 완전하게 시험하기 어려우며,


· 최종생산보다는 개발과정이 중요하며,


· 제품이 닳거나 소모되는 산업 생산품과 다른 특성을 지니고 있다.




이와 같은 소프트웨어의 특성 때문에 ISO 9001을 소프트웨어에 적용하기 위해 추가 지침인 ISO 9000-3이 1991년에 제정되었다.


ISO 9000-3은 소프트웨어를 개발하고, 공급하며, 유지보수하는 조직이 ISO 9001을 쉽게 사용할 수 있도록 하기 위한 지침들을 제공한다. 이 지침을 소프트웨어의 구매자가 공급자에게 소프트웨어의 품질을 보증할 수 있는 능력의 실증을 요구하는 경우 필요한 지침을 제공하며, 개발에서부터 유지보수에 이르는 전 과정에서 발생가능한 품질의 부적합성을 사전에 방지하는 것을 목표로 한다.


ISO 9000-3은 소프트웨어의 구매 계약과정에서 구매자가 성능이나 설계측면에서 공급자에게 특별한 요구를 해야 하거나 공급자가 개발 및 유지보수 등에서 공급자의 능력을 보증해야 할 필요가 있을 때 품질 보증을 위한 표준지침으로 사용될 수 있다. ISO 9000-3은 경영책임, 품질시스템, 내부 품질시스템 감사, 시정조치 조항으로 이루어진 기본틀, 계약검토에서 유지보수에 이르는 소프트웨어의 계약과 관련된 아홉 가지 생명주기 활동, 그리고 품질기록, 문서화, 교육훈련 등의 아홉 가지 지원활동에 대한 규정으로 구성되어 있다.




3. 품질시스템 도입에 따른 비용과 효과




품질시스템의 도입이 반드시 많은 이익을 가져다 줄 것인가 하는 것은 분명하지 않다. 품질시스템을 도입하는데 드는 비용은 심사와 인증 비용으로서 측정하기가 쉬운 반면, 효과는 눈에 보이지 않고 측정하기가 곤란한 것들이 대부분이기 때문이다. 그러나 일반적으로 품질 시스템의 도입은 항상 단순한 비용효과분석의 결과에 의해 이루어지기보다는 다음과 같은 이유로 추진되기도 한다.




· 경영환경의 변화 중의 하나로 품질에 대한 요구가 강화되기 때문


· 품질시스템에 대한 국제적이 공인을 획득함으로써 기업이미지를 제고할 수 있기 때문


· 통합유럽(EU)이나 북미자유무역협정(NAFTA) 등과 같은 경제블록화가 ISO 9000 시리즈를 무역장벽의 일환으로 활용하는 경우 이에 대처하기 위해서.




(1) 비용


심사와 인증비용에는 심사비용과 심사 후 사후관리를 위해 인증기관에 지불하는 요금과 심사준비를 위해 기업이 투자한 노력이 포함된다. 제 3의 기관이 인증심사와 관련하여 징수하는 요금은 기업규모, 심사대상 장소의 수, 기술과 산업의 복잡성 등에 딸 결정된다. 영국 인증기관의 예를 보면, 1994년을 기준으로, 50 내지 100명의 인원이 일하는 소프트웨어 회사에 대한 심사비용은 약 200만원에서 300만원 정도로 계산되었다. 이와 함께 어떤 인증기관은 약 60만원의 심사신청비와 인증서에 대한 60만원의 추가 요금을 부과한다. 또한, 품질시스템 감시를 위한 사후관리 비용으로 연평균 초기 심사비용의 약 40% 정도가 추가된다.


다른 사업과 마찬가지로 인증기관들의 인증사업 역시 시장경쟁 원리에 따라 경쟁적으로 운영되며, 인증을 원하는 조직은 여러 기관에 인증 관련비용을 문의 할수 있다. 그러나 심사를 요청할 인증기관을 최종 결정할 때는 각 기관이 제공하는 서비스에 대하여 충분한 고려를 해야 하며, 인증기관을 선택하는 결정이 단지 비용만을 근거로 해서는 안된다.




(2) 효과


품질시스템의 효과는 비용처럼 직접적으로 측정하기가 매우 어려워 효과를 직접 측정하기보다는 비용의 절감을 대체하여 효과로 간주하는 것이 일반적이다. 즉 품질경영의 효과는 품질개선으로 나타나는데 품질개선으로 인한 효과를 측정하기가 어렵기 때문에 품질개선으로 인한 실패비용의 감소로 대신하여 측정한다. 실패비용이란 다음과 같은 것을 말한다.




· 인도 전후 발생하는 결함에 따른 비용


· 일정과 예산 초과로 인한 비용


· 불필요한 유지보수 비용


· 저품질 소프트웨어에 기인하는 사용자의 간접비용

조엘 테스트: 소프트웨어팀 평가 테스트 방법

우리회사(혹은 취업하고자 희망하는 회사)의 소프트웨어팀이 얼마나 업무를 잘 수행하고 있는지 가늠해 볼 수 있는 아주 간단하면서도 리얼한 방법이 있습니다. 조엘 아저씨가 2000년 8월에 소개한 12가지 테스트 항목이 그것입니다.


 


- 조엘 테스트 12 항목


1. 소스코드 관리 시스템을 사용하고 있습니까?


2. 한방에 모든 갈래의 빌드를 만들어 낼 수 있습니까?


3. 일일빌드를 하고 있습니까?


4. 버그 추적 시스템을 운영하고 있습니까?


5. 새로운 코드(기능)를 추가하기 전에 버그를 수정합니까?


6. 일정을 업데이트하고 있습니까?


7. 명세서를 작성하고 있습니까?


8. 조용한 작업환경에서 일하고 있습니까?


9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?


10. 테스터를 별도로 두고 있습니까?


11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?


12. 무작위 사용 편의성 테스트를 수행하고 있습니까?


 


어떻습니까? 아주 간단하게 예, 아니오로 답을 할 수 있는 항목들이지요?


조엘 아저씨의 의견에 의하면 12점 만점에 11점 이상이면 우수한 성적이고 10점 이하는 심각한 문제가 있다고 합니다. 참고로 마이크로소프트는 12점 만점을 받았다고 합니다. 조엘 아저씨는 이 테스트 항목이 알려진 이후 4년 동안 자신의 조직이 몇 점을 받았는지 알려주는 무수히 많은 메일을 받았다고 합니다. 그런데 놀랍게도 대부분의 경우 2~3점 사이였다는 겁니다.


 


물론 조엘 테스트에서 낮은 점수를 받았다고 해서 꼭 질 낮은 소프트웨어를 개발해내고 높은 점수를 받았다고 해서 질 높은 소프트웨어를 개발해낸다는 의미는 아닙니다. 다만 다른 제반 조건이 비슷할 경우 12점 만점을 받았다면 일정과 품질 모든 측면에서 일관성 있게 제품을 출시해낼 수 있는 잘 훈련된 팀이라고 판단할 수 있다는 겁니다.


 


이 12가지 항목에 대한 자세한 설명과 프리맨의 주석은 앞으로 엮인글로 쭈~욱 달아 올리겠습니다.


 


참고로 현재 프리맨이 몸담고 있는 회사의 소프트웨어팀 평가 점수는 6점입니다. 심각한 문제가 있는 수준이라고 자책을 하고 있습니다.


1. 소스코드 관리 시스템을 사용하고 있습니까? - Yes


2. 한방에 모든 갈래의 빌드를 만들어 낼 수 있습니까? - Yes


3. 일일빌드를 하고 있습니까? - Yes


4. 버그 추적 시스템을 운영하고 있습니까? - No


5. 새로운 코드(기능)를 추가하기 전에 버그를 수정합니까? - Yes


6. 일정을 업데이트하고 있습니까? - No


7. 명세서를 작성하고 있습니까? - No


8. 조용한 작업환경에서 일하고 있습니까? - No


9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까? - Yes


10. 테스터를 별도로 두고 있습니까? - Yes


11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까? - No


12. 무작위 사용 편의성 테스트를 수행하고 있습니까? - No

소프트웨어 기술성 평가 기준 해설서

소프트웨어 기술성 평가 기준 해설서


- 한국소프트웨어 진흥원 2004년 1월



Windows XP의 성능

Microsoft Windows XP는 많은 새로운 기능을 가지고 있습니다. 아주 빨라진 부팅 시간과 재시동 시간 및 뛰어난 응답성을 갖춘 어플리케이션 등 전반적으로 향상된 성능은 아주 만족스러운 사용자 경험을 제공합니다.

Microsoft의 최소 하드웨어 권장 사양을 충족시키는 대부분 컴퓨터에서 Windows XP는 지금까지 선보인 Windows 운영체제 중에서 최고의 성능을 자랑합니다. 이 백서는 Windows XP의 주요 성능 개선 사항을 설명하며, 시스템 구성을 평가할 때 반드시 고려해야 할 일부 이슈들을 강조하여 설명합니다.

Windows XP는 아직까지 개발 중에 있기 때문에 Microsoft는 현재 여러분에게 구체적인 성능 수치를 제공할 수는 없지만 다른 객관적 검토자들이 실시한 벤치마크를 통하여 조사한 내용을 곧 발표할 것입니다. 그 때까지, 여기서 설명하는 정보가 여러분이 Windows XP 및 그의 리소스 요건을 이해하는데 도움이 될 것입니다.















페이지 2/7: 메모리와 성능










Microsoft는 Windows XP 운영 컴퓨터에 최소 128 MB RAM을 설치할 것을 권장합니다. Windows XP는 이 정도의 메모리 크기에서 이전 버전의 Windows보다 항상 좋은 품질을 보장합니다. 리소스를 추가하면 성능이 더 향상되며, 특히 여러분이 메모리 소모가 큰 멀티미디어 어플리케이션을 사용할 때는 향상된 성능을 확실하게 느낄 수 있습니다. 많은 사용자들은 보유하고 있는 컴퓨터 메모리를 확장하여 멀티미디어 어플리케이션을 사용하고 보다 향상된 성능을 확보하려고 할 것입니다.

일반적으로 메모리를 추가하는 것이 컴퓨터의 성능을 향상시키는 가장 빠르고 효율적인 방법입니다. 비록 메모리 확장을 권장하기는 하지만 Windows XP가 반드시 128 MB RAM을 요구하는 것은 아닙니다. 이 운영체제는 64 MB RAM으로도 운영할 수 있습니다. 웹 브라우징, 이메일 등 많은 작업부하를 발생시키는 업무를 수행하는 경우에도 64 MB RAM으로 Windows XP를 운영하는 것이 동일한 하드웨어에서 Windows Millennium Edition (Windows Me)을 운영하는 경우에 비하여 성능 면에서 최소한 같거나 우수합니다.

성능에 영향을 주는 기타 요소들


특수한 작업부하 상태에서 특정 운영체제의 성능에 영향을 미치는 요소로는 메모리 이외에 다른 것도 있습니다. 특히 어플리케이션과 관련하여 CPU 속도가 성능에 영향을 줄 수 있습니다. Windows XP는 훌륭한 사용자 경험을 제공하기 위하여 최고급 프로세서를 요구하는 것은 아니지만(최소 300 MHz Pentium II 급 프로세서), 하드웨어가 빠르면 시스템의 성능이 보다 향상됩니다. 운영체제, 특히 Windows XP UI(사용자 인터페이스)는 비디오 하위시스템 및 비디오 드라이버에 민감하게 반응합니다. 보드에 비디오 메모리를 설치하면 운영체제나 어플리케이션이 사용하는 일반용 RAM에 걸리는 작업부하를 경감시켜줄 것입니다. 그리고 개별 드라이버들이 시스템 성능을 저하시킬 수 있기 때문에, 가능하면 매우 다양한 장치에 걸쳐서 고품질 드라이버를 사용하도록 Microsoft는 업계와 긴밀하게 협력하고 있습니다.















페이지 3/7: 성능 평가










훌륭한 운영체제 성능을 실현하는 것은 Microsoft의 최고 관심사입니다. Windows XP의 개발 과정에서 지속적으로 성능 검사를 실시하였습니다. 새로운 기능과 서비스의 효율성을 평가하고, 문제를 진단하고, 성능의 향상 정도를 파악하였습니다. 성능상 문제가 발생하는 부분에서는 새로운 설계 및 알고리즘을 적용하였습니다.


평가 절차


시스템 성능을 평가하기 위해서는 운영체제의 사용 환경에 따른 다양한 접근 방법과 작업부하 형태가 필요합니다. 시스템 부팅과 같은 일부 동작은 독립된 환경에서 측정 가능하지만, 다른 기능들은 실제 작업부하 환경에서 테스트하는 경우에만 의미 있는 측정 결과를 기대할 수 있습니다. 시스템의 전반적인 적합성을 파악하는데 필요한 것으로서 실제 환경 외에는 다른 대안이 없습니다.


Windows 성능 조사팀은 Windows XP의 성능을 측정하기 위하여 내부/외부 벤치마크 자료 및 심층적 비교 기법을 활용하였습니다. 현실적 벤치마크 외에도 Windows 개발자들은 Windows XP를 사용하여 자신들의 일상 업무를 수행함으로써 작업의 신뢰성을 높였으며, 그러한 작업의 의도는 실제 고객들의 경험을 미리 체험하기 위한 것이었습니다.


Windows XP는 내부 및 외부용 베타 프로그램으로 발표되어 수천명의 사용자들에게 이 시스템을 사용하면서 테스트 해볼 수 있도록 하고 있습니다. 응답성 및 리소스 소모와 관련된 많은 문제점들을 파악하여 수정하였습니다. 이렇게 광범위하게 사용해봄으로써 여러분의 실제 작업 환경에서 필요한 부분을 보다 잘 이해할 수 있게 되었습니다.


벤치 마크


Windows XP를 평가하기 위하여 사용한 벤치 마크 및 다른 표준 작업부하를 통하여 이 운영체제의 작동 원리를 파악함으로써 성능 향상을 촉진하였습니다. Windows XP가 이러한 벤치 마크에서 좋은 결과를 제시하기는 하였지만 그러한 성능 향상이 인위적인 벤치 마크 상황에서만 발휘되는 것은 아닙니다. Microsoft가 사용한 벤치마크 기법은 아주 다양하며 장기적으로 수행되었습니다. 그리고 Windows XP의 훌륭한 성능은 확실한 리소스 관리 알고리즘, 선점 메모리 축소(reductions of memory footprint), 파일 시스템의 성능 향상, 레지스트리 및 다른 시스템 구성요소를 통하여 구현됩니다.


심층적인 성능 분석


Microsoft 가 여러분의 Windows XP의 사용 경험을 평가하는데 있어서 가장 중요한 방법중의 하나가 Windows XP와 다른 Windows 버전들을 심도 있게 비교하는 작업이었습니다. 이 작업은 동일한 조건으로 구성된 컴퓨터를 활용하여 수행하였습니다.


분석 방법
이러한 심도 있는 분석은 Office 작업용 어플리케이션, 웹 브라우징 또는 게임 플레이 같은 연습 시나리오를 경험한 두 사람에 의하여 수행되었습니다. 시스템에 대한 주관적인 느낌을 평가하고 성능의 차이점을 기록하였습니다. 이들 정보는 Microsoft의 개발자들에게 전달하여 문제를 보완하도록 하였습니다.


최소 하드웨어 사양 또는 그 이상의 사양만을 충족한다면 Windows XP는 이전 버전의 Windows보다 최소한 같거나 더 우수한 사용자 경험을 제공한다는 것을 확인하였습니다. 우수한 사용자 경험은 128 MB 이상의 RAM을 가진 컴퓨터, 특히 데스크톱 멀티프로세서 워크스테이션에서 가장 확실하게 보여졌습니다.


조사 시점
Windows XP가 이전 버전 Windows들보다 우수한 성능을 제공한다는 사실이 현재 시점에서는 주관적인 결과이지만, Microsoft는 이 조사 결과가 가까운 시일 내에 많은 객관적 외부 시험기관에 의하여 입증될 것임을 확신합니다.


벤치마킹에 사용된 어플리케이션


아래의 상업적 벤치마크를 통하여 Windows XP의 성능을 측정하였습니다:



  • eTesting Labs의 Business Winstone 2001 및 Content Creation Winstone 2001
  • BAPCo의 Webmark 2001 및 SysMark 2001
  • PC World의 PCWorldBench>
  • MadOnion의 3DMark 2000 (게임)>
  • EtestingLabs의 3D WinBench 2000 (게임)
  • Microsoft가 개발한 벤치마크

벤치마크 수행 절차
벤치마크가 현실적인 작업부하를 고려하도록 설계하였으며, 다양한 프로그램에 적용되었습니다. 이들 다양한 프로그램 샘플들은 아주 많은 사용자 시나리오를 의미합니다. 그리고, 벤치마크는 상당히 장기간에 걸쳐 운영되었으며, 일부 벤치마크는 한 번 수행하는데 한 시간 이상 걸리기도 했습니다. 이렇게 다양한 작업부하 및 프로그램에 걸쳐서 좋은 결과를 거두기 위해서는 지속적이고 효율적인 관리 작업이 필요하며 Windows XP는 그러한 관리기능을 제공하였습니다.


벤치마크 대상 어플리케이션
이 벤치마크에 활용된 어플리케이션들은 사용자들이 가장 많은 관심을 표시하는 광범위한 것들이었습니다. 사용된 어플리케이션들은 어플리케이션 요구사항 및 작동원리를 결정하는데 필요한 다양한 항목들을 제공하였으며, 이들은 Windows XP를 실제 작업 환경에서 사용할 때 어떠한 작동 상태를 보일 것인지를 이해하는데 있어서 필수적인 것들이었습니다.


벤치마크 했던 어플리케이션들은 다음과 같습니다:


웹 브라우저



  • Netscape Navigator
  • Microsoft Internet Explorer>

Office 제품군



  • Microsoft Word, Microsoft Excel, Microsoft Access, Microsoft PowerPoint?, Microsoft FrontPage?, Microsoft Outlook?, and Microsoft Project
  • Lotus Notes
  • Quicken (Intuit)

멀티미디어



  • Adobe Photoshop and Premiere
  • Corel Photopaint
  • Sonic Foundry’s Sound Forge
  • Macromedia’s Dreamweaver

문서 및 멀티미디어 컨텐츠


  • Microsoft Windows Media™ Player and Microsoft NetMeeting?
  • Adobe Acrobat
  • Macromedia’s Flashplayer
  • Cycore’s Cult3D
  • Apple’s QuickTime player
  • Dragon System’s Naturally Speaking

게임



  • 다양한 종류의 게임을 사용하였음















페이지 4/7: 시동 성능










Windows XP를 탑재한 데스크톱이나 랩톱 컴퓨터를 시작하거나 대기모드/최대 절전모드에서 다시 시작할 때, 여러분은 Windows 2000을 사용할 때보다 훨씬 빨리 컴퓨터가 사용 가능한 상태로 전환된다는 것을 느낄 것입니다.


개요


부팅 및 로그온


부팅 및 로그온 절차에는 컴퓨터의 시작, BIOS 초기화, 운영체제의 로딩 및 장치의 초기화 작업 등이 포함됩니다. 로그온 하면 컴퓨터가 사용자 바탕화면은 표시합니다.


일반적으로 새롭게 바탕화면을 표시하는데 걸리는 시간은 30초 미만이어야 하며, 많은 컴퓨터들이 20초 이내로 부팅됩니다. 그런데 로그온 할 때 네트워크를 통한 상호작용이 필요한 경우가 있는데, 이때는 로그온 시간이 더 걸릴 수도 있습니다. 그러나 그러한 상호작용이 필요한 경우의 수는 Windows 2000를 사용할 때보다 휠씬 줄어들었습니다. 사실, Windows XP 도메인에 로그온 하는 기본 절차에서는 캐시된 자격정보가 사용됩니다.


대기모드나 최대 절전 모드에서 다시 시작하기


대기모드나 최대 절전 모드는 배터리의 수명을 연장하려는 랩톱 사용자의 경우에는 특히 중요한 두 가지 수단입니다. 사용자 세션에서 로그 오프하여 컴퓨터를 끄지 않고 대기모드나 최대 절전모드를 사용할 수 있습니다. Windows XP는 대기 모드나 최대 절전 모드로 전환하고 다시 사용하는데 걸리는 시간을 크게 단축하였습니다.


대기모드는 바탕화면이나 어플리케이션을 그대로 둔 상태에서 작업을 다시 재개할 수 있는 절전 상태를 말합니다. 대기 모드를 사용할 때는 메모리 내용이 소멸성 램(Volatile RAM)에 저장됩니다. 많은 신규 랩톱이 2초 안에 대기모드 상태에서 다시 시작할 수 있도록 되어 있습니다. 최대 절전 모드는 메모리 내용을 압축 형태로 디스크에 저장한 후 컴퓨터를 완전히 끕니다. 다시 사용할 때는 이전 작업 환경과 동일한 상태로 데스크톱과 어플리케이션을 환원시켜 작업을 할 수 있습니다. 많은 신규 랩톱이 20~30초 안에 대기모드 상태에서 다시 시작할 수 있습니다만, 실제 걸리는 시간은 최대 절전모드로 전환할 때 메모리에 있는 내용물의 양에 따라 상당히 달라질 수 있습니다.


구체적인 시작 프로세스


부팅


컴퓨터를 부팅할 때는 다양한 장치, 시스템 기능 및 서비스의 초기화 등 많은 작업이 수행됩니다. Windows XP에서는 중요한 일부 변경 작업을 통하여 초기화 프로세스를 완료하는데 걸리는 시간을 크게 단축하였습니다.


이러한 변경 내용은 다음과 같습니다:


부트 로더의 개선


부트 로더(boot loader) 및 일부 핵심적 드라이버에 대한 개선을 통하여 그 속도가 훨씬 빨라졌습니다. 레지스트리 초기화도 물론 빨라졌고, 많은 장치 제조업체들이 운영체제를 실행시키기 전에 자사 제품 BIOS에 소요되는 시간을 크게 단축시켰습니다.


I/O 작업 및 장치 초기화를 동시에 진행


Windows 2000을 사용하는 경우, 각 디스크 I/O는 디스크 헤드가 어떤 새로운 위치로 이동하고 디스크가 일정 수준으로 회전할 것을 요구합니다. 그 결과 일반적인 데스크톱 디스크는 단지 초당 80~100 I/O 만을 처리할 수 있습니다. 랩톱 디스크는 그보다 느릴 경우가 많습니다. 이러한 낮은 I/O 속도로 인하여 Windows 2000에서의 부팅 시간이 길어 집니다.


Windows XP는 장치가 초기화되는 동안에 운영체제의 많은 부분을 미리 가져옴 (Prefetching)으로써 이러한 비효율적 I/O 프로세스를 개선하였습니다. 이 방법을 통하여 I/O 작업은 장치 초기화 프로세스와 동시에 수행될 수 있습니다. 그 결과, 실행 코드와 부팅 과정에서 읽어야 할 데이터를 디스크에 분산시키면서도, 시동 시간의 성능에는 거의 영향을 주지 않습니다.


부팅 시에 필요한 코드 및 데이터를 동적으로 파악


Windows XP는 시스템 부팅 과정을 관찰함으로써 부팅에 필요한 코드 및 데이터를 동적으로 결정할 수 있으며, 이들 파일을 디스크에 위치시키는 작업을 최적화시킵니다. 컴퓨터의 부팅이 시작되면 Windows XP는 높은 처리 속도로 효율적으로 처리할 수 있는 대규모 I/O 요청을 할 수 있습니다. 또한 이 운영체제는 이러한 요청을 발행할 기회를 포착하여 장치의 검색 및 초기화 기간에 동시에 처리할 수 있습니다. 이 작업은 전체적인 부팅 시간을 증가시키지 않는 방식으로 진행되므로 시스템 부팅 시간을 크게 줄일 수 있습니다.


그림 1은 Prefetching(미리가져오기) 절차 없이 부팅하는 경우의 디스크 I/O 작업을 나타내고, 그림 2는 Prefetching을 통한 부팅 작업을 나타내고 있습니다.

Prefetching(미리가져오기) 과정 없이 부팅하는 경우의 디스크 I/O : 아래의 그래프는 초당 I/O를 나타내고, 위에 있는 그래프는 디스크의 패턴을 표시하고 있습니다.

그림 1 - Prefetching(미리가져오기) 과정 없이 부팅하는 경우의 디스크 I/O : 아래의 그래프는 초당 I/O를 나타내고, 위에 있는 그래프는 디스크의 패턴을 표시하고 있습니다.

Prefetching(미리가져오기)을 통한 부팅 : 검색 시간이 대폭 줄었기 때문에 모든 작업이 훨씬 신속하게 수행됨. 레이아웃이 개선되었고 대규모의 단일 I/O를 발행하기 때문에 I/O 효율이 크게 향상되었습니다.

그림 2 - Prefetching(미리가져오기)을 통한 부팅 : 검색 시간이 대폭 줄었기 때문에 모든 작업이 훨씬 신속하게 수행됨. 레이아웃이 개선되었고 대규모의 단일 I/O를 발행하기 때문에 I/O 효율이 크게 향상되었습니다.


주의 :  신규 설치인 경우에는 신속한 부팅을 위한 관찰 및 최적화 작업을 완료하기 전에 세 번의 부팅이 필요합니다.


드라이버의 품질을 향상시키기 위하여 OEM 및IHV 업체들과 협력


부팅 과정에서 I/O의 속도를 향상시키는 작업 외에도, Microsoft는 OEM 업체와 독립적 하드웨어 공급업체(IHV) 파트너들과 긴밀한 협력작업을 통하여 장치 초기화에 걸리는 시간을 줄이기 위하여 많은 노력을 하고 있습니다. 시스템에 로드되는 많은 장치들이 여러 제조업체들에 의해 개발되고 있으며, 저질의 드라이버는 부팅시간을 매우 지연시킵니다.


Microsoft와 OEM 업체들이 신속한 부팅 및 재시동을 위하여 협력하고 있는 상황에 대한 보다 자세한 정보를 원하시면 Windows 플랫폼을 위한 신속한 부팅/ 신속한 다시 시작 을 참고하시기 바랍니다.Fast Boot/Fast Resume for the Windows Platform.


로그온


Windows XP는 미리 가져오기(prefetching) 기능을 사용하고 아울러 많은 불필요한 네트워크 지연 요소를 제거함으로써 로그온 세션의 초기화 속도를 향상시킵니다. 물론 네트워크와의 상호작용이 필요한 경우도 있습니다. 예를 들어, 일부 그룹 정책을 변경하기 위해서는 컴퓨터가 네트워크를 통하여 정보를 교환해야 하며, 로밍 프로필은 이러한 유형의 상호 교환작업을 필요로 합니다. 그러나 다른 많은 상호작용은 안전하게 제거될 수 있습니다. Windows XP에서는 이러한 상호작용을 가능한 한 모두 제거하였으며, 그 예로는 시스템이 캐시된 사용자 자격 정보를 사용하도록 하는 것입니다. 따라서 사용자 로그온의 일반적 경로, 심지어는 도메인에서도 네트워크 지연 요소를 제거하였습니다.


전체적으로 보면, 이러한 Windows XP의 로그온 관련 개선 사항은 보다 만족스러운 사용자 경험을 제공하는 것을 가능하게 했습니다. 여기에는 Microsoft Active Directory™ 가 제공하는 중앙 집중식 관리 기법상의 이점도 포함됩니다.


대기모드에서 다시 시작하기


대기 모드에서 다시 시작할 때, 운영체제는 전원 상태의 변경 내용을 알려주는 컴퓨터 장치로 명령을 보냅니다. 장치를 정상적 액티브 상태로 환원시키는 순서에는 제약조건이 있습니다. 장치가 액티브 상태로 전환되는 데는 상당한 시간이 소요되므로 다시 시작 성능을 향상시키는 데 있어서 핵심적 기법은 가능한 많은 장치의 초기화를 동시에 수행하도록 하는 것입니다. 따라서 운영체제가 선택한 순서는 병렬처리 능력을 최대화 하는데 있어서 매우 중요합니다.


병렬 처리 능력의 극대화


Windows XP에서는 장치나 어플리케이션에 전원 상태의 변경을 통보하는 알고리즘이 병렬처리 능력을 극대화하도록 개선되었습니다. 핵심적 시스템 드라이버는 서로 간의 상호작용을 막지 않게 하고 또한 다른 시스템 동작으로 인하여 작동이 방해 받을 가능성을 줄이도록 개선되었습니다.


가능한 지연 요소


다시 시작 과정에서 지연현상이 발생할 가능성은 여전히 있습니다. 예를 들어, 디스크가 완전이 초기화 되어 가동되기 전에는 처리할 수 없는 페이지 오류가 발생할 가능성이 있습니다. 때로는 프로그램이 계속 실행되기 전에는 제대로 작동하지 않는 프로그램 지연 현상이 발생할 수도 있습니다. 그러한 취약성이 때로는 다시 시작하는 시간을 지연 시킬 수 있습니다. 소요 시간은 장치용 드라이버(Microsoft가 제공하지 않는 다른 드라이버 포함)의 품질 및 컴퓨터의 BIOS 품질에 따라 달라질 수 있습니다.


Microsoft는 여러분의 컴퓨터가 가능하면 가장 신속하게 다시 시작할 수 있도록 하기 위하여 OEM 파트너들과 협력하고 있습니다.


최대 절전 모드에서 다시 시작하기


최대 절전 모드에서는 모든 장치가 꺼지며, 시스템의 물리적 메모리는 시스템 최대 절전 모드 파일에 있는 디스크에 기록되게 됩니다. 최대 절전 모드로 전환되기 전에 Windows XP는 메모리의 중요한 부분을 최대 절전 모드 파일에 압축하여 기록합니다.


압축 알고리즘을 최적화하고 압축 작업을 디스크에 대한 DMA (Direct Memory Access) 전송 작업과 동시에 수행하도록 함으로써, 최대 절전 모드 전환 속도가 보다 빨라졌습니다. 그 결과, 압축 시간이 거의 모든 장치의 I/O와 동시에 수행됩니다. 또한 부트 로더(시스템의 부팅에 영향을 줌)를 개선하고 장치 초기화 루틴을 개선함으로써 최대 절전 모드에서 다시 시작하는 속도도 빨라졌습니다.


최대 절전 모드에서 다시 시작하는데 소요되는 시간은 상황에 따라 상당히 다릅니다. 다시 시작할 때 계속될 시스템 리소스의 양은 컴퓨터 부팅 시간과 비례관계를 가집니다. 그러나 이 경우에는 최대 절전 모드로 전환될 때 저장된 모든 불필요한 페이지도 압축을 해제하여 읽어 들여야 합니다. 따라서, 최대 절전 모드에서 다시 시작하는데 걸리는 시간은 컴퓨터에 설치된 RAM의 크기, 운영중인 어플리케이션의 수, 그리고 컴퓨터가 최대 절전 모드로 전환될 때의 어플리케이션의 상태에 따라 달라집니다.


 















페이지 5/7:런타임 성능










사용자들은 부팅할 때나 최대 절전 모드/대기 모드에서 다시 시작할 때에도 물론 높은 수준의 성능을 원하지만, 사용자들이 실질적으로 느끼는 경험의 대부분은 Windows XP가 정상 운영상태에 접어들었을 때 여러분이 느끼는 시스템의 성능에 의하여 결정됩니다.


Windows XP의 성능 개선을 확인할 수 있는 두 가지 분야가 어플리케이션 시작 시간 및 리소스 관리 기능 부분입니다.


어플리케이션 시작


여러분은 Windows XP에서 어플리케이션, 특히 이전 버전 Windows에서 많은 시작 시간이 걸렸던 어플리케이션을 50%나 빨리 시작할 수 있습니다. 그 이유 중의 하나는 Windows XP가 보다 효율적이고 빠른 부팅을 하기 위하여 활용했던 방법과 유사한 방식을 통하여 어플리케이션 시작 절차를 단순화하였기 때문입니다.


프로세스


어플리케이션을 시작할 때는 운영체제가 새로운 프로그램이나 프로그램 코드 및 디스크에서 읽어야 할 데이터용으로 충분한 메모리를 확보할 수 있어야 합니다. Windows XP는 각 어플리케이션의 시작을 관찰하여 필요한 메모리의 크기 및 디스크에서 필요한 것이 무엇인지 파악합니다. 이러한 방식은 신속한 부팅 및 로그온을 위하여 사용한 방법과 동일합니다. 어플리케이션의 시작 속도는 일반적으로 필요한 I/O의 규모 및 I/O 처리의 효율성에 달려있습니다.


필요한 I/O 의 예측


일반적 수준의 페이징에서는 소량의 텍스트나 데이터를 전체 디스크에서 가져옵니다. 품질이 낮은 I/O는 디스크 찾기 및 회전으로 인하여 상당한 시간을 허비합니다. Windows XP는 각 시작 상황을 관찰함으로써 필요한 I/O를 정확하게 예측하여 수백개의 요청을 한 번에 발행합니다. 이들 요청들을 분류하여 활용하므로 추가적인 찾기나 회전 없이도 요청들을 처리할 수 있습니다. 이미 메모리에 필요한 코드 및 데이터가 있으므로 디스크에서 부족한 것을 기다릴 필요 없이 어플리케이션을 바로 시작하는 것이 가능합니다.


어플리케이션을 시작할 때의 파일 액세스 패턴을 사용하여 주기적으로 디스크에 있는 파일의 레이아웃을 최적화하고, 또 개선된 레이아웃은 찾는 시간을 축소시키며, 보다 신속한 시작을 통하여 빠르게 작업을 수행할 수 있습니다.


리소스 관리


리소스 관리 (메모리, CPU , I/O 관리 포함)는 운영체제의 가장 중요한 작업 기능 중의 하나입니다. 효율적 자원 관리 (컴퓨터의 응답성을 저하시키는 불필요한 작동을 피하는 것)는 성능 향상에 있어서 핵심적인 요건입니다. Windows XP는 Microsoft Windows NT 커널을 기반으로 구축되었으며, 대부분의 리소스 관리 접근 방법의 대부분을 이전 Windows와 함께 공유합니다 .


이러한 튼튼한 기초 위에 다음과 같은 개선 사항을 추가하였습니다:


유휴시간 작업


Windows XP는 시스템 작업을 수행하기 위하여 유휴 시간을 활용함으로써 리소스 관리 작업을 보다 효율적으로 수행합니다. Windows XP는 사용자가 작업을 완료하기 위하여 사용하는 시스템 리소스를 사용하는 동안에만 시작할 수 있는 타이머에 의존하기 보다는 사용자가 작업을 하지 않을 때 시스템 작업이 이루어지도록 리소스를 관리합니다. 따라서 향상된 유휴시간 감지 기능을 통하여 여러분은 아무 때나 수행되는 시스템 작업으로 인하여 작업속도가 늦어지는 현상 없이 Windows XP의 훌륭한 기능을 즐길 수 있습니다. 유휴 시간에 수행되는 작업으로는 하드 드라이브에 있는 파일 및 디렉터리의 최적화를 들 수 있습니다. 시스템 및 서비스 정리 작업도 이 시간대에 실행될 수 있습니다.


서비스


Windows XP는 여러분에게 다양한 기능을 제공하는 많은 서비스를 가지고 있습니다. 예를 들어, 시스템 복원 기능은 오류가 발생한 어플리케이션이나 드라이버를 정상으로 환원시키고 시스템의 손상도 복원시킬 수 있으며, 도움말 및 지원 기능은 시스템 장애해결 작업을 아주 간편하게 해줍니다.


많은 서비스들이 활성 상태에서는 상당한 시스템 리소스를 사용할 수 있으나, 그러한 시스템 사용이 Windows XP의 성능에 미치는 영향은 Windows Me에 미치는 영향에 비하면 훨씬 적습니다. 이러한 서비스 성능의 개선은 비활성화 상태에서는 적은 양의 리소스를 사용하고, 활성화 상태에서는 작업 수행 시간을 유휴시간에 맞추도록 하는 개선된 작업 방식에 기인합니다.


자가 조정 (Self Tuning)


Windows XP는 최신 하드웨어를 최대한 활용하도록 조정되어 있습니다. 많은 경우에 Windows XP는 스스로 상황에 대처할 수 있는 능력이 있으므로, 보다 높은 수준의 자가 조정 기능을 가지고 있습니다. 따라서 여러분은 적은 관리 비용으로도 보다 향상된 성능을 즐길 수 있습니다.


Windows XP는 많은 리소스 관리 기능을 Windows 2000으로부터 상속 받았지만 이전의 Windows 버전에 비하여 보다 높은 수준의 자가 조정 기능을 발휘하는 분야도 있습니다. 예를 들어, 미리가져오기(Prefetching) 기능 외에도 Windows XP는 사용자 인터페이스의 시각적 효과를 개별 컴퓨터의 환경에 맞게 조화시키도록 하는 기능을 가지고 있습니다. 그리고 애니메이션, 드롭 쉐도잉(drop shadowing), 특정 컴퓨터에서 신속하게 수행되지 않을 경우에 응답시간을 지연시킬 수 있는 메뉴 페이딩과 같은 몇 가지 효과들이 있습니다. 이러한 문제들을 방지하기 위하여 Windows XP는 설치과정에서 시스템의 기능을 측정하여 사용자 인터페이스 설정을 적절하게 조정합니다.


이 문서의 앞 부분 어플리케이션 시작 섹션에서 설명하였듯이, Windows XP의 자가 조정 절차는 디스크에 있는 파일 및 디렉터리의 레이아웃을 효율적으로 관리하고, 이 프로세스를 파일 메타데이터를 재구성하기 전에 한 발 앞서 수행함으로써 선점 메모리(footprint in memory)의 크기를 작게 합니다. 이 레이아웃 최적화의 이점은 오늘날의 대용량 디스크에서 상당한 설득력을 얻고 있습니다.


메모리 관리


Windows XP는 오늘날 대부분의 운영체제와 마찬가지로 가상 메모리를 사용합니다. 가상 메모리는 컴퓨터의 하드 드라이브에 컴퓨팅 공간을 추가함으로써 어플리케이션에 할당되는 물리적 메모리를 확장하는 것입니다. 운영체제가 일부 메모리를 어플리케이션에 할당할 수 있지만 어플리케이션의 모든 메모리 액세스를 충족시킬 수 있을 만큼 충분하게 할당하지는 못합니다. 대신에, 일부 액세스는 하드웨어에 의하여 감지되고, 이것은 일부 메모리 구조를 다시 구성하도록 합니다. 어플리케이션의 사용 패턴을 정확하게 예측함으로써, 운영체제는 어플리케이션에 필요한 물리적 메모리와 가상 메모리의 결합 형태를 파악하여 컴퓨터가 보다 적은 물리적 메모리를 사용하여 작동할 수 있게 해 줍니다.


이것은 마치 여러 개의 공을 동시에 다루는 마술사와 같습니다. 마술사는 단지 두 개의 손을 가지고 있지만, 마술사의 손은 항상 떨어지는 공을 받을 준비가 되어있는 것입니다. 다섯 개의 공을 다루는 마법사가 다섯 개의 손이 필요 없듯이 어플리케이션이 액세스하는 각각의 메가비트에 대하여 메가비트급 물리적 RAM이 필요하지는 않습니다.


Windows 2000과 마찬가지로 Windows XP는 특정 어플리케이션에 할당된 메모리가 사용되고 있는지 정기적으로 확인함으로써 성능에 영향을 주지 않고 적절하게 각 어플리케이션이 사용할 수 있는 메모리의 양을 나타내는 예측치를 가지고 있습니다. 여유 메모리는 필요할 때 바로 사용할 수 있도록 관리됩니다. 이 여유 메모리가 너무 낮아지면 작업 중인 세트를 줄여서 이것을 보충합니다. 이러한 예측치는 메모리를 어디서 확보할 것인지를 결정하는 지침으로 사용됩니다.


가상 메모리의 비용


가상 메모리를 구현하는데는 비용이 듭니다. 운영체제가 어플리케이션의 필요성을 정확하게 예측하지 못하면 앞에서 설명한 메모리 재구성 작업에는 일반적으로 디스크로부터 주고 받을 I/O 비트를 포함합니다. 디스크 I/O는 상당이 고가입니다.


일반적인 데스크톱 컴퓨터 디스크의 경우에는 초당 80 ~ 100 랜덤 I/O로 제한됩니다. 랩톱 디스크인 경우에는 제한요소가 더 많습니다. 메모리 관리 시에 발생하는 문제는 이러한 제한 요소와 관련되며, 만약 문제가 많이 발생하는 경우에는 시간이 추가로 걸립니다. 메모리를 추가하면 이러한 문제를 방지할 수 있으며, 실직적으로 메모리가 적을 경우, 이러한 문제를 피하기는 어렵습니다.


일반적으로 이러한 가상 메모리와 관련된 I/O의 영향은 매우 큽니다. 따라서, 컴퓨터에 메모리를 추가하는 것이 성능을 향상시키는 가장 쉽고 효율적인 방법입니다.


Windows XP 가 메모리를 관리하는 방법


아래의 그림 3은 Windows XP에서 운영되는 장시간의 작업부하를 추적하여 얻은 몇 가지 작업에서의 가상 메모리 사용 형태를 나타내고 있습니다. 이 작업부하는 Office 어플리케이션 및 웹 브라우징이 관련되어 있습니다. 이들 작업에는 어플리케이션의 시작, 문서의 저장 및 인쇄, 파일 및 웹 페이지를 여는 작업 등을 포함하고 있습니다. 예시한 가상 메모리는 작업에 사용되는 모든 코드 및 데이터를 유지하기 위하여 필요한 메모리의 양과 컴퓨터의 메모리에 영구히 잠겨있는 모든 메모리 리소스를 나타내고 있습니다. 가상 메모리는 다음과 같이 구분됩니다:



  • 어플리케이션이 차지한 공간 이 공간은 크기가 다양합니다. 거의 전적으로 시스템 서비스에 의존하는 서비스(웹 페이지 열기 등)의 경우에는 아주 작으며, 어플리케이션을 시작하고 자체적으로 초기화를 하는 경우에는 상당한 규모로 커집니다.
  • 드라이버 코드가 차지하는 공간 이것은 비교적 일정한 크기를 유지하는데 그 이유는 대부분의 드라이버용 코드가 메모리에 잠겨있거나 일상적으로 사용되기 때문입니다.
  • 시스템이 사용하는 할당/매핑 데이터여기에는 레지스트리 데이터, 많은 시스템 데이터 구조 및 운영체제가 액세스하는 파일들이 포함됩니다.
  • 시스템 자체가 사용하는 공간 여기에는 셸 및 모든 시스템 서비스 프로세스가 사용하는 공간이 포함됩니다.
그림 3 : 한 시간 동안 추적하여 선택한 25개 작업 유형의 가상 메모리 요건을 나타냄

그림 3 : 한 시간 동안 추적하여 선택한 25개 작업 유형의 가상 메모리 요건을 나타냄


Windows XP에서 운영되는 어플리케이션을 위한 메모리 할당


그림 3에서 설명한 작업들은 각각 20 MB ~ 55 MB의 가상 공간을 사용합니다. 이러한 가상 공간을 매핑하기 위하여 물리적 메모리를 할당하는 일은 운영체제가 담당합니다. 개별 작업은 64 MB RAM에 쉽게 적응하지만, 작업을 하나 씩 수행하다 보면 일부 메모리의 내용이 교체되어야 하는 경우가 있습니다. 한 시간 동안의 작업 부하 과정에서 총 256 MB 분량의 페이지를 처리하였습니다. 만약에 후속 작업의 많은 부분이 기존 가상공간에서 진행된다면 각각의 새로운 작업들은 I/O를 거의 요구하지 않을 것입니다.


어플리케이션 간의 전환이 이루어지는 경우에는 가상 공간의 컨텐츠에 커다란 변화가 나타날 것입니다. 64 MB RAM으로 작업 할 때는 많은 양의 I/O를 필요로 할 것입니다. 128 MB RAM으로 작업을 하는 경우에는 공간이 충분하기 때문에 필요한 대부분의 공간이 여전히 메모리에 있을 것입니다. 따라서, 128 MB 이상을 사용하면 어플리케이션 전환 작업이 훨씬 빨라집니다.


메모리 리소스 밸런싱 (Balancing Memory Resources)


앞의 예에서 보았듯이 어플리케이션이나 시스템용으로 사용할 수 있는 유일한 최선의 메모리 정책이 있을 수는 없습니다. 물리적 메모리가 부족하면 여러 작업을 진행하는 과정에서 I/O와 관련된 불편함이 자주 발생합니다. 그러나 물리적 메모리가 충분하면 시스템이 메모리를 사용하는데 여유가 있기 때문에 I/O관련 불편함을 미연에 방지할 수 있습니다.


운영체제는 지속적으로 현재 상황을 액세스하여 보관할 페이지와 삭제할 페이지를 선택합니다. 따라서, 사용중인 페이지 수 자체가 필요한 메모리의 척도가 되지 않습니다. 사용중인 페이지의 수 자체만을 고려하면 상황을 잘못 판단할 수 있습니다. 어플리케이션의 작업 세트, 즉 이 어플리케이션이 메모리에 가지고 있는 페이지 수는 때로는 규모가 상당히 클 수 있는데, 그것은 단순히 운영중인 다른 어플리케이션으로부터 메모리를 차지하려는 경쟁이 없기 때문일 수 있습니다. 반대로, 작업 세트가 아주 작아 보일 수 있는데, 이것은 단순히 모든 물리적 메모리 리소스가 다른 어플리케이션으로 할당되었기 때문일 수 있습니다.


 















페이지 7/7:평가상의 이슈










Windows XP의 성능을 평가할 때는 다음에 설명하는 중요한 이슈를 반드시 고려하도록 하십시오:


조각모음


I/O의 성능은 디스크에 있는 파일의 배열에 의하여 크게 영향을 받습니다. 디스크에 조각으로 광범위하게 퍼져 있는 파일이나 디렉터리는 성능을 저하시킵니다. Windows XP가 자동으로 일부 파일을 제 위치로 이동시켜 성능을 향상시키기는 하지만 이 작업이 정기적으로 이루어지지 않고 극히 일부 파일에 한정되어 수행됩니다. 따라서 설치 후에 주기적으로 디스크 조각모음을 하는 것이 좋은 방법입니다.


기본적으로 3일에 한 번씩 Windows XP는 부분적인 디스크 조각 모음 작업을 수행하여 현재 사용 상황에 따라 디스크의 배열을 조정합니다. 제거할 파일은 파일 Layout.ini에 기록됩니다. (이것은 '시스템 루트' 디렉터리의 '미리가져오기'(Prefetch) 디렉터리에 있음)


업그레이와 새로 설치 비교


Windows XP를 새로 설치하면 일반적으로 업그레이드를 하는 것보다 성능이 보다 향상되는데, 그 이유는 시스템의 디스크에 있는 파일 및 파일 메타데이터의 위치 설정에 대한 제어 능력이 크게 향상되기 때문입니다. FAT (file allocation table)에서 NTFS 파일 시스템으로 변환되는 디스크 파티션도 차선책으로 최적화된 클러스터 사이즈를 가질 수 있습니다.


드라이버


Microsoft는 시스템에서 사용 가능한 단지 몇 개의 드라이버만을 공급합니다. 시스템 성능은 종종 그러한 드라이버의 품질에 따라 차이가 납니다. 특히, 앞에서 지적한 대로 Windows XP에서는 드라이버 초기화를 병행 처리하는 것이 가능하지만 일부 드라이버의 초기화 작업에는 상당한간이 소요될 수 있습니다. 따라서, 일부 하드웨어의 부팅 및 재시동 작업에 상당한 시간이 걸릴 수 있습니다. 제조업체들이 다양한 하드웨어 관련 문제점에 대응하고 있지만 일부 장치에서는 여전히 문제가 발생합니다.


비디오


여러분이 사용하는 비디오 하드웨어는 비디오 드라이버의 품질과 함께 Windows XP의 성능 및 응답성에 상당한 영향을 미칠 수 있습니다. 새로운 Windows XP UI는 Windows 2000 UI에 비하여 보다 강화된 비디오 메모리 조건을 요구합니다. 만약 비디오 하드웨어가 메모리를 거의 제공할 수 없는 경우라면 시스템 메모리가 비트맵이나 다른 그래픽 데이터 구조용으로 사용될 수도 있습니다. 그러면 운영체제 및 어플리케이션이 사용할 수 있는 메모리의 양이 줄어들게 됩니다.


시스템 등록정보 대화상자에 있는 고급 탭을 통하여 실행 또는 중단시킬 기능을 선택할 수 있습니다. 간단한 한 쌍의 단추를 사용하여 시스템이 '최고의 모양 (best appearance)' 이나 '최적의 성능 (best performance)' 중에서 원하는 기능을 제공하도록 설정할 수 있습니다. Windows XP는 자동으로 모양 기능의 적절한 서브 세트를 선택하지만, 이 선택이 반드시 최적의 성능을 보장하는 것은 아닙니다.


만약 여러분의 시스템이 제한된 비디오 기능을 가지고 있거나 또는 다시 색칠(repainting)한 것이 컴퓨터에 문제를 발생시킬 소지가 있다면, 추가한 모양 기능을 제거하여 성능의 변화를 확인한 후에 바탕화면 비트맵을 제거할 수 있습니다.


초기 부팅과 후속 부팅의 비교


시스템을 처음 설치하여 부팅할 때는 운영체제가 시스템의 동작상태를 관찰합니다. 그리고 부팅 속도를 향상시킬 수 있도록 최적화 프로세스를 시작합니다. 이와 마찬가지로, 어플리케이션을 맨 처음 시작하면 나중에 최적화되고 난 이후에 시작하는 것보다 속도가 느릴 수 있습니다. 따라서 벤치마크 작업이나 다른 시스템 평가 작업을 수행하기 이전에 이러한 최적화 작업이 수행되고 이것이 충분한 횟수만큼 부팅/시작 과정을 통하여 시스템을 적응시킨다는 것을 인식하는 것은 매우 중요합니다.


요약


Windows XP는 엄청나게 빨라진 부팅 및 재시동 시간과 뛰어난 응답성을 갖춘 어플리케이션 등의 전반적으로 훌륭한 성능을 제공합니다. Microsoft의 최소 권장 하드웨어 사양을 충족시키는 대부분의 모든 컴퓨터에서 Windows XP는 다른 어떠한 제품보다 탁월한 Windows 운영체제 입니다. Microsoft는 Windows XP를 운영할 컴퓨터에 최소한 128 MB RAM을 설치할 것을 강력히 권장합니다.


Windows XP의 성능을 평가할 때 고려해야 할 추가적인 사향으로는 하드 드라이브의 프래그먼트화(fragmentation; 단편화) 정도, 업그레이드를 했는지 아니면 신규 설치를 했는지 여부, 사용중인 다른 드라이버의 품질, 비디오 시스템의 성능, 그리고 시스템이 여러분의 사용 패턴에 적응할 수 있을 정도로 충분하게 부팅/ 재시동 과정을 거쳤는지의 여부 등이 있습니다.


 


 

웹오피스 3종 벤치마킹

웹오피스 3종 벤치마킹


 


웹오피스 3종 벤치마킹


세계적으로 유례를 찾아보기 힘들 정도로 발빠른 인터넷 인프라의 구축에 힘입어 웹오피스의 쓰임새가 높아지고 있습니다. 값 비싼 오피스 패키지를 구입하지 않더라도 즉석에서 다운로드 받아 이용할 수 있는 웹오피스는 설치 및 실행의 신속함과 더불어 불법 복제 시비에 휘말릴 염려가 없이 집과 사무실, 혹은 외부에서 편리하게 이용할 수 있습니다.

현재 국내에는 넷피스(http://www.netffice.com), 씽크프리(http://www.thinkfree.co.kr), 훈민웹오피스(http://web.hunmin.com) 등의 웹오피스가 서비스 중에 있습니다. 


 


자세한 것은 첨부 파일 참조


7,200RPM 80GB HDD 4種 完全分析

내용이 길어서 잘림


첨부 워드 문서 참고