개념: 사용성 설계

주제
개념: 

소개페이지 맨 위

사용성 설계(사용자 중심 설계라고도 함)는 일반 사용자가 잘 이해할 수 있도록 하고 요구사항, 사용자 인터페이스 설계 및 테스트 노력에 사용자를 참여시켜서 더 나은 시스템을 빌드하는 것에 관한 모든 것입니다. 기본 개념은 개념: 사용자 중심 설계에 설명되어 있으므로 이 개념을 보기 전에 읽으십시오. 이 개념 페이지는 RUP가 현재 사용성 설계 기술을 다루는 방법에 대해 설명합니다.

역할페이지 맨 위

RUP에는 사용성 문제를 담당하는 많은 역할이 있습니다. 시스템 분석가요구사항 지정자는 사용자, 사용자의 타스크 및 환경에 관한 정보를 수집 및 분석하고 이러한 정보를 요구사항 및 결과물에 캡처하는 기술을 가지고 있어야 합니다. 요구사항 검토자 및 . ../process/workers/wk_tstr.htm -- This hyperlink in not present in this generated website테스터../process/workers/wk_tstanl.htm -- This hyperlink in not present in this generated website테스트 분석가 역할은 우선적으로 사용성 테스트에 대한 책임을 맡습니다. 사용자 인터페이스 설계자는 사용자 인터페이스의 설계 및 "시각적 모양"에 대한 책임을 맡습니다. 구현자는 기능적인 사용자 인터페이스를 구축하기 위해 사용자 인터페이스 컴포넌트를 선택 및/또는 개발합니다.

프로젝트 관리자도 중요한 역할입니다. 프로젝트 관리자는 사용자가 개발 프로세스에 참여할 수 있도록 하고 개발 조직에 사용 가능한 시스템을 빌드하는 데 필요한 기술을 가진 인력이 지정되었는지 확인합니다. 또한 ../process/workers/wk_depm.htm -- This hyperlink in not present in this generated website개발 관리자, ../process/workers/wk_crsdv.htm -- This hyperlink in not present in this generated website코스 개발자../process/workers/wk_tchwr.htm -- This hyperlink in not present in this generated website기술 자료 작성자와 같은 다른 역할은 전개된 시스템이 사용 가능한지 확인하는 책임을 맡습니다.

규칙페이지 맨 위

다음 섹션은 사용성에 가장 중요한 활동 및 결과물에 대한 RUP 규칙을 설명합니다.

요구사항페이지 맨 위

사용성 관점에서 요구사항 규칙은 다음에 중점을 둡니다.

  • 사용자 및 사용자의 요구사항 파악
  • 사용자에게 가장 이익이 되는 유스 케이스 식별

특정 활동 및 결과물은 다음과 같습니다.

활동 결과물 사용성 관련 내용
스테이크홀더 요청 유도 스테이크홀더 요청

이 활동에는 사용자 및 사용자 환경을 잘 파악하기 위한 사용자 인터뷰, 질문 및 워크샵 개최가 포함됩니다. 여기에는 다음이 포함됩니다.

../webtmpl/templates/req/rup_stkreq.htm -- This hyperlink in not present in this generated website결과물용 템플리트: 스테이크홀더 요청은 교육 배경, 컴퓨터 배경, 경력, 기존 환경, 기대 및 목표 등을 포함한 세부 사용자 프로파일을 캡처합니다. 또한 사용자 관점에서의 문제점 및 우선순위 설명을 캡처합니다. 스테이크홀더 요청은 비전이 수집되는 원시 재료입니다.

비전 개발 비전

비전 템플리트의 사용자 환경 섹션에서는 일반 사용자의 작업 환경 또는 ISO에서 환경 컨텍스트[ISO 13407]라고 하는 것에 대해 설명합니다.

비전 템플리트의 사용자 프로파일 섹션에서는 사용자의 전문 기술, 기술적 배경, 책임, 성공 기준 및 인도물 등을 설명합니다. ISO에서는 이것을 사용자 컨텍스트[ISO 13407]라고 합니다.

