개념: 사용성 엔지니어링
이 가이드라인은 사용성 엔지니어링에 대해 논의합니다. 사용성 엔지니어링(사용자 중심 디자인라고도 함)은 일반 사용자가 잘 이해할 수 있도록 하고 요구사항, 사용자 인터페이스 디자인 및 테스트 노력에 사용자를 참여시켜서 더 나은 시스템을 빌드하는 것에 관한 모든 것입니다.
기본 설명
개념: 

소개

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

역할

RUP에는 사용성 문제를 책임지는 많은 역할이 있습니다. 시스템 분석가요구사항 지정자는 사용자, 사용자의 타스크 및 환경에 관한 정보를 수집 및 분석하고 이러한 정보를 요구사항으로 캡처하는 스킬이 있어야 합니다. 이 자료는 요구사항 검토자가 검토합니다. 테스터테스트 분석가 역할은 우선적으로 사용성 테스트에 대한 책임을 맡습니다. 사용자 인터페이스 디자이너는 사용자 인터페이스의 디자인 및 "시각적 모양" 작업을 책임집니다. 구현자는 기능적인 사용자 인터페이스를 생성하기 위해 사용자 인터페이스 컴포넌트를 선택 및/또는 개발합니다.

프로젝트 관리자도 중요한 역할입니다. 프로젝트 관리자는 사용자가 개발 프로세스에 참여할 수 있도록 하고 개발 조직에 사용 가능한 시스템을 빌드하는 데 필요한 스킬을 가진 인력이 배정되도록 합니다. 또한  배치 관리자,  과정 개발자 전문 기술 작성자와 같은 다른 역할은 전개된 시스템이 유용하도록 하는 책임을 맡습니다.

원칙

다음 섹션은 사용성에 가장 중요한 활동 및 아티팩트에 대한 RUP 원칙을 설명합니다.

요구사항

사용성 관점에서 요구사항 원칙은 다음에 초점을 맞춥니다.

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

특정 활동 및 아티팩트는 다음과 같습니다.

활동 아티팩트 사용성 관련 컨텐츠
이해 당사자(stakeholder) 요청 도출 이해 당사자(stakeholder) 요청

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

아티팩트용 템플리트: 이해 당사자(stakeholder) 요청은 교육 배경, 컴퓨터 배경, 경력, 기존 환경, 기대 및 목적 등을 포함한 자세한 사용자 프로파일을 캡처합니다. 또한 사용자 관점에서의 문제점 및 우선순위 설명을 캡처합니다. 이해 당사자(stakeholder) 요청은 비전이 수집되는 원시 재료입니다.

비전 개발 비전

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

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

액터 및 유스 케이스 찾기, 유스 케이스 모델 구조화, 유스 케이스 세부화 유스 케이스 모델

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

워크샵은 사용자를 관련시키는 훌륭한 방법입니다. 유스 케이스 워크샵을 참조하십시오.

 

액터

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

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

유스 케이스

여기에는 Constantine의 [CON99]에서 설명된 필수 유스 케이스가 포함됩니다(필수 유스 케이스 논의는 개념: 사용자 중심 디자인 참조). 제공된 유스 케이스에 대한 특정 사용성 요구사항은 유스 케이스 명세에서 "특별 요구사항"으로 캡처될 수 있습니다.
소프트웨어 요구사항 세부화

보충 스펙

보충 스펙은 유스 케이스에 지정되지 않은 요구사항을 캡처합니다. 여기에는 사용성과 밀접하게 관련될 수 있는 가용성 및 성능 요구사항이 포함됩니다. 여러 유스 케이스에 적용할 수 있는 일반 사용성 요구사항이 적용할 수 있는 법률 및 사용성 표준(사용성 법률 및 표준에 관한 세부사항은 개념: 사용자 중심 디자인 참조)과 함께 여기에 캡처됩니다.
 종속성 관리  요구사항 속성 유스 케이스 및 사용성 요구사항이 "발견되면" 중요성 및 이점을 기록해야 합니다. 여기에는 사용자 및 다른 이해 당사자(stakeholder)와의 상의가 필요합니다. 유스 케이스가 실행되는 빈도와 같은 기타 속성이 이 아티팩트에 캡처될 수도 있습니다.
요구사항 검토 변경 요청 사용자 중심 개발 노력에서는 모든 요구사항 검토에 가능한 많은 사용자를 포함시킵니다.
공통 용어 캡처 용어집 사용자 및 나머지 개발 팀 간의 커뮤니케이션 및 이해를 용이하게 하기 위해 사용자의 도메인에 특정한 공통 용어를 캡처합니다.

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

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

분석 및 디자인

이 원칙에 있는 많은 다른 활동이 사용자 인터페이스의 모양 및 디자인에 초점을 맞춥니다. 이는 다음과 같습니다.

활동

아티팩트

사용성 관련 컨텐츠

사용자 인터페이스 디자인

스토리보드

탐색 맵

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

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

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

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

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

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


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

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

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

활동

아티팩트

사용성 관련 컨텐츠

유스 케이스 분석 분석 클래스
유스 케이스 실현(realization)

다음도 참조하십시오.

