Software2013. 10. 6. 15:35

WMP Plus 끄기(KMP 오른쪽 화면, KMP 오른쪽 광고, KMP 오른쪽 창)

출처: https://plus.google.com/116226056306620630801/posts/S9T6QC3e2Ri (최원님 구글+)


KMP Player 3.7 버전 업데이트 후 사용중 많은 문제점이 발견되지만
네이버나 구글검색을 통해 쉽게 해결하는 방법을 찾을수 없습니다.
해당 글을 공유하여 많은 분들에게 소개시켜 주세요 :)

몇가지 절차로 간단하게 QuickFix 하는 방법을 소개해드립니다.
* 본 팁은 최원님 구글+에서 발췌하였음을 밝힙니다.

목적 : KMP Player 3.7 버전 문제점 해결

환경 : Windows 95 / 98 / ME / XP / Vista / 7
(Windows 8은 보안문제로 인해 별도의 hosts 편집기가 필요합니다.)

해결1. 실행 및 종료 시 멈추는 현상 제거
해결2. 불필요한 KMP Plus 기능 제거

방법소개
1. 시작 - 보조프로그램 - 명령프롬프트 - 우클릭 - "관리자 권한..."
** 추가 : XP의 경우 관리자 권한이 없습니다. 2번 항목 부터~
2. "attrib -r -s -h c:\windows\system32\drivers\etc\hosts" 입력
3. "notepad c:\windows\system32\drivers\etc\hosts" 입력
4. ["127.0.0.1 player.kmpmedia.net # KMP PLUS" 추가] 후 [저장]
5. ["ipconfig /flushdns" 입력 후 명령프롬프트 종료] 또는 [재부팅]
6. KMP Player 재실행 또는 실행

--
더욱 쾌적한 멀티미디어 환경을 이용하세요 :)

** 내용추가 기록 (13.09.28 23:12)
hosts 파일은 시스템 파일로 메모장으로 열려도 저장이 안될수 있습니다. 그래서 기존의 2번 항목을 3번으로 교체하고 시스템 파일을 수정하기 위한 작업 방법을 2번 항목에 추가하였습니다. 

[출처] WMP Plus 끄기(KMP 오른쪽 화면, KMP 오른쪽 광고, KMP 오른쪽 창)|작성자 레디시스


알약이 실행중이면 알약 끄고 할 것

저작자표시
Posted by 신의물방울
Software2013. 4. 6. 12:57

Camtasia DivX 코덱으로 녹화하기

1. Tools > Options 선택




2. Saving 항목에서 Record to를 .camrec에서 .avi로 변경






3. Input 탭 선택 후 Video settings.. 선택(일반 인터넷 강좌는 10프레임만으로도 충분하다)