액터 및 유스 케이스 찾기, 유스 케이스 모델 구축, 유스 케이스 세부사항 유스 케이스 모델

유스 케이스 모델은 사용자(휴먼 액터)가 수행하는 타스크를 설명합니다. 이것은 일반화 관계를 사용하여 액터 간 유사성 및 관계를 캡처합니다. 액터는 유스 케이스와 관련됩니다. 이것은 Constantine의 "역할 모델"[CON99]과 유사합니다. 유스 케이스는 의사소통-연관, 포함, 일반화확장 관계를 통해 구축되고 다른 유스 케이스 및 액터와 연관됩니다.

워크샵은 사용자를 관련시키는 훌륭한 방법입니다. ../process/workguid/wg_ucwsh.htm -- This hyperlink in not present in this generated website유스 케이스 워크샵을 참조하십시오.

 

액터

휴먼 액터의 특성은 액터의 속성으로 캡처됩니다. 다음이 포함됩니다.

  • 액터의 책임 범위.
  • 액터가 시스템을 사용하는 물리적 환경.
  • 이 액터로 표시되는 사용자 수.
  • 액터가 시스템을 사용하는 빈도.
  • 액터의 영역 지식 레벨.
  • 액터의 일반 컴퓨터 경험 레벨.
  • 액터의 일반 특성(예: 전문성(교육) 레벨, 사회적 관계(언어) 및 나이).
 

유스 케이스

여기에는 Constantine이 설명한 필수 유스 케이스[CON99](필수 유스 케이스에 관한 정보는 개념: 사용자 중심 설계 참조)가 포함될 수 있습니다. 제공된 유스 케이스에 대한 특정 사용성 요구사항은 ../webtmpl/templates/req/rup_ucspec.htm -- This hyperlink in not present in this generated website유스 케이스 스펙에서 "스펙 요구사항"으로 캡처될 수 있습니다.
소프트웨어 요구사항 세부사항 정의

추가 스펙

추가 스펙은 유스 케이스에 지정되지 않은 요구사항을 캡처합니다. 여기에는 사용성과 밀접하게 관련될 수 있는 사용 가능성 및 성능 요구사항이 포함됩니다. 여러 유스 케이스에 적용할 수 있는 일반 사용성 요구사항이 적용할 수 있는 법률 및 사용성 표준(사용성 법률 및 표준에 관한 세부사항은 개념: 사용자 중심 설계 참조)과 함께 여기에 캡처됩니다.
요구사항 검토 변경 요청 사용자 중심 개발 노력에는 모든 요구사항 검토에 가능한 많은 사용자가 포함됩니다.
공통 어휘 캡처 용어집 사용자 및 나머지 개발 팀 간의 의사소통 및 이해를 용이하게 하기 위해 사용자의 도메인에 특정한 공통 어휘 용어를 캡처합니다.

위의 요구사항 활동에 추가될 수 있는 유용한 몇 가지 다른 활동이 있습니다.

    • 친화도 다이어그램[HOL96, BEY98]은 사용자 및 사용자의 타스크에 대해 수집된 각 정보를 접착 노트에 두는 기술입니다. 사용자 및 분석가는 관련 노트를 개념 그룹 또는 "친화도"로 클러스터하기 위해 협업합니다. 이 활동은 문제와 그 문제의 상대적 중요성 및 관계에 대한 공통적인 이해를 조성하는 데 도움을 줍니다.
    • 카드 정렬[CON99]은 색인 카드의 정보가 그룹으로 구성되는 것과 유사한 활동입니다. 또한 카드는 중요성, 빈도 등에 따라 정렬될 수 있습니다.
    • 계층 구조 타스크 모델링[MAY99, CON99]은 현재 사용자에 의해 수행되는 타스크를 분석하고 이를 계층 구조로 구성합니다. 계층 구조는 사용자가 현재 타스크의 조직을 파악하는 방법을 나타냅니다.

분석 및 설계 페이지 맨 위

이 규칙에 있는 많은 다른 활동이 사용자 인터페이스의 모양 및 설계에 중점을 둡니다. 다음과 같습니다.