클래스 디자인

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

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

가이드라인: UML을 사용하여 웹 응용프로그램 빌드


구현

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

테스트

사용성 연관  성능 테스트를 포함한 사용성 테스트는 사용자 인터페이스의 실제 모형 또는 실행 가능 프로토타입이 생기자마자 시작되어야 합니다. 테스트는 보충 스펙에서 캡처되거나 유스 케이스에서 "특수 요구사항"으로 캡처된 사용성 및 성능 요구사항의 유효성 검증이 포함되어야 합니다.

배치

사용자는  활동: 적합성 테스트 관리 중에 최종 사용성 테스트 뿐만 아니라  활동: 제품 베타 테스트에도 깊이 관여해야 합니다.

 활동: 지원 자료 개발에는 사용자가 전달된 소프트웨어 제품을 성공적으로 사용할 수 있게 하는 훈련 자료 및 시스템 지원 자료의 개발이 포함됩니다.

프로젝트 관리

프로젝트 관리는 고객(청구서 지불자) 및 사용자 모두의 요구사항을 충족하는 제품을 성공적으로 전달하기 위한 경쟁 목표 밸런스 조정, 위험성 관리 및 제한조건 극복 기술입니다. 사용성 엔지니어링 관점에서 가장 중요한 활동은 활동: 프로젝트 조직 및 인력 구성 정의입니다. 이 활동은 조직 구조, 외부 인터페이스, 책임 및 역할을 정의합니다. 이 활동은 개발 프로세스에서 사용자가 관련될 범위의 정의가 포함되고 개발자가 사용성 엔지니어링 메소드에 경험이 있어야 하는지를 판별합니다.

환경

환경 원칙은 프로젝트 또는 조직에서 따르게 될 개발 프로세스의 정의를 포함합니다.  활동: 개발 사례 개발( 중간 산출물: 개발 사례)은 적용될 사용성 엔지니어링 기법 및 이러한 기법을 통합하기 위해 다양한 RUP 아티팩트 및 활동을 조정하는 방법을 정의합니다.

또다른 중요한 활동은 사용자 인터페이스 가이드라인을 포함한  중간 산출물: 프로젝트 가이드라인을 작성하는  타스크: 프로젝트 가이드라인 개발입니다. 이러한 가이드라인은 사용성에 상당한 도움을 줄 수 있는 사용자 인터페이스의 일관성을 보증하는 데 도움을 줍니다. 또한 바로 가기, "실행 취소" 기능, 인식 가능 종료, 모델리스 상호작용 등에 대한 가이드라인과 같이 준수해야 하는 사용성 원칙도 캡처합니다.

반복적 개발 및 단계

RUP의 소프트웨어 라이프사이클은 시간이 경과함에 따라 네 가지 순차 단계로 나누어 집니다. 각 단계는 주요 이정표로 완결되며 본질적으로 두 가지 주요 이정표 사이의 기간입니다. 각 단계가 종료되면 단계의 목표를 달성했는지를 판별하기 위한( 타스크: 라이프사이클 이정표 검토) 평가가 수행됩니다. 만족스러운 평가 결과를 얻은 경우 프로젝트는 다음 단계로 이동합니다.

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

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

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

도입/인식(Inception)

도입/인식(Inception) 단계의 두 가지 핵심 목표는 도입/인식입니다

  • 운영 비전, 적합성 기준 및 제품에 필요한 내용과 그렇지 않은 내용을 포함하여 프로젝트의 소프트웨어 범위 및 경계 조건을 수립
  • 시스템의 핵심 유스 케이스, 주요 디자인 절충을 가져오는 기본 오퍼레이션 시나리오 식별

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

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

도입/인식(Inception) 단계는 종종 일부 개념적 디자인 및 "개념 검증" 프로토타입 생성을 탐색하는 시간이기도 합니다. 이것은 특히 기본 프로젝트 위험성이 사용자 인터페이스 및 사용성 문제와 연관된 경우 해당됩니다. 사용성 연관  성능 테스트를 포함한 사용성 테스트는 사용자 인터페이스의 실제 모형 또는 실행 가능 프로토타입이 생기자마자 시작되어야 합니다.

정제(Elaboration)

RUP가 반복적 프로세스이므로, 범위를 관리하고 발전 중인 시스템이 사용자 요구사항을 충족하는지 확인하기 위해 사용자는 도입/인식(Inception) 시 작성된 아티팩트를 다시 검토합니다.

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

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

사용성 테스트 및 사용성 연관  성능 테스트보충 스펙에서 캡처되거나 유스 케이스에서 "특수 요구사항"으로 캡처된 위험성 요구사항에 중점을 두어야 합니다.

구현/구축(Construction)

구현/구축에서는 더 많은 유스 케이스를 구현하는 데 초점을 맞춥니다. 여기에는 사용자 인터페이스 및  프로젝트 가이드라인에서 캡처된 사용자 인터페이스 가이드라인에 충실하면서 사용자 인터페이스에 추가하는 것이 포함됩니다. 새 기능이 추가되므로 사용성 테스트는 지속적으로 매우 중요합니다.

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

전이(Transition)

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

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

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