4. Video Compression Setup에서 DivX 코덱을 선택 후 Configure... 항목 선택(DivX코덱이 없을 http://www.divx.com/에서 설치, 플레이어 필요없이 코덱만 설치하면 된다.)





5. Certification Profile에서 Home Theater Profile을 선택, 중요한 것은 하단에 적힌 Resolutions값, 720x480, 720x576을 기억하도록





6. 화면 선택창을 Custom으로 선택 후 Dimension값을 720x480 또는 720x576으로 변경(변경하지 않는 경우 녹화 중 튕긴다)




7. rec 버튼을 선택해서 녹화






저작자표시
Posted by 신의물방울
Software2011. 12. 5. 13:52

[디자인] UX란 무엇인가?

얼마전 동아리 선배에게서 자신의 관심분야가 UX 라는 말을 듣고나서 과연 UX가 무엇일까라는

생각을 하게 되었습니다. 그래서 이것 저것 알아본 결과 UX는 User eXperience의 약자이구요,

                                                                           

                                                                         


사용자 경험(UX)은 사용자가 제품과 서비스, 그리고 그것을 제공하는 회사와 상호작용하면서

경험하게 되는 모든 경험의 총 합을 의미합니다.


모범적인 사용자 경험을 만드는 가장 중요한 조건은 고객의 요구를 정확하게 만족시키는 것이며

다만 어떤 경우에도 고객을 혼란스럽게 만들거나 귀찮게 해서는 안됩니다. 그 다음으로 중요한 것은

단순함과 우아함인데 이 특징들은 사람들이 제품을 가지고 싶고, 사용하고 싶게 만듭니다.


이 글을 읽고 생각나는건 바로 애플사의 아이팟이나 아이패드, 아이폰입니다.  애플사의 제품은 단순함과
우아함을 가지고 있어 사람들 대부분 애플사의 제품을 누구나 가지고 싶게 만들며 사용하고 싶게 만드는
것은 사실입니다. 




스티픈 잡스는 어떤 조작이든 3번의 클릭만으로 어디든 도달이 가능하게 만드는 것을 강조하고

많은 디지털 기기들의 출시에서도 인터페이스 만큼은 심플하게 만드는 것보다 중요한 것은 없다는

사실을 알고 있었습니다. 바로 잡스는 UX를 통하여 기업을 성장시킨 CEO라고 할 수 있습니다.


애플은 어두운 단색적인 배경 위에서 돋보이는 흰색 이어폰을 담은 광고를 내보이며 흰 이어폰을

트랜드로 만들었으며, "가장 단조롭지만 질리지 않는, 가장 흔하지만 언제나 세련된 느낌 바로 이것

화이트 컬러가 애플이다"라고 강조했죠.


이 그림은 검색2.0 : 발견의 진화 라는 책에서 "피터보빌"이 정의한 The User Experience Honeycomb입니다.


여기에서 "유용한", "편리한", "발견가능한"은 결국 사용성(Usability)을 의미하며, "매력적인"은

독착성(Originality)을, "접근가능한"은 접근성(Accessibility), "가치있는", "믿을만한"은 가치(Valuable)등

으로 4가지가 만족되어야 좋은 사용자 경험을 할 수 있다고 합니다.


관련 도서



- Reference

   http://www.tennygood.net/fxlab/4 UX 개념도




출처 : http://kimyongjun87.blog.me/50117570111
저작자표시
Posted by 신의물방울
Software2011. 12. 5. 11:14

소극장을 만들어라. - 관찰실과 관찰자


http://murianwind.blogspot.com/2011/07/blog-post.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+murian+%28%ED%85%8C%EC%8A%A4%ED%8C%85+%ED%9E%88%EC%B9%98%ED%95%98%EC%9D%B4%EC%BB%A4%EB%A5%BC+%EC%9C%84%ED%95%9C+%EC%95%88%EB%82%B4%EC%84%9C%29
저작자표시
Posted by 신의물방울
Software2011. 11. 16. 16:16

Validation & Verification

검증(Validation)과 확인(Verification)

Validation과 Verification(V&V)는 사실 현장에 있는 전문인들도 많이 혼돈스러워하는 용어이다. 이번 “프로젝트 실무” 과목의 과제와 더불어 관련된 문서를 조사해 보았다.


모든 내용은 최대한 이해하기 쉬운 용어들을 선택해 후에 복습을 하더라도 그 모호함이 없도록 최선을 다했다.


주요 인터넷 포털 사이트와 백과사전 사이트를 조사하여 얻어낸 두 용어 Validation과 Verification의 뜻과 차이점은 다음과 같이 정의 될 수 있다.

1. 검증(Validation)

• 목적 : Are we building the RIGHT product?(올바른 제품을 만들고 있는가?)

이것은 고객의 니드(Need, 요구, 명세)를 분석가가 받아들이는데 있어 혹여나 주관적인 관점이 들어가 발생할 수 있는 문제 즉, 실제 고객의 니드와 분석가가 받아들인 니드가 차이가 나는지를 검사하는 절차이다. 아래 Verification 부분에서도 설명하지만, 이 과정은 매우 중요하다. 제작 단계에서 고객의 니드에 부합하는지 아닌지를 판단하지 않는 그러한Validation 과정이 생략된 프로세스는 매우 큰 Risk를 안게 된다. 개발자들은 오류가 있는 명세를 가지고 마치 그것이 올바른 것인 양 고객에게 제공 할 때까지 열심히 제작을 할 것이다. 하지만 고객은 제품을 사용해보고는 “이것은 제가 요구한 것이 아닌데요?”라고 하는 사태가 벌어질 수 있는 것이다.

그리하여 Validation이 다 되었으면 그것이 Complete하다고 한다. 그렇담 Complete은 무엇인가. 우선 사전적 의미를 보면 다음과 같다

“including all parts, details, facts etc and with nothing missing”

사전적 의미를 보더라도 Validation이라는 것은 명백해 진다. 고객의 니드에서 빠진 요소가 없이 모든 것을 포함하는 것. 이것이 Validation의 가장 큰 목적이라고 할 수 있다. 분석가가 이해한 내용에 고객의 니드가 빠지면 않되는 것이다.

• 특징 :

∙다이나믹한 테스트 과정이다.

∙수정과정이다.

∙평가자들이나 종종 사용자들에 의한다.

2. 확인(Verification)

• 목적 : Are we building the product RIGHT?(제품을 올바르게 만들고 있는가?)

위에서 언급한 니드에 따라 제품이 설계에 맞게 만들어지고 있는가 혹은 제품이 명세서를 충족하는가를 검사하는 절차이다. 만약 어떤 프로세스에서 Validation 과정이 이루어지지 않았다고 하더라도 Verification 절차는 100% 올바르다는 결과를 도출할 수 있다. 이러한 상황은 오류를 범하게 되는 것이다. 개발자들은 엉뚱한 명세를 가지고(개발자들은 이것인 맞는 명세라고 생각함) 열심히 개발하고 테스트를 계속해서 한다. 결국 명세에 일치하는 제품이 나오게 되고 Verification 측면에서 봤을 때 제품은 우수한 품질이라고 단정짓는다.

Verification이 다 되었으면 그것이 Correct 한다고 한다. 그럼 이것이 Validation에서의 Complete하고 무엇이 다른가? 역시 사전적 의미를 보자.

“If something is correct, it is in accordance with the facts

and has no mistakes.“

facts는 고객의 니드에 따라 만들어진 명세라고 볼수 있다. 실수가 없고(빠진 것이 없고) 명세대로 이행에 나가고 있는가(Complete와의 차이점은 Complete은 고객의 니드에서 빠진 것이 없나 체크하는 것이고, Correct는 Validation이 Complete하다는 가정 하에 프로세스가 정확하다는 것이다.) 이것이 Verification의 목적이라고 볼 수 있겠다.

• 특징 :

∙정적인 테스트 과정이다.

∙예방과정이다.

∙2~3사람이나 그룹에 의한다.

∙internal process이다.

그럼 이러한 V&V를 소프트웨어 개발에 적용하는 이유는 무엇인가? 그것은 TTA에서 발간한 “소프웨어 검증 및 확인 계획서 지침★”이란 문서에 잘 설명되어 있다.

‘소프트웨어 V&V는 고도의 훈련이 요구되는 접근 방법으로 산출물 생명 주기 전반을 통해 소프트웨어 산출물을 평가한다. V&V 노력은 소프트웨어 품질을 확립하고, 소프트웨어가 사용자 요구에 만족한다는 것을 확신하기 위한 노력이다. V&V는 소프트웨어 산출물 혹은 개발, 지원 프로세스에 대해 시의 적절한 변경을 허용함으로써 소프트웨어 프로젝트와 산출물의 상태를 통찰 할 수 있는 기법을 제공한다. 소프트웨어 검증과 확인은 소프트웨어 시스템과 그 중간 산출물들의 요구 사항을 만족시키는지를 확인하기 위해 검사, 분석 그리고 시험 기법을 사용하며 이러한 요구사항은 기능의 성능과 품질 속성 모두를 포함한다.


★소프트웨어 검증 및 확인 계획서 지침(Guide for Software Verification and Validation Plans), 정보통신단체 표준 TTAS.IE-1059, 2001년 12월 3일, 한국정보통신기술협회



 


※사전적 의미의 Validation과 Verification

Verification is a quality process that is used to evaluate whether or not a product, service, or system complies with a regulation, specification, or conditions imposed at the start of a development phase. Verification can be in development, scale-up, or production. This is often an internal process.

Validation is the process of establishing documented evidence that provides a high degree of assurance that a product, service, or system accomplishes its intended requirements. This often involves acceptance and suitability with external customers.

It is sometimes said that validation ensures that ‘you built the right thing’ and verification ensures that ‘you built it right’. 'Building the right thing' refers back to the user's needs, while 'building it right' checks that the documented development process was followed. In some contexts, it is required to have written requirements for both as well as formal procedures or protocols for determining compliance.

[사전출처]http://en.wikipedia.org/wiki/Verification_and_Validation

저작자표시
Posted by 신의물방울
Software2011. 11. 16. 10:28

ISO 9126과 국제품질표준

ISO 9126의 정의
1. 소프트웨어 품질의 특성을 정의하고 품질 평가의 Metrics를 정의한 국제표준
2. 사용자 관점에서 본 소프트웨어의 품질 특성에 대한 표준

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

ISO 품질특성 모델(주특성,부특성)
기능성 (적합성, 정확성, 상호운용성)
신뢰성 (성숙성, 결함허용성, 복구성)
사용성 (이해용이성, 기능학습용이성, 운용성)
효율성 (반응시간 효율성, 자원사용 효율성)
유지보수성 (분석성, 변경성, 안정성, 시험성)
이식성 (적응성, 설치성, 병행 존재성, 대체성)



ISO 9126 품질 측정 평가 항목(Metrics) 개략 

이번 절에서는 품질모델을 구성하는 6개의 품질특성과 그 특성의 각 부특성을 살펴보겠다. 


1) 기능성 평가항목 