활동

결과물

사용성 관련 내용

사용자 인터페이스 설계

스토리보드

탐색 맵

이 활동은 종종 개념적 설계라고 하는 것을 작성합니다FER01]. 이것은 사용자에게 표시되는 기본 창 및 탐색 경로를 캡처한 사용자 인터페이스 자체의 초기 추상화합니다. 이 활동은 사용자 인터페이스 설계를 조종하는 유스 케이스에 중점을 둡니다.

탐색 맵([CON99] 참조)은 상호 작용 영역(화면, 창 및 대화 상자) 간 탐색 경로의 개요를 제공합니다.

사용자 인터페이스 프로토타입 사용자 인터페이스 프로토타입

3가지 기본 프로토타입 유형을 작성할 수 있습니다.

그림(종이)
비트맵(그림 툴)
실행 파일(대화식)
대부분의 프로젝트에서 3가지 프로토타입 모두를 위에 나열된 순서대로 사용해야 합니다.

사용자 인터페이스 프로토타입 작성의 주요 목적은 실제 설계 및 개발이 시작되기 전에 시스템의 기능성 및 사용성 모두를 드러내고 테스트할 수 있다는 것입니다. 이처럼, 개발에 너무 많은 시간과 자원을 소비하기 전에 올바른 시스템을 빌드 중인지 확인할 수 있습니다.


다음과 같은 기술도 사용자 인터페이스 설계의 일부로 유용할 수 있습니다.

    • 이전에 설명된 대로 카드 정렬[CON99]은 사용자 인터페이스를 설계하는 데도 유용합니다. 각 메뉴 항목 또는 목차 항목은 카드로 표시되므로 사용자는 카드를 논리적 그룹으로 구성합니다.

위에 설명된 활동에 더하여 다음과 같은 분석 및 설계 활동이 사용자 인터페이스 설명에 보완됩니다.

활동

결과물

사용성 관련 내용

유스 케이스 분석 분석 클래스
유스 케이스 구현

다음도 참조하십시오.

클래스 설계

이 활동은 사용자 인터페이스의 설계 및 프로토타입 결과를 사용하며 클래스를 설계합니다. 프로토타입과 다르게, 이것은 일시적인 개념적 사용자 인터페이스 작업이 아니지만 인도된 시스템의 설계를 나타내기 위해 사용됩니다.

다음 가이드라인도 참조하십시오.

가이드라인: UML을 통해 웹 어플리케이션 빌드


구현 페이지 맨 위

사용자 인터페이스의 구현은 일반 구현 워크플로우를 따릅니다. 사용자 인터페이스의 구현이 종종 설계 활동의 일부로 수행됨에 주의하십시오.

테스트 페이지 맨 위

사용성 관련 ../process/workflow/test/co_perfo.htm -- This hyperlink in not present in this generated website성능 테스트를 포함한 사용성 테스트는 사용자 인터페이스의 실제 모형 또는 실행 가능 프로토타입이 생기자마자 시작되어야 합니다. 테스트는 추가 스펙에서 캡처되거나 ../webtmpl/templates/req/rup_ucspec.htm -- This hyperlink in not present in this generated website유스 케이스 스펙에서 "특수 요구사항"으로 캡처된 사용성 및 성능 요구사항의 검증을 포함해야 합니다.

전개 페이지 맨 위

사용자는 ../process/workflow/deployme/wfs_dep3.htm -- This hyperlink in not present in this generated website워크플로우 세부사항: 승인 테스트 관리 중에 최종 사용성 테스트뿐 아니라 ../process/workflow/deployme/wfs_dep10.htm -- This hyperlink in not present in this generated website워크플로우 세부사항: 제품 베타 테스트에도 깊이 관여해야 합니다.

../process/workflow/deployme/wfs_dep2.htm -- This hyperlink in not present in this generated website워크플로우 세부사항: 지원 자료 개발에는 일반 사용자가 인도된 소프트웨어 제품을 성공적으로 사용할 수 있게 하는 교육 자료 및 시스템 지원 자료의 개발이 포함됩니다.