기능성이란 소프트웨어가 특정 조건에서 사용될 때, 명시된 요구와 내재된 요구를 만족하는 기능을 제공하는 소프트웨어 제품의 능력을 의미한다. 기능성은 적합성, 정확성, 상호운영성, 보안성, 준수성 등의 품질 부특성으로 세분화 된다. 

가. 적합성 평가항목 

적합성이란 지정된 작업과 사용자 목적을 위한 적절한 기능들을 제공하는 소프트웨어의 능력을 의미한다. 적합성은 기능 구현 완전성, 기능 충분성, 기능 적절성 등의 평가항목을 가진다. 

나. 정확성 평가항목 

정확성이란 요구하는 정밀도를 유지하거나 또는 허용범위 내에 결과 값을 제공할 수 있는 소프트웨어 제품의 능력을 의미한다. 정확성은 기능 구현 정확성, 정밀성 등의 평가항목을 가진다. 

다. 상호 운영성 평가항목 

상호 운영성이란 하나 이상의 명세된 소프트웨어 또는 시스템과 상호 작용할 수 있는 소프트웨어의 능력을 의미한다. 상호 운영성은 데이터 교환성의 평가항목을 가진다. 

라. 보안성 평가항목 

보안성이란 권한이 없는 사람 또는 시스템은 정보를 읽거나 변경하지 못하게 하고, 권한이 있는 사람 또는 시스템은 정보에 대한 접근이 거부되지 않도록 정보를 보호하는 소프트웨어의 능력을 의미한다. 보안성은 접근 통제 가능성, 접근 감시 가능성 등의 평가항목을 가진다. 