프로젝트 관리 페이지  맨 위

../process/workflow/ovu_mgm.htm -- This hyperlink in not present in this generated website프로젝트 관리는 고객(청구서 지불자) 및 사용자 모두의 요구사항을 충족하는 제품을 성공적으로 인도하기 위한 경쟁적 목표 비교 평가, 위험 관리 및 제한조건 극복 기술입니다. 사용성 설계 관점에서 가장 중요한 활동은 활동: 프로젝트 조직 및 담당 직원 정의입니다. 이 활동은 조직 구조, 외부 인터페이스, 책임 및 역할을 정의합니다. 이 활동은 개발 프로세스에서 사용자가 관련될 범위의 정의가 포함되고 개발자가 사용성 설계 메소드에 경험이 있어야 하는지를 판별합니다.

환경 페이지  맨 위

../process/workflow/ovu_env.htm -- This hyperlink in not present in this generated website환경 규칙은 프로젝트 또는 조직에서 따르게 될 개발 프로세스의 정의를 포함합니다. ../process/activity/ac_devca.htm -- This hyperlink in not present in this generated website활동: 개발 케이스 개발(../process/artifact/ar_devcs.htm -- This hyperlink in not present in this generated website결과물: 개발 케이스)은 적용될 사용성 설계 기술 및 이러한 기술을 통합하기 위해 다양한 RUP 결과물 및 활동을 조정하는 방법을 정의합니다.

또다른 중요한 활동은 사용자 인터페이스 가이드라인을 포함한 ../process/artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website결과물: 프로젝트 가이드라인을 작성하는 ../process/activity/ac_dvlprjspcgdl.htm -- This hyperlink in not present in this generated website활동: 프로젝트 특정 가이드라인 개발입니다. 이러한 가이드라인은 사용성에 상당한 도움을 줄 수 있는 사용자 인터페이스의 일관성을 보증하는 데 도움을 줍니다. 또한 단축중요한 가이드라인, "실행 취소" 성능, 인식 가능 종료, 모델리스(Modeless) 상호 작용 등과 같이 준수해야 할 사용성 원칙을 캡처합니다.

반복적 개발 및 단계 페이지 맨 위

RUP의 소프트웨어 라이프사이클은 시간이 경과함에 따라 4가지 순차 단계로 나뉩니다. 각 단계는 주요 이정표로 완결되며 본질적으로 2가지 주요 이정표 사이의 기간입니다. 단계의 목적이 충족되었는지 판별하기 위해 각 단계의 마지막에 평가가 수행됩니다 평가가 만족스러우면 프로젝트가 다음 단계로 이동할 수 있습니다.

각 단계 내에 몇 개의 반복이 존재할 수 있습니다. 반복은 실행 가능 제품, 개발 중인 최종 제품 서브세트의 릴리즈(내부 또는 외부)를 생성하는 전체 개발 루프입니다. 최종 시스템이 되기까지 반복에서 반복으로 단계적으로 발전합니다. 사용성은 이 반복적 방법에서 크게 이익을 얻습니다. 이 방법은 사용자가 사용성에 대한 빠른 피드백을 제공할 수 있도록 하며 단순히 사용자 요구사항만을 충족하지 않을 경로 너무 아래로 나아가는 것을 막습니다.

사용자는 각 반복에 관련되어 요구사항을 더 세부적으로 정제하고 설계 개념을 평가하며 POC 프로토타입 및 전개 시스템 모두의 사용성을 테스트/평가해야 합니다.

다음 섹션에서는 각 단계에 대한 사용성 관련 단계 완료 기준 및 기본 활동을 설명합니다.

초기화 페이지 맨 위

초기화 단계의 두 가지 주요 목적은 다음과 같습니다.

  • 운영 비전, 승인 기준 및 제품에 존재하도록 의도된 것과 그렇지 않은 것을 포함하여 프로젝트의 소프트웨어 범위 및 경계 조건을 수립
  • 시스템의 중요한 유스 케이스, 주요 설계 상충(trade-off)을 드라이브하는 기본 조작 시나리오 식별