마. 준수성 평가항목 

준수성이란 기능성과 관련된 표준 및 관례를 준수하는 소프트웨어의 능력을 의미한다. 준수성은 기능 표준 준수율, 인터페이스 준수율 등의 평가항목을 가진다. 


2) 신뢰성 평가항목 

신뢰성이란 명세된 조건에서 사용될 때, 성능 수준을 유지할 수 있는 소프트웨어의 능력을 의미한다. 신뢰성은 성숙성, 오류 허용성, 회복성, 준수성 등의 품질 부특성으로 세분화 된다. 

가. 성숙성 평가항목 

성숙성이란 소프트웨어 내의 결함으로 인한 고장을 피해 가는 소프트웨어의 능력을 의미한다. 성숙성은 문제 해결률, 결함 회피율 등의 평가항목을 가진다. 

나. 오류 허용성 평가항목 

오류 허용성이란 명세된 인터페이스의 위반 또는 소프트웨어 결함이 발생했을 때 명세된 성능 수준을 유지할 수 있는 소프트웨어의 능력을 의미한다. 오류 허용성은 다운 회피율, 고장 회피율, 경계값 처리 가능성, 오조작 회피율, 오류 방지성 등의 평가항목을 가진다. 

다. 회복성 평가항목 

회복성이란 고장 발생시 명세된 성능 수준을 회복하고 직접적으로 영향 받은 데이터를 복구하는 소프트웨어의 능력을 의미한다. 회복성은 데이터 복구율, 복구가능률, 복구 효과율, 문제 해결 구현율 등의 평가항목을 가진다. 

라. 준수성 평가항목 

준수성이란 신뢰성과 관련된 표준 및 관례를 준수하는 소프트웨어의 능력을 의미한다. 준수성은 신뢰성 표준 준수율의 평가항목을 가진다. 


3) 사용성 평가항목 

사용성이란 명시된 조건에서 사용할 경우 사용자가 이해하고, 학습하고, 사용하며 선호할 수 있는 소프트웨어의 능력을 의미한다. 사용성에는 이해가능성, 학습 가능성, 운영성, 선호도, 준수성 등의 품질 부특성으로 세분화 된다. 

가. 이해 가능성 평가항목 

이해가능성이란 소프트웨어가 적합한지, 그리고 특정 작업과 사용 조건에서 어떻게 사용될 수 있는지를 사용자가 이해할 수 있도록 하는 소프트웨어의 능력을 의미한다. 이해가능성에는 기능 이해도, 인터페이스 이해도, 도움말 이해도, 입출력 데이터 이해도, 인터페이스 일관성, 사용자 안내성, 메시지 이해 용이성 등의 평가항목을 가진다. 

나. 학습 가능성 평가항목 

학습 가능성이란 사용자로 하여금 소프트웨어가 제공하는 기능을 학습할 수 있도록 하는 소프트웨어의 능력을 의미한다. 학습 가능성에는 기능 학습 용이성, 도움말 접근 용이성 등의 평가항목을 가진다. 

다. 운영성에 대한 평가항목 

운영성이란 사용자가 소프트웨어를 운영하고 제어할 수 있도록 하는 소프트웨어의 능력을 의미한다. 운영성에는 운영 절차 조정 가능성, 운영 절차 일관성, 진행 상태 파악 가능성, 오류 복구 용이성, 문제 해결 정보 제공 등의 평가항목을 가진다. 

라. 선호도 평가항목 

선호도란 사용자에 의해 선호되는 소프트웨어의 능력을 의미한다. 선호도에는 인터페이스 변경 가능성, 인터페이스 선호도 등의 평가항목을 가진다. 

마. 준수성 평가항목 

준수성이란 사용성과 관련된 표준 및 관례를 준수하는 소프트웨어의 능력을 의미한다. 준수성에는 사용성 표준 준수율 등의 평가항목을 가진다. 