사용성 설계 관점에서 이것은 다음에 관련된 요구사항 및 비즈니스 모델링 활동을 강조하는 것을 의미합니다.

  • 사용자 및 사용자의 요구사항 파악
  • 사용자에게 가장 이익이 되는 유스 케이스 식별

초기화 단계는 종종 일부 개념적 설계 및 "POC" 프로토타입을 탐색하는 시간이기도 합니다. 이것은 특히 기본 프로젝트 위험이 사용자 인터페이스 및 사용성 문제와 연관된 경우 참입니다. 사용성 관련 ../process/workflow/test/co_perfo.htm -- This hyperlink in not present in this generated website성능 테스트를 포함한 사용성 테스트는 사용자 인터페이스의 실제 모형 또는 실행 가능 프로토타입이 생기자마자 시작되어야 합니다.

구현화 페이지  맨 위

RUP가 반복적 프로세스이므로, 범위를 관리하고 전개 중인 시스템이 사용자 요구사항을 충족하는지 확인하기 위해 사용자는 초기화에서 작성된 결과물을 다시 방문하고 검토합니다.

구현화에서는 사용자 인터페이스 구조를 포함한 소프트웨어 구조에 중점을 둡니다. 개념 사용자 인터페이스가 정의되고 중요하고/하거나 위험한 사용자 인터페이스 설계 요소가 구현됩니다. 소프트웨어 구조에 관련된 활동은 일반적으로 사용자 인터페이스에 적용됩니다(평가되어야 하는 출하 대기 제품, 재사용 고려사항, 메커니즘 및 패턴 선택 등이 있음).

이 단계는 분석 및 설계 규칙의 활동 지원뿐 아니라 사용자 인터페이스 설계 활동을 강조합니다. 구현화를 완료하려면 평가될 수 있는 실행 중인 시스템이 구축되어야 하므로 구현 및 테스트도 포함됩니다.

사용성 테스트 및 사용성 관련 ../process/workflow/test/co_perfo.htm -- This hyperlink in not present in this generated website성능 테스트추가 스펙에서 캡처되거나 ../webtmpl/templates/req/rup_ucspec.htm -- This hyperlink in not present in this generated website유스 케이스 스펙에서 "특수 요구사항"으로 캡처된 위험한 요구사항에 중점을 두어야 합니다.

구축 페이지  맨 위

구축에서는 더 많은 유스 케이스를 구현하는 데 중점을 둡니다. 여기에는 사용자 인터페이스 및 ../process/artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website프로젝트 특정 가이드라인에서 캡처된 사용자 인터페이스 가이드라인에 충실하면서 사용자 인터페이스에 추가하는 것이 포함됩니다. 새 기능이 추가되므로 사용성 테스트는 지속적으로 매우 중요합니다.

각 반복에 놓이게 될 기능의 선택은 사용자에 대한 가치를 기반으로 합니다.

전이 페이지 맨 위

전이 단계의 초점이 ../process/workflow/ovu_dep.htm -- This hyperlink in not present in this generated website전개 규칙으로 이전되기 시작합니다. 사용자 중심 개발 노력에서 사용자를 관여시키는 데 전이 단계까지 기다려서는 안됩니다. 그러나 사용자는 계속하여 관여하고 우선적으로 피드백을 제공합니다. 사용자가 개발 전체에서 관여된 경우, 종종 정규 베타 및 승인 테스트가 상당히 축소되거나 없어지게 됩니다. 대신 자세한 사용자 피드백 및 승인이 개발 노력 전체에서 발생합니다.

교육 자료 및 시스템 지원 자료의 개발이 전이에서 완료되지만 사용자가 피드백을 줄 수 있도록 가능하면 전이보다 더 이른 단계에서 시작되어야 합니다.

전이에서 일반 사용자가 사용할 수 있는 작업 시스템이 있습니다. 초기 릴리즈에 있던 문제점이 정정될 수 있고 주요한 사용자 피드백이 통합될 수 있도록 전이 동안 최소한 몇 개의 반복을 계획하는 것이 좋습니다.



Rational Unified Process   2003.06.15