4) 효율성 평가항목 

효율성이란 명시된 조건에서 사용되는 자원의 양에 따라 요구된 성능을 제공하는 소프트웨어의 능력을 의미한다. 효율성에는 시간 효율성, 자원 효율성, 준수성 등의 품질 부특성으로 세분화 된다. 

가. 시간 효율성 평가항목 

시간 효율성이란 명시된 조건에서 그 기능을 수행할 때 적절한 반응 및 처리 시간과 처리율을 제공하는 소프트웨어의 능력을 의미한다. 시간 효율성에는 평균 반응 시간, 평균 처리율, 평균 처리시간 등의 평가항목을 가진다. 

나. 자원 효율성 평가항목 

자원 효율성이란 명시된 조건에서 소프트웨어가 그 기능을 수행할 때 적절한 양과 종류의 자원을 사용하는 소프트웨어의 능력을 의미한다. 자원 효율성에는 입출력 자원 사용률, 메모리 사용률, 데이터 전송률, CPU 사용률 등의 평가항목을 가진다. 

다. 준수성에 대한 평가항목 

준수성이란 효율성과 관련된 표준 및 관례를 준수하는 소프트웨어의 능력을 의미한다. 준수성에는 효율성 표준 준수율 등의 평가항목을 가진다. 


5) 유지보수성 평가항목 

유지보수성이란 소프트웨어가 변경되는 능력을 의미한다. 변경에는 환경과 요구사항 및 기능적 명세에 따른 소프트웨어의 수정, 개선, 또는 개작 등이 포함된다. 유지보수성에는 분석성, 변경성, 안정성, 시험가능성, 준수성 등의 품질 부특성으로 세분화 된다. 

가. 분석성 평가항목 

분석성이란 소프트웨어의 결함이나 고장의 원인 또는 변경될 부분들의 식별에 대한 진단을 가능하게 하는 소프트웨어의 능력을 의미한다. 분석성에는 진단 기능 지원률, 상태 모니터링 제공율, 감사 추적 가능성 등의 평가항목을 가진다. 

나. 변경성 평가항목 

변경성이란 특정 변경요구사항이 시스템에 반영될 수 있도록 하는 소프트웨어의 능력을 의미한다. 변경성에는 변경 가능성, 소프트웨어 변경통제 가능성, 변경 용이성 등의 평가항목을 가진다. 

다. 안정성 평가항목 

소프트웨어 변경으로 인한 예상치 않은 결과를 최소화하는 소프트웨어 능력을 의미한다. 안정성에는 변경 성공률의 평가항목을 가진다. 

라. 시험 가능성 평가항목 

시험 가능성이란 소프트웨어가 용이하게 시험될 수 있는 소프트웨어의 능력을 의미한다. 시험 가능성에는 내장형 시험 기능 보유성 등의 평가항목을 가진다. 

마. 준수성에 대한 평가항목 

준수성이란 유지보수성과 관련된 표준 및 관례를 준수하는 소프트웨어의 능력을 의미한다. 준수성에는 유지보수 표준 준수율의 평가항목을 가진다. 


6) 이식성 평가항목 

이식성이란 한 환경에서 다른 환경으로 전이될 수 있는 소프트웨어의 능력을 의미한다. 이식성에는 적응성, 설치가능성, 대체성, 공존성, 준수성 등의 품질 부특성으로 세분화 된다. 

가. 적응성 평가항목 

적응성이란 소프트웨어가 특정 환경에서 다른 환경으로 적응할 수 있는 소프트웨어의 능력을 의미한다. 적응성에는 데이터 구조 적응률, 적용 환경 적응률, 이식 편리성 등의 평가항목을 가진다. 

나. 설치 가능성 평가항목 

설치 가능성이란 명세된 환경에 설치될 수 있는 소프트웨어의 능력을 의미한다. 설치 가능성에는 설치 가능률, 제거 가능률 등의 평가항목을 가진다. 

다. 대체성 평가항목 

대체성이란 동일한 환경에서 동일한 목적으로 다른 지정된 소프트웨어를 대신하여 사용될 수 있는 소프트웨어의 능력을 의미한다. 대체성에는 데이터 지속 가능률, 기능 지속 가능률 등의 평가항목을 가진다 

라. 공존성 평가항목 

공존성이란 공통 자원을 공유하는 공동 환경에서 다른 독립적인 소프트웨어와 공존할 수 있는 소프트웨어의 능력을 의미한다. 공존성에는 공존 가능률 등의 평가항목을 가진다. 

마. 준수성 평가항목 

준수성이란 이식성과 관련된 표준 및 관례를 준수하는 소프트웨어의 능력을 의미한다. 준수성에는 이식 표준 준수율의 평가항목을 가진다. 


ISO 9126의 활용과 전망
1. ISO 9126의 활용
- 기업내부 자체에서의 구축시스템에 대한 품질 평가를 할 때 활용할 수 있는 기준자료로 사용하는 것이 가능함
- 외부로부터 도입하는 소프트웨어 패키지의 품질 평가시의 기본적인 평가 측정 틀로 활용
- 정보시스템 감리 프로세스의 표준화된 개념적인 큰 틀을 제공하여 활용됨
2. ISO 9126의 전망
- 정보시스템 감리에 대한 필요성이 커지면서 소프트웨어 품질에 대한 명확한 기분으로 활용할 필요가 있음
- 소프트웨어 제품자체의 품질을 직접적으로 높이는 연구는 보다 더 많은 노력이 필요함
- 소프트웨어 개발 프로세스를 개선하여 소프트웨어의 품질을 높이는 간접적인 방법으로 CMM과 SPICE를 도입하여 프로세스 능력을 개선하는 것이 필요

관련 국제 표준 현황
소프트웨어 품질에 대한 표준화 작업은 소프트웨어 제품 평가 분야, 프로세스 평가 분야, 품질 시스템 구축분야에 대해서 진행되고 있고 ISO/IEC 가 국제 표준화를 주도하고 있으며, IEEE가 국제표준으로 경쟁적 위치에 있다.

Quality Management System - ISO 9000 시리즈 TickIT
Process Quality - ISO/IEC 12207, SPICE(ISO 15504), CMM
Product Quality - ISO/IEC 9126, 12119, 14598


Reference 

[1]http://www.improveqs.nl/pdf/sqwe2000.pdf (Measuring software product quality during testing)
[2] http://www.cse.dcu.ie/essiscope/sm2/9126ref.html (ISO 9126: The Standard of Reference)
[3]ISO/IEC9126–3 internal quality measures: are they still useful? 
ISO, ISO/IEC 9126-1 : Information Technology - Software Quality Characteristics and Metrics - Part1:Quality characteristics and subcharacteristics, 1997 
[4]ISO, ISO/IEC 9126-2 : Information Technology - Software Quality Characteristics and Metrics - Part2:External Metrics - External Metrics, 1997 
[5] TTA, TTAS.KO-11.0049, 2005 
[6] 정창신 외, 소프트웨어 제품 품질에 관한 국제표준화, TTA저널 85호 
[7] 오영배 외, “소프트웨어 품질 평가 표준 기술 및 동향”, 주간기술동향 1271호, 2006.11.
[8] 산업자원부 기술표준원, “S/W 품질평가 국제표준화 동향 세미나”, 2005.10
[9] 정통부, “소프트웨어 품질 측정의 구체적인 방법(ISO/IEC 9126에 근간)”, 2004.1
[10] ISO/IEC 9126-1:2001,
Posted 12th December 2007 by solarixer
Labels: QA 품질 표준 ISO 9126 test 국제표준


출처 : http://solarixer.blogspot.com/2007/12/iso-9126.html
저작자표시
Posted by 신의물방울

티스토리툴바