• 20230101 ~ 20230108

• 2023 시나공 정보처리기사 필기

2장 화면 설계

Section 11. 사용자 인터페이스

11-1. 사용자 인터페이스(UI, User Interface)의 개요

• 사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어

  • 인터페이스(Interface)

    • 서로 다른 두 시스템이나 소프트웨어 등을 서로 이어주는 부분 또는 접속 장치

    • 사람이나 시스템이 기계나 프로그램을 편리하게 사용할 수 있도록 하는 연결점

• 초기의 사용자 인터페이스 -> 사용자와 컴퓨터 간의 상호작용에 국한됨

• 점차 사용자가 수행할 작업을 구체화시키는 기능 위주로 변경됨

• 최근에는 정보 내용을 전달하기 위한 표현 방법으로 변경됨

• 사용자 인터페이스의 세 가지 분야

  • 정보 제공과 전달을 위한 물리적 제어 분야

  • 콘텐츠의 상세 표현과 전체 구성 분야

  • 모든 사용자가 편리하고 간편하게 사용하도록 하는 기능(접근성) 분야

11-2. 사용자 인터페이스(UI)의 특징

• 사용자의 만족도에 가장 큰 영향을 미치는 중요한 요소

• 소프트웨어 영역 중 변경이 가장 많이 발생한다.

• 사용자 중심 설계로 사용자 중심의 상호작용이 되도록 한다.

• 사용자의 편리성과 가독성을 높여 작업 시간을 단축시키고 업무 이해도를 높인다.

• 최소한의 노력으로 원하는 결과를 얻을 수 있게 한다.

• 수행 결과의 오류를 줄인다.

• 사용자의 막연한 작업 기능에 대해 구체적인 방법을 제시한다.

• 정보 제공자와 공급자 간의 매개 역할을 수행한다.

• 사용자 인터페이스를 설계하기 위해서는 소프트웨어 아키텍처를 반드시 숙지해야 한다.

11-3. 사용자 인터페이스의 구분

• 상호작용의 수단 및 방식에 따라 다음과 같이 구분

• CLI(Command Line Interface)

  • 텍스트 형태로 명령과 출력이 이뤄지는 인터페이스

• GUI(Graphical User Interface)

  • 마우스로 아이콘이나 메뉴를 선택하여 작업을 수행하는 그래픽 환경의 인터페이스

• NUI(Natural User Interface)

  • 사용자의 말이나 행동(모바일 제스처 등)으로 기기를 조작하는 인터페이스

  • 주요 모바일 제스처(Mobile Gesture)

    • Tab(누르기) :
      화면을 가볍게 한 번 터치하는 동작

    • Double Tap(두 번 누르기) :
      화면을 빠르게 두 번 터치하는 동작

    • Drag(누른 채 움직임) :
      화면의 특정 위치에 손가락을 댄 상태에서 정해진 방향으로 움직인 후 손가락을 떼는 동작

    • Pan(누른 채 계속 움직임) :
      화면에 손가락을 댄 후 손가락을 떼지 않고 계속적으로 움직이는 동작.
      움직이는 방향이나 시간에 제한이 없으며, 손가락을 뗄 때까지의 동작을 패닝(Panning)이라고 함.

    • Press(오래 누르기) :
      화면의 특정 위치를 손가락으로 꾹 누르는 동작

    • Flick(빠르게 스크롤) :
      화면에 손가락을 터치하면서 수평 또는 수직으로 빠르게 드래그하는 동작

    • Pinch(두 손가락으로 넓히기/좁히기) :
      두 손가락으로 화면을 터치한 후 두 손가락을 서로 다른 방향으로 움직이는 동작

• VUI(Voice User Interface)

  • 사람의 음성으로 기기를 조작하는 인터페이스, 음성 인식

• OUI(Organic User Interface)

  • 모든 사물과 사용자 간의 상호작용을 위한 인터페이스

  • 소프트웨어가 아닌 하드웨어 분야에서 사물 인터넷(IoT, Internet of Things), 가상현실(VR, Virtual Reality), 증강현실(AR, Augmented Reality), 혼합현실(MR, Mixed Reality) 등과 함께 대두되고 있다.

11-4. 사용자 인터페이스의 기본 원칙

• 직관성 / 유효성 / 학습성 / 유연성

• 직관성

  • 누구나 쉽게 이해하고 사용할 수 있어야 한다.

• 유효성

  • 사용자의 목적을 정확하고 완벽하게 달성해야 한다.

• 학습성

  • 누구나 쉽게 배우고 익힐 수 있어야 한다.

• 유연성

  • 사용자의 요구사항을 최대한 수용하고 실수를 최소화해야 한다.

11-5. 사용자 인터페이스의 설계 지침

• 설계할 때 고려할 사항 : 사용자 중심 / 사용성 / 일관성 / 단순성 / 결과 예측 가능 / 가시성 / 심미성 / 표준화 / 접근성 / 명확성 / 오류 발생 해결 등

• 사용자 중심

  • 사용자가 쉽게 이해하고 편리하게 사용할 수 있는 환경 제공

  • 실사용자에 대한 이해가 바탕이 되어야 한다.

• 사용성

  • 사용자가 소프트웨어를 얼마나 빠르고 쉽게 이해할 수 있는지, 얼마나 편리하고 효율적으로 사용할 수 있는지의 정도

  • 사용자 인터페이스 설계 시 가장 우선적으로 고려

• 일관성

  • 버튼이나 조작 방법 등을 일관성 있게 제공

  • 사용자가 쉽게 기억하고 습득할 수 있게 설계

• 단순성

  • 조작 방법을 단순화시켜 인지적 부담을 감소

• 결과 예측 가능

  • 작동시킬 기능만 보고도 결과를 미리 예측할 수 있게 설계

• 가시성

  • 메인 화면에 주요 기능을 노출시켜 최대한 조작이 쉽도록 설계

• 심미성

  • 디자인적으로 완성도 높게 글꼴, 색상 적용, 그래픽 요소 배치

  • 가독성을 높일 수 있도록 설계

• 표준화

  • 기능 구조와 디자인을 표준화

  • 한 번 학습한 이후에는 쉽게 사용할 수 있도록 설계

    • 표준화(Standardization) :
      공통적이고 반복적인 사용을 위한 규정을 만드는 활동

• 접근성

  • 사용자의 연령, 성별, 인종 등 다양한 계층이 사용할 수 있도록 설계

• 명확성

  • 사용자가 개념적으로 쉽게 인지할 수 있도록 설계

• 오류 발생 해결

  • 오류가 발생하면 사용자가 쉽게 인지할 수 있도록 설계

11-6. 사용자 인터페이스 개발 시스템의 기능

• 사용자의 입력 검증

• 에러 처리와 그에 관한 에러 메시지 표시

• 도움과 프롬프트(Prompt) 제공

Section 12. UI 표준 및 지침

12-1. UI 표준 및 지침

• UI 표준과 지침을 토대로 기술의 중립성(웹 표준) / 보편적 표현 보장성(웹 접근성) / 기능의 호환성(웹 호환성)이 고려되었는지 확인한다.

• UI 표준

  • 전체 시스템에 포함된 모든 UI에 공통적으로 적용될 내용

  • 화면 구성, 화면 이동 등

• UI 지침

  • UI 개발 과정에서 꼭 지켜야 할 공통의 조건

  • UI 요구사항, 구현 시 제약사항 등

※ 웹의 3요소

• 웹 표준 / 웹 접근성 / 웹 호환성

• 웹 표준(Web Standards)

  • 웹에서 사용되는 규칙 또는 기술

  • 웹 사이트 작성 시 이용하는 HTML, JavaScript 등에 대한 규정, 웹 페이지가 다른 기종이나 플랫폼에서도 구현되도록 제작하는 기법 등을 포함

• 웹 접근성(Web Accessibility)

  • 누구나, 어떠한 환경에서도 웹 사이트에서 제공하는 모든 정보를 접근하여 이용할 수 있도록 보장

• 웹 호환성(Cross Browsing)

  • 하드웨어나 소프트웨어 등이 다른 환경에서도 모든 이용자에게 동등한 서비스를 제공

12-2. 한국형 웹 콘텐츠 접근성 지침(KWCAG; Korean Web Content Accessibility Guidelines)

• 장애인이 비장애인과 동등하게 접근할 수 있는 웹 콘텐츠의 제작 방법을 제시

• 목적 : 웹 콘텐츠 저작자, 웹 사이트 설계자 등이 접근성이 보장된 웹 콘텐츠를 쉽게 제작할 수 있도록 돕는 것

• 웹 접근성의 준수 여부를 평가할 수 있는 요구 조건과 모두 준수할 경우 얻을 수 있는 기대 효과 제시

• 웹 콘텐츠 접근성(사용성) 지침 준수를 위한 고려 사항

  • 인식의 용이성

    • 대체 텍스트

      • 텍스트가 아닌 이미지 등의 콘텐츠에는 그 의미를 인식할 수 있는 대체 텍스트를 제공해야 한다.

    • 멀티미디어 대체 수단

      • 동영상, 음성 등 멀티미디어 콘텐츠에 대한 이해도를 높일 수 있도록 대체 수단을 제공해야 한다.

      • 대체 수단 :
        멀티미디어 콘텐츠에 포함된 음성(대화)을 대체할 수 있는 자막, 대본, 수화 등을 의미한다.

    • 명료성

      • 콘텐츠는 색이나 명도, 방향, 모양, 크기, 소리 등에 관계없이 명확하게 전달될 수 있어야 한다.

      • 소리

        • 콘텐츠에 포함된 모든 소리는 자동으로 재생되면 안되므로 멈춤 / 일시정지 / 음량 조절 등 제어 수단을 함께 제공해야 한다.

        • 단, 3초 미만으로 재생되는 소리는 자동 재생이 허용된다.

  • 운용의 용이성

    • 키보드 접근성

      • 콘텐츠는 키보드만으로도 접근할 수 있어야 한다.

    • 충분한 시간 제공

      • 콘텐츠를 읽고 사용하는 데 충분한 시간을 제공해야 한다.

    • 광과민성 발작 예방

      • 광과민성 발작 :
        사람이 장시간 불규칙적으로 깜빡거리거나 번쩍이는 빛의 자극에 노출되어 발생하는 발작

      • 광과민성 발작을 일으킬 수 있는 콘텐츠는 제공하지 않아야 한다.

      • 초당 3 ~ 50회 주기로 깜빡이거나 번쩍이는 콘텐츠 등

    • 쉬운 내비게이션

      • 콘텐츠를 쉽고 편리하게 내비게이션 할 수 있어야 한다.

      • 반복되는 영역은 건너뛸 수 있도록 하거나 용도나 목적을 이해할 수 있도록 링크 텍스트를 제공하는 등

  • 이해의 용이성

    • 가독성

      • 콘텐츠는 읽고 이해하기 쉬워야 한다.

    • 예측 가능성

      • 콘텐츠의 기능과 실행 결과는 예측이 가능해야 한다.

    • 콘텐츠의 논리성

      • 콘텐츠는 선형 구조로 작성되어야 하고, 논리적인 순서를 제공해야 한다.

    • 입력 도움

      • 입력 오류를 방지하거나 정정할 수 있어야 한다.

  • 견고성

    • 문법 준수

      • 웹 콘텐츠는 마크업 언어(Markup Language)의 문법을 준수해야 한다.

      • 마크업 언어(Markup Language) :
        태그 등을 이용하여 문서의 포맷이나 구조 등을 지정하는 언어.
        HTML, SGML, XML 등.

    • 접근성

      • 웹 애플리케이션은 접근성이 있어야 한다.

※ 내비게이션(Navigation)

• 사용자가 사이트에서 원하는 정보를 빠르게 찾을 수 있도록 안내하는 것

• 사용자가 중심이 되어야 한다.

• 내비게이션은 원하는 정보를 쉽고 빠르게 찾을 수 있도록 다양한 경로나 방법을 제공해야 한다.

• 내비게이션의 구성 요소는 사용자가 직관적으로 찾아 사용할 수 있도록 설계되어야 한다.

• 내비게이션의 구성 요소는 사용자가 혼동하지 않도록 전체 페이지에서 일관성이 있어야 한다.

• 내비게이션 구조의 요소

  • 메뉴(단추)

    • 계층 구조를 표현하는 기본 요소

    • 사용자가 원하는 페이지로 이동할 수 있게 한다.

  • 링크

    • 원하는 페이지로 이동할 수 있게 하는 하이퍼링크

  • 이미지 맵

    • 그림에 하이퍼링크를 연결하여 원하는 페이지로 이동할 수 있게 한다.

  • 사이트 맵

    • 사이트의 전체 구조를 한 눈에 알아볼 수 있도록 트리 구조 형태로 만든 것

  • 사이트 메뉴바

    • 사이트의 옆쪽에 메뉴, 링크 등을 모아둔 것

  • 내비게이션 바

    • 메뉴를 한 곳에 모아 놓은 그래픽이나 문자열 모음

  • 디렉터리

    • 주제나 항목을 카테고리별로 표현한 방식

12-3. 전자정부 웹 표준 준수 지침

• 정부기관의 홈페이지 구축 시 반영해야 할 최소한의 규약을 정의한 것

• 모든 사람이 시스템 환경에 구애받지 않고 정부기관의 홈페이지를 이용할 수 있도록 하기 위한 것

• '전자정부 웹 표준 준수 지침'에는 이를 준수할 경우의 기대 효과가 제시되어 있다.

• 전자정부 웹 표준 준수 지침 사항

  • 내용의 문법 준수

    • 모든 웹 문서는 적절한 문서타입을 명시해야 한다.

    • 명시한 문서타입에 맞는 문법을 준수해야 한다.

    • 모든 페이지는 사용할 인코딩 방식을 표기해야 한다.

      • 인코딩(Encoding) :
        문자들의 집합을 컴퓨터에 저장하거나 통신에 사용할 목적으로 부호화하는 방법

  • 내용과 표현의 분리

    • 논리적인 마크업 언어를 사용하여 웹 문서를 구조화해야 한다.

    • 사용된 스타일 언어는 표준적인 문법을 준수해야 한다.

  • 동작의 기술 중립성 보장

    • 스크립트의 비표준 문법을 확장하는 것을 배제해야 한다.

    • 스크립트의 비사용자를 위해 대체 텍스트나 정보를 제공해야 한다.

  • 플러그인의 호환성

    • 플러그인은 다양한 웹 브라우저에서 호환되는 것을 사용해야 한다.

    • 플러그인(Plug-In) :
      응용 프로그램에 추가되어 특정한 기능을 수행하도록 구현된 프로그램 모듈

  • 콘텐츠의 보편적 표현

    • 메뉴는 다양한 브라우저에서 접근할 수 있어야 한다.

    • 웹 사이트를 다양한 인터페이스로 이용할 수 있어야 한다.

  • 운영체제에 독립적인 콘텐츠 제공

    • 제공되는 미디어는 운영체제에 종속적이지 않은 범용적인 포맷을 사용해야 한다.

  • 부가 기능의 호환성 확보

    • 실명인증, 전자인증 등의 부가 기능은 다양한 브라우저에서 사용할 수 있어야 한다.

  • 다양한 프로그램 제공

    • 정보를 열람하는 기능은 다양한 브라우저에서 사용할 수 있어야 한다.

    • 별도의 다운로드가 필요한 프로그램은 윈도우 / 리눅스 / 맥킨토시 중 2개 이상의 운영체제를 지원해야 한다.

Section 13. UI 설계 도구

13-1. UI 설계 도구

• 사용자의 요구사항에 맞게 UI의 화면 구조나 화면 배치 등을 설계할 때 사용하는 도구

• 와이어프레임 / 목업 / 스토리보드 / 프로토타입 / 유스케이스 등

• UI 설계 도구로 작성된 결과물은 사용자의 요구사항이 실제 구현되었을 때의 예상 결과물을 기획단계에서 미리 보여주기 위한 용도로 사용된다.

  • 화면은 어떻게 구성되는지, 어떤 방식으로 수행되는지 등

13-2. 와이어프레임(Wireframe)

• 기획 단계의 초기에 제작하는 것

• 페이지에 대한 개략적인 레이아웃이나 UI 요소 등에 대한 뼈대를 설계하는 단계

• 제작할 때 각 페이지의 영역 구분 / 콘텐츠 / 텍스트 배치 등을 화면 단위로 설계

• 개발자나 디자이너 등이 레이아웃을 협의하거나 현재 진행 상태 등을 공유하기 위해 사용

• 와이어프레임 툴 : 손그림 / 파워포인트 / 키노트 / 스케치 / 일러스트 / 포토샵 등

13-3. 목업(Mockup)

• 사용 방법 설명, 평가 등을 위해 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형

• 시각적으로만 구성 요소를 배치하며 실제로 기능이 구현되지는 않는다.

• 목업 툴 : 파워 목업 / 발사믹 목업 등

13-4. 스토리보드(Story Board)

• 와이어프레임에 콘텐츠에 대한 설명 / 페이지 간 이동 흐름 등을 추가한 문서

• 디자이너와 개발자가 최종적으로 참고하는 작업 지침서

• 정책 / 프로세스 / 콘텐츠 구성 / 와이어프레임 / 기능 정의 등 서비스 구축을 위한 모든 정보가 들어있다.

• 상단이나 우측에는 제목, 작성자 등을 입력하고 좌측에는 UI 화면, 우측에는 디스크립션(Description)을 기입한다.

• 디스크립션(Description)

  • 화면에 대한 설명 / 전반적인 로직 / 분기처리 / 예외처리 등을 작성하는 부분

  • 명확하고 세부적으로 작성해야 한다.

• 스토리보드 툴 : 파워포인트 / 키노트 / 스케치 / Axure 등

13-5. 프로토타입(Prototype)

• 와이어프레임이나 스토리보드 등에 인터랙션을 적용함으로써 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형

  • 인터랙션(Interaction) :
    UI를 통해 시스템을 사용하는 일련의 상호작용

• 사용성 테스트나 작업자 간 서비스 이해를 위해 작성하는 샘플

• 작성 방법에 따라 페이퍼 프로토타입 / 디지털 프로토타입으로 나뉜다.

• 프로토타입 툴 : HTML/CSS / Axure / Flinto / 네이버 프로토나우 / 카카오 오븐 등

13-6. 유스케이스(Use Case)

• 사용자 측면에서의 요구사항

• 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술

• 사용자의 요구사항을 빠르게 파악함으로써 프로젝트의 초기에 시스템의 기능적인 요구를 결정하고 그 결과를 문서화할 수 있다.

• 자연어로 작성된 사용자의 요구사항을 구조적으로 표현한 것

  • 일반적으로 다이어그램 형식으로 묘사된다.

• 유스케이스 다이어그램이 완성되면 각각의 유스케이스에 대해 유스케이스 명세서를 작성

Section 14. UI 요구사항 확인

14-1. UI 요구사항 확인

• 새로 개발할 시스템에 적용할 UI 관련 요구사항을 조사해서 작성하는 단계

• 다양한 경로를 통해 사용자의 요구사항을 조사하고 분석한 후 작성해야 한다.

• UI 요구사항 확인 순서 :
  목표 정의 -> 활동 사항 정의 -> UI 요구사항 작성

14-2. 목표 정의

• 사용자들을 대상으로 인터뷰를 진행한 후 사용자들의 의견이 수렴된 비즈니스 요구사항을 정의

• 인터뷰를 통해 사업적, 기술적 요구사항을 명확히 이해

• 인터뷰 진행 시 유의사항

  • 인터뷰는 가능하면 개별적으로 진행

  • 가능한 많은 사람을 인터뷰하여 다양한 의견을 수렴하되, 다수의 의견으로 인해 개인의 중요한 의견을 놓치지 않도록 주의

  • 인터뷰는 한 시간을 넘지 않도록 한다.

  • 인터뷰 진행은 반드시 사용자 리서치를 시작하기 전에 해야 한다.

    • 사용자 리서치(Research)

      • 사용자들의 요구사항이나 불편사항 등을 파악하기 위해 진행되는 것

      • 리서치 전에 인터뷰를 진행함으로써 효과적인 리서치 계획이 가능

      • 설문조사, 개인 인터뷰 등으로 진행

14-3. 활동 사항 정의

• 조사한 요구사항을 토대로 앞으로 해야 할 활동 사항을 정의

• 사용자와 회사의 비전을 일치

• 리서치 규모, 디자인 목표 등을 결정할 수 있도록 각각에 필요한 예산과 일정을 결정

• 기술의 발전 가능성을 파악하고 UI 디자인의 방향을 제시

• 인터뷰한 내용을 기반으로 경영진마다 다르게 이해하고 있는 프로젝트에 대해 정확히 이해하고 협의

• 사업 전략 및 목표 / 프로세스의 책임자 선정 / 회의 일정 및 계획 작성 / 우선순위의 선정 / 개별적인 단위 업무를 구분

14-4. UI 요구사항 작성

• 여러 경로를 통해 수집된 사용자들의 요구사항을 검토하고 분석하여 UI 개발 목적에 맞게 작성

• 반드시 실사용자 중심으로 작성

• 여러 사람의 인터뷰를 통해 다양한 의견을 수렴하여 작성

• UI 요구사항을 바탕으로 UI의 전체적인 구조를 파악 및 검토

• 작성 순서 :
  요구사항 요소 확인 -> 정황 시나리오 작성 -> 요구사항 작성

14-5. 요구사항 요소 확인

• 파악된 요구사항 요소의 종류와 각각의 표현 방식 등을 검토

• 요구사항 요소

  • 데이터 요구

    • 사용자가 요구하는 모델과 객체들의 주요 특성을 기반으로 데이터 객체들을 정리

  • 기능 요구

    • 사용자의 목적 달성을 위해 무엇을 실행해야 하는지를 동사형으로 설명

    • 기능 요구 리스트는 최대한 철저히 정리

  • 제품/서비스의 품질

    • 제품의 품질, 서비스, 감성적인 품질 등을 고려하여 작성

  • 제약 사항

    • 제품 완료 데드라인 / 전체 개발 및 제작에 필요한 비용 / 시스템 준수에 필요한 규제가 포함된다.

    • 사전에 제약사항의 변경 가능 여부를 확인한다.

14-6. 정황 시나리오 작성

• 사용자의 요구사항을 도출하기 위해 작성하는 것

• 사용자가 목표를 달성하기 위해 수행하는 방법을 순차적으로 묘사

• 정황 시나리오 : 사용자의 어떤 요구사항이 있을 때 이것을 만족하기 위해 사용자가 수행하는 과정을 이야기 형식으로 표현한 것

• 요구사항 정의에 사용되는 초기 시나리오

• 개발하는 서비스의 모습을 상상하는 첫 번째 단계

• 사용자 관점에서 시나리오를 작성해야 한다.

• 사용자가 주로 사용하는 기능 위주로 작성

• 함께 발생되는 기능들은 하나의 시나리오에 통합

• 육하원칙에 따라 간결하고 명확하게 작성

• 작성된 시나리오는 외부 전문가 또는 경험이 풍부한 사람에게 검토를 의뢰

14-7. 요구사항 작성

• 요구사항은 정황 시나리오를 토대로 작성

Section 15. 품질 요구사항

15-1. 품질 요구사항

• 소프트웨어의 품질은 소프트웨어의 기능 / 성능 / 만족도 등 소프트웨어에 대한 요구사항이 얼마나 충족하는가를 나타내는 소프트웨어 특성의 총체이다.

• 소프트웨어의 품질은 사용자의 요구사항을 충족시킴으로써 확립된다.

• ISO/IEC 9126

  • ISO/IEC 9126은 소프트웨어의 품질 특성과 평가를 위한 표준 지침으로서 국제 표준으로 널리 사용된다.

  • 개발자 관점에서 본 소프트웨어 품질의 특성에 대한 표준이다.

  • 소프트웨어의 품질에 대한 요구사항을 기술하거나 개발중인 또는 개발이 완료된 소프트웨어의 품질 평가 등에 사용된다.

  • 2011년 호환성과 보안성을 강화하여 ISO/IEC 25010으로 개정되었다.

  • ISO/IEC 9126에서 제시한 소프트웨어의 품질 특성

    • 총 6개의 특성과 각 특성에 대한 하위 특성으로 이루어져 있다.

    품질 특성	상세 품질
    기능성	- 적절성/적합성 - 정밀성/정확성 - 상호 운용성 - 보안성 - 준수성
    신뢰성	- 성숙성 - 고장 허용성 - 회복성
    사용성	- 이해성 - 학습성 - 운용성 - 친밀성
    효율성	- 시간 효율성 - 자원 효율성
    유지 보수성	- 분석성 - 변경성 - 안정성 - 시험성
    이식성	- 적용성 - 설치성 - 대체성 - 공존성

• ISO/IEC 25010

  • ISO/IEC 25010은 소프트웨어 제품에 대한 국제 표준

  • 2011년에 ISO/IEC 9126을 개정하여 만들었다.

  • ISO/IEC 25010에서 제시한 소프트웨어의 품질 특성

    품질 특성	상세 품질
    기능 적합성	- 기능 완전성 - 기능 정확성 - 기능 적절성
    성능 효율성	- 시간 효율성 - 자원 효율성 - 사양
    호환성	- 공존성 - 상호운용성
    사용성	- 적절 인지정도 - 학습성 - 조작성 - 사용자 오류 방지 - UI 미학 - 접근성
    신뢰성	- 성숙성 - 사용가능성 - 결함 허용성 - 복구성
    보안성	- 기밀성 - 무결성 - 부인방지 - 책임추적성 - 인증성
    유지 보수성	- 모듈성 - 재사용성 - 분석성 - 변경성 - 시험성
    이식성	- 적응성 - 설치성 - 대체성

※ 기타 소프트웨어 품질 관련 표준

• ISO/IEC 12119

  • ISO/IEC 9126을 준수한 품질 표준

  • 테스트 절차를 포함하여 규정

• ISO/IEC 14598

  • 필요 절차를 소프트웨어 품질의 측정과 평가에 규정한 표준

  • 개발자 / 구매자 / 평가자 별로 수행해야 할 제품 평가 활동을 규정

15-2. 기능성(Functionality)

• 소프트웨어가 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는지 여부를 나타낸다.

• 적절성/적합성(Suitability)

  • 지정된 작업과 사용자의 목적 달성을 위해 적절한 기능을 제공할 수 있는 능력

• 정밀성/정확성(Accuracy)

  • 사용자가 요구하는 결과를 정확하게 산출할 수 있는 능력

• 상호 운용성(Interoperability)

  • 다른 시스템들과 서로 어울려 작업할 수 있는 능력

• 보안성(Security)

  • 정보에 대한 접근을 권한에 따라 허용하거나 차단할 수 있는 능력

• 준수성(Compliance)

  • 기능과 관련된 표준, 관례 및 규정을 준수할 수 있는 능력

  • 준수성은 각 품질 특성에 품질 특성과 관련된 표준, 관례 및 규정을 준수할 수 있는 능력으로서 포함되어 있으나, 동일한 내용이어서 기능성에만 포함하도록 교재에는 적혀 있다. 유의할 부분.

15-3. 신뢰성(Reliability)

• 소프트웨어가 요구된 기능을 정확하고 일관되게 오류 없이 수행할 수 있는 정도

• 주어진 기능을 오류 없이 수행하는 정도

• 성숙성(Maturity)

  • 결함으로 인한 고장을 피해갈 수 있는 능력

• 고장 허용성(Fault Tolerance)

  • 결함 또는 인터페이스 결여 시에도 규정된 성능 수준을 유지할 수 있는 능력

• 회복성(Recoverability)

  • 고장 시 규정된 성능 수준까지 다시 회복하고 직접적으로 영향 받은 데이터를 복구할 수 있는 능력

15-4. 사용성(Usability)

• 사용자와 컴퓨터 사이에 발생하는 어떠한 행위에 대하여 사용자가 쉽게 배우고 사용할 수 있으며, 향후 다시 사용하고 싶은 정도

• 쉽게 배우고 사용할 수 있는 정도

• 이해성(Understandability)

  • 소프트웨어의 적합성, 사용 방법 등을 사용자가 이해할 수 있는 능력

• 학습성(Learnability)

  • 소프트웨어 어플리케이션을 학습할 수 있도록 하는 능력

• 운용성(Operability)

  • 사용자가 소프트웨어를 운용하고 제어할 수 있도록 하는 능력

• 친밀성(Attractiveness)

  • 사용자가 소프트웨어를 다시 사용하고 싶어 하도록 하는 능력

15-5. 효율성(Efficiency)

• 사용자가 요구하는 기능을 할당된 시간 동안 한정된 자원으로 얼마나 빠르게 처리할 수 있는지 정도

• 주어진 기능을 한정된 자원으로 빨리 처리하는 정도

• 시간 효율성(Rime Behaviour)

  • 특정 기능을 수행할 때 적절한 반응 시간 및 처리 시간, 처리율을 제공할 수 있는 능력

• 자원 효율성(Resource Behaviour)

  • 특정 기능을 수행할 때 적절한 자원의 양과 종류를 제공할 수 있는 능력

15-6. 유지 보수성(Maintainability)

• 환경의 변화 또는 새로운 요구사항이 발생했을 때 소프트웨어를 개선하거나 확장할 수 있는 정도

• 개선과 확장이 쉬운 정도

• 분석성(Analyzability)

  • 결함이나 고장의 원인, 수정될 부분들의 식별을 가능하게 하는 능력

• 변경성(Changeability)

  • 결함 제거 또는 환경 변화로 인한 수정 등을 쉽게 구현할 수 있는 능력

• 안정성(Stability)

  • 변경으로 인한 예상치 못한 결과를 최소화할 수 있는 능력

• 시험성(Testability)

  • 소프트웨어의 변경이 검증될 수 있는 능력

15-7. 이식성(Portability)

• 소프트웨어가 다른 환경에서도 쉽게 적용될 수 있는 정도

• 적용성(Adaptability)

  • 원래의 목적으로 제공되는 것 외에 다른 환경으로 변경될 수 있는 능력

• 설치성(Installability)

  • 임의의 환경에 소프트웨어를 설치할 수 있는 능력

• 대체성(Replaceability)

  • 동일한 환경에서 동일한 목적을 위해 다른 소프트웨어를 대신하여 사용될 수 있는 능력

• 공존성(Co-existence)

  • 자원을 공유하는 환경에서 다른 소프트웨어와 공존할 수 있는 능력

Section 16. UI 프로토타입 제작 및 검토

16-1. UI 프로토타입의 개요

• 사용자 요구사항을 기반으로 실제 동작하는 것처럼 만든 동적인 형태의 모형

• 완전한 UI를 만들기 전에 사용자와의 의사소통을 위해 만든 모형

• 테스트가 가능하다.

• 최종적으로 구현할 화면의 주요 기능을 직접 실행해 볼 수 있도록 미리 만들어본 임시 화면

• 사용자의 요구사항을 개발자가 맞게 해석했는지 검증하기 위한 것

• 최대한 간단하게 만들어야 한다.

• 일부 핵심적인 기능만을 제공하지만 최종 제품의 작동 방식을 이해시키는데 필요한 기능은 반드시 포함되어야 한다.

• 사용자 요구사항이 모두 반영될 때까지 프로토타입을 계속하여 개선하고 보완해야 한다.

• 프로토타이핑 및 테스트를 거치지 않고는 실제 사용자와 제품 간의 상호 작용 방식을 예측하기 어려우므로 실제 사용자를 대상으로 테스트하는 것이 좋다.

  • 프로토타이핑

    • 프로토타입을 만드는 과정

    • 사용자의 요구사항 검토부터 최종적인 프로토타입 완성까지 반복적으로 수행되는 전 과정

16-2. UI 프로토타입의 장·단점

• 장점

  • 사용자를 설득하고 이해시키기 쉽다.

  • 요구사항과 기능의 불일치 등으로 인한 혼선을 예방할 수 있어 개발 시간을 줄일 수 있다.

  • 사전에 오류를 발견할 수 있다.

• 단점

  • 프로토타입에 사용자의 모든 요구사항을 반영하기 위한 반복적인 개선 및 보완 작업 때문에 작업 시간을 증가 시킬 수 있고, 필요 이상으로 자원을 소모할 수 있다.

  • 부분적으로 프로토타이핑을 진행하다보면 중요한 작업이 생략될 수 있다.

16-3. 프로토타이핑의 종류

• 페이퍼 프로토타입(Paper Prototype)

  • 아날로그적인 방법

  • 스케치, 그림, 글 등을 이용하여 손으로 직접 작성하는 방법

  • 제작 기간이 짧은 경우 / 제작 비용이 적을 경우 / 업무 협의가 빠를 경우 사용

  • 장점

    • 비용이 저렴

    • 회의 중 대화하면서 생성이 가능

    • 즉시 변경이 가능

    • 고객이 과다한 기대를 하지 않는다.

  • 단점

    • 테스트하기에 부적당

    • 상호 관계가 많은 경우 나타내기 복잡하다.

    • 여러 사람들에게 나눠주거나 공유하기 어렵다.

• 디지털 프로토타입(Digital Prototype)

  • 프로그램을 사용하여 작성하는 방법

    • 파워포인트, 아크로뱃, 비지오, 옴니그래플 등

  • 재사용이 필요한 경우 / 산출물과 비슷한 효과가 필요한 경우 / 숙련된 전문가가 있을 경우 사용

  • 장점

    • 최종 제품과 비슷하게 테스트 가능

    • 수정이 쉽다.

    • 재사용 가능

  • 단점

    • 프로토타입을 작성할 프로그램의 사용법을 알아야 한다.

16-4. UI 프로토타입 계획 및 작성 시 고려 사항

• 일반적으로 프로토타입의 개발 계획을 수립하는 과정과 프로토타입을 개발한 후 결과를 보고하는 과정으로 진행된다.

• 계획 시 고려 사항

  • 프로토타입의 개발 목적 확인

  • 소프트웨어, 하드웨어 등 프로토타입 개발 환경 마련

  • 프로토타이핑 일정은 일반적으로 아키텍처가 확정된 이후, 프로젝트의 실제 분석 작업이 완료되기 이전에 진행

    • 대형 프로젝트의 프로토타이핑 일정

      • 프로토타입의 개발 목적이 아키텍처 검증인 경우 :
        프로젝트 개발 이전에 완료하거나 대략 1개월 정도로 잡는 것이 좋다.

      • 프로토타입의 개발 목적이 분석, 설계 가이드에 대한 검증인 경우 :
        2개월을 추가할 수 있다.

  • 아키텍처의 핵심이 되는 UI 요소를 프로토타입의 범위로 잡는다.

  • 프로토타입의 개발 인원을 확인한다.

    • 리더 / 솔루션 담당자 / 인프라 담당자 / 개발 환경 리더 / 공통 모듈 개발자 / 프로토타입 개발자 등

    • 대형 프로젝트의 프로토타입 개발 인원

      • 리더 1인 / 솔루션 담당자 파트타임 2인 이상 / 인프라 담당자 파트타임 1인 / 개발 환경 리더 겸 공통 모듈 개발자 1인 / 프로토타입 개발자 3 ~ 5인 구성

  • 주어진 비즈니스 요구사항을 모두 만족하는지 프로토타입 아키텍처를 검증

  • 프로토타입을 통해 발생하는 이슈를 모두 취합하고 해결 방법 제시

    • 프로토타입 이슈

      • 대부분 소프트웨어 아키텍처의 요소를 검증하는 과정에서 발생

      • 이슈는 많이 발생할수록 좋은 것

      • 프로토타입 리더는 이슈를 종류별로 취합하고 해결 방법을 제시해야 하며, 이를 모두 정리해서 보고해야 한다.

  • 프로토타이핑를 진행하면서 분석 / 설계 / 개발 / 테스트 등의 표준 가이드를 확정

  • 프로토타이핑을 진행하면서 가장 많은 시간이 소요된 구간을 찾고 원인 분석, 해결 방법 제시

  • 고객과 프로젝트 매니저, 프로젝트 리더 등에게 완성된 프로토타입을 시연

• 작성 시 고려 사항

  • 프로토타입의 작성 계획 수립

  • 프로젝트의 범위나 리스크 상황 등 주변 여건을 감안해서 프로토타입의 범위를 결정

  • 프로토타입을 통해서 얻고자 하는 목표 확인

  • 프로토타입의 개발 목표 달성을 위한 필요 최소 기간과 비용을 확인

  • 완성된 프로토타입이 실제 개발에 참조 가능한지 확인

  • 프로토타입으로 검증할 범위가 너무 넓거나 기간이 길면 목표가 커져 문제가 될 수 있으므로 주의

16-5. UI 프로토타입 제작 단계

• 1단계

  • 사용자의 요구사항을 분석하는 단계

  • 사용자 관점에서 기본적인 요구사항이 확정될 때까지 수행

• 2단계

  • 요구사항을 충족하는 프로토타입을 작성

  • 프로토타입은 개발할 시스템의 핵심 기능을 중심으로 개발

• 3단계

  • 작성된 프로토타입이 요구사항을 잘 수행하는지 사용자가 직접 확인하는 단계

  • 프로토타입에 대해 다양한 추가 및 수정 의견을 제안 가능

• 4단계

  • 작성된 프로토타입을 기반으로 수정과 합의가 이뤄지는 단계

  • 개발자는 사용자가 요청한 제안 사항을 수용하여 보완 작업을 진행

  • 작업이 완료된 후 3단계로 되돌아간다.

  • 사용자가 최종적으로 승인을 완료할 때까지 3단계와 4단계가 반복된다.

Section 17. UI 설계서 작성

17-1. UI 설계서의 개요

• 사용자의 요구사항을 바탕으로 UI 설계를 구체화하여 작성하는 문서

• 실제 사용할 UI 화면을 설계하기 전에 사용자의 요구사항을 가시화하고 검증하기 위해 작성하는 것

• 상세 설계 전에 대표적인 화면들을 설계

• 기획자, 개발자, 디자이너 등과의 원활한 의사소통을 위해 작성

• UI 설계서 표지 -> UI 설계서 개정 이력 -> UI 요구사항 정의서 -> 시스템 구조 -> 사이트 맵 -> 프로세스 정의서 -> 화면 설계 순으로 작성

17-2. UI 설계서 표지 작성

• 다른 문서와 혼동되지 않도록 프로젝트명 또는 시스템명을 포함시켜 작성

17-3. UI 설계서 개정 이력 작성

• UI 설계서가 수정될 때마다 어떤 부분이 어떻게 수정되었는지를 정리해 놓은 문서

• 처음 작성 시 첫 번째 항목을 '초안 작성', 버전(Version)을 1.0으로 설정

• UI 설계서에 변경 사항이 있을 때마다 변경 내용을 적고 버전을 0.1씩 높인다.

17-4. UI 요구사항 정의서 작성

• 사용자의 요구사항을 확인하고 정리한 문서

• 사용자 요구사항의 UI 적용 여부를 요구사항별로 표시

17-5. 시스템 구조 작성

• UI 요구사항과 UI 프로토타입에 기초하여 전체 시스템의 구조를 설계한 것

• 사용자의 요구사항이 어떻게 시스템에 적용되는지 알 수 있다.

17-6. 사이트 맵(Site Map) 작성

• 시스템 구조를 바탕으로 사이트에 표시할 콘텐츠를 한 눈에 알아 볼 수 있도록 메뉴별로 구분하여 설계한 것

• 사이트 맵을 작성한 후 사이트 맵의 상세 내용(Site Map Detail)을 표 형태로 작성

17-7. 프로세스(Process) 정의서 작성

• 사용자 관점에서 사용자가 요구하는 프로세스들을 작업 진행 순서에 맞춰 정리한 것

• UI의 전체적인 흐름 파악 가능

17-8. 화면 설계

• UI 프로토타입과 UI 프로세스를 참고하여 필요한 화면을 페이지별로 설계한 것

• 화면을 구분하기 위해 화면별 고유ID를 부여하고 별도 표지를 작성

• 대표적인 화면들에 대해 포함될 정보 / 인터페이스 요소 / 레이아웃 등이 표현된 와이어프레임을 대략적으로 스케치

  • 와이어프레임(Wireframe)

    • 기획 단계의 초기에 제작하는 것

    • 페이지에 대한 개략적인 레이아웃이나 UI 요소 등에 대한 뼈대를 설계하는 단계

• 주요 흐름을 스토리보드 형태로 작성

  • 디스크립션에는 시스템 정보 / 인터렉션 / 로직 / 정책 등 디자인하거나 설계할 때 필요한 사항을 기록

  • 스토리보드(Story Board)

    • 와이어프레임에 콘텐츠에 대한 설명 / 페이지 간 이동 흐름 등을 추가한 문서

※ UI 화면 설계의 기본 구성 요소

• 윈도우(Window)

  • 키보드나 마우스 등을 통해 데이터 입력 및 결과를 보여주는 화면상의 표시 영역

• 메뉴(Menu)

  • 화면에서 수행할 기능들을 일정한 형태로 모아놓은 인터페이스

  • 사용자로 하여금 기능 선택을 수월하게 한다.

• 아이콘(Icon)

  • 수행하고자 하는 동작 / 동작의 대상 등을 작은 그림 형태로 표현한 인터페이스

  • 동일한 사용 환경 안에서는 아이콘의 크기는 동일하거나 규칙적인 크기 안에서 제공해야 한다.

• 포인터(Pointer)

  • 입력이 이뤄지는 지점을 알려주는 화면상의 커서

  • 시스템의 상태를 포인터의 모양으로도 표시한다.

Section 18. 유용성 평가

18-1. UI의 유용성 평가

• 유용성(Usability) :
  사용자가 시스템을 통해 원하는 목표를 얼마나 효과적으로 달성할 수 있는가에 대한 척도

• UI의 주된 목적은 유용성이 뛰어난 UI를 제작하는 것

  • 좋은 UI는 유용성이 뛰어난 UI

  • 유용성이 뛰어난 UI를 설계하려면 사용자와 개발자가 생각하는 완성된 모형의 차이가 작아야 한다.

• 유용성 평가

  • 사용자 측면에서 복잡한 시스템을 얼마나 편리하게 사용할 수 있는지를 평가하는 것

  • 시스템의 문제점을 찾아내고 개선 방향을 제시하기 위한 조사 과정

• 유용한 UI를 설계하기 위해서는 UI의 구조 / 기능 / 가치 등에 대해 사용자가 생각하는 사용자 모형과 시스템 설계자가 만들려고 하는 개발자 모형 간의 차이를 최소화해야 한다.

• 사용자 모형과 개발자 모형 간의 차이가 발생하는 원인

  • 실행 차

    • 사용자가 원하는 목적과 실행 기능이 다르기 때문에 발생

  • 평가 차

    • 사용자가 원하는 목적과 실행 결과가 다르기 때문에 발생

18-2. 실행 차를 줄이기 위한 UI 설계 원리 검토

1. 사용 의도 파악

   • 사용자의 목적을 명확히 파악한 후 불필요한 기능 / 중복되는 기능이 있는지 확인

2. 행위 순서 규정

   • 특정 기능을 사용하기 위한 행위 순서를 세분화시켜 순서대로 제시

   • 사용자가 임의로 행위 순서를 변경할 수 있도록 한다.

   • 특정 작업을 수행하기 위한 단계는 최소화

   • 다양한 방법을 통해 수행할 수 있도록 설계

   • 사용자의 기존 경험에 비추어 가능한 한 친숙하도록 설계

3. 행위의 순서대로 실행

   • 프로세스의 흐름을 직접적으로 파악할 수 있도록 제공

   • 사용자가 행위 순서대로 실행할 때 어려움이 없어야 한다.

   • 과도한 상호 작용은 피한다.

     -> 작업이 원활하게 진행되도록 하기 위함

   • 사용자가 의도한 행위를 효율적으로 실행할 수 있도록 피드백 / 취소 기능 / 디폴트 값 등을 적절하게 설정

18-3. 평가 차를 줄이기 위한 UI 설계 원리 검토

1. 수행한 키 조작의 결과를 사용자가 빠르게 지각하도록 유도

   • 사용자가 수행한 행위에 대해 최대한 빨리 반응하도록 설계

   • 사용자가 수행한 행위로 인해 현재 시스템의 변화를 직접적으로 파악할 수 있도록 피드백해야 한다.

2. 키 조작으로 변화된 시스템의 상태를 사용자가 쉽게 인지하도록 유도

   • 시스템의 상태 정보를 가능한 한 단순하고 이해하기 쉽게 제시

3. 사용자가 가진 원래 의도와 시스템 결과 간의 유사 정도를 사용자가 쉽게 파악하도록 유도

   • 사용자의 의도가 시스템을 통해 충족되었는지, 충족될 수 있는지를 사용자가 쉽게 파악할 수 있도록 설계

Section 19. UI 상세 설계

19-1. UI 시나리오 문서 개요

• UI 상세 설계는 UI 설계서를 바탕으로 실제 설계 및 구현을 위해 모든 화면에 대한 자세한 설계를 진행하는 단계

  • UI 설계서

    • UI 흐름 설계와 UI 상세 설계 모두에서 작성한다.

    • UI 흐름 설계에서 UI 설계서의 기본 토대를 작성

    • UI 상세 설계에서는 흐름 설계에서 작성한 UI 설계서를 다시 한번 확인하고 추가, 수정하여 완성

• UI 상세 설계를 할 때는 반드시 시나리오를 작성해야 한다.

• 사용자 인터페이스의 기능 구조 / 대표 화면 / 화면 간 인터랙션의 흐름 / 다양한 상황에서의 예외 처리 등을 문서로 정리한 것

  • 인터랙션(Interaction) :
    사용자와 시스템을 연결하는 것이 UI라면, 인터랙션은 UI를 통해 시스템을 사용하는 일련의 상호작용

• 사용자가 최종 목표를 달성하기 위한 방법을 순차적으로 묘사

• UI 설계자 또는 인터랙션 디자이너가 UI 시나리오 문서를 작성하면 그래픽 디자이너가 시나리오를 바탕으로 디자인, 개발자가 UI 구현

  • 인터랙션 디자이너
    • 제품, 시스템, 서비스에 대한 사용자의 행동과 그에 반응하는 절차를 디자인하는 사람

19-2. UI 시나리오 문서 작성 원칙

• 개발자가 전체적인 UI의 기능과 작동 방식을 한눈에 이해할 수 있도록 구체적으로 작성

• 보통 계층(Tree) 구조 또는 플로차트(Flow Chart) 표기법으로 작성

• 모든 기능에 공통적으로 적용될 UI 요소와 인터랙션을 일반 규칙으로 정의

• 대표 화면의 레이아웃과 그 화면에 속할 기능을 정의

• 인터랙션의 흐름을 정의

  • 화면 간 인터랙셩의 순서(Sequence), 분기(Branch), 조건(Condition), 루프(Loop) 등을 명시

• 예외 상황에 대비한 다양한 케이스를 정의

• UI 일반 규칙을 지키면서 기능별 상세 기능 시나리오를 정의

• UI 시나리오 규칙을 지정

19-3. UI 시나리오 문서 작성을 위한 일반 규칙

• 주요 키의 위치와 기능

  • 모든 화면에 공통적으로 배치되는 주요 키의 위치와 기능을 설명한 것

  • 여러 화면 간의 일관성을 보장

• 공통 UI 요소

  • 체크 박스, 라디오 버튼, 텍스트 박스 등의 UI 요소를 언제, 어떤 형태로 사용할지를 정의

  • 사용자가 조작하면 어떻게 반응하는지 그 흐름을 설명

• 기본 스크린 레이아웃(Basic Screen Layouts)

  • 모든 화면에 공통적으로 나타나는 Titles / Ok/Back / Soft Key / Option / Functional Buttons 등의 위치와 속성을 정의

• 기본 인터랙션 규칙(Basic Interaction Rules)

  • 많은 기능들에 공통적으로 사용되는 조작 방법 / 실행 / 이전 / 다음 / 삭제 / 이동 등의 화면 전환 효과 등을 기술

• 공통 단위 태스크 흐름(Task Flows)

  • 많은 기능들에 공통적으로 사용되는 삭제 / 검색 / 매너 모드 상태 등에 대한 인터랙션 흐름을 설명

• 케이스 문서

  • 다양한 상황에서 공통적으로 적용되는 시스템의 동작을 정의한 문서

※ UI 요소

• 체크 박스(Check Box) :
  여러 개의 선택 상황에서 1개 이상의 값을 선택할 수 있는 버튼

• 라디오 버튼(Radio Button) :
  여러 항목 중 하나만 선택할 수 있는 버튼

• 텍스트 박스(Text Box) :
  사용자가 데이터를 입력하고 수정할 수 있는 상자

• 콤보 상자(Combo Box) :
  이미 지정된 목록 상자에 내용을 표시하여 선택하거나 새로 입력할 수 있는 상자

• 목록 상자(List Box) :
  콤보 상자와 같이 목록을 표시하지만 새로운 내용을 입력할 수 없는 상자

19-4. UI 시나리오 문서의 요건

• 완전성(Complete)

  • 누락되지 않도록 최대한 상세히 기술

  • 해당 시스템의 기능보다는 사용자의 태스크에 초점을 맞춰 기술

• 일관성(Consistent)

  • 서비스 목표 / 시스템 및 사용자 요구사항 / UI 스타일 등이 모두 일관성을 유지해야 한다.

• 이해성(Understandable)

  • 누구나 쉽게 이해할 수 있도록 설명

  • 불분명하거나 추상적인 표현은 피한다.

• 가독성(Readable)

  • 표준화된 템플릿 등을 활용하여 문서를 쉽게 읽을 수 있도록 해야 한다.

    • 템플릿(Template)

      • 형판, 형틀이라는 뜻

      • 화면의 기본 레이아웃 형태를 의미

  • v1.0, v2.0 등과 같이 문서 인덱스에 대한 규칙이나 목차를 제공

  • 읽기 쉽도록 줄 간격, 단락, 들여쓰기 등의 기준 마련

  • 시각적인 효과를 위해 여백 / 빈 페이지 / 하이라이팅 등을 일관성 있게 지정

  • 하이퍼링크 등을 지정하여 문서들이 서로 참조될 수 있도록 지정

• 수정 용이성(Modifiable)

  • 시나리오의 수정이나 개선이 쉬워야 한다.

• 추적 용이성(Traceable)

  • 변경 사항은 언제, 어떤 부분이, 왜 발생했는지 쉽게 추적할 수 있어야 한다.

19-5. UI 시나리오 문서로 인한 기대 효과

• 요구사항이나 의사소통에 대한 오류 감소

• 개발 과정에서의 재작업 감소, 혼선 최소화

• 불필요한 기능 최소화

• 소프트웨어 개발 비용 절감

• 개발 속도 향상

Section 20. HCI/UX/감성공학

20-1. HCI(Human Computer Interaction of Interface)

• 사람이 시스템을 보다 편리하고 안전하게 사용할 수 있도록 연구하고 개발하는 학문

• 최종 목표는 시스템을 사용하는데 있어 최적의 사용자 경험(UX)을 만드는 것

  • UX와 감성공학

    • UX : 제품을 사용하고 느낀 총체적 경험

    • 감성공학의 감성 : 경험을 통해 얻은 복합적 감각

• 원래 HCI는 사람과 컴퓨터의 상호작용을 연구해 사람이 컴퓨터를 편리하게 사용하도록 만드는 학문

• 대상이 컴퓨터뿐만 아니라 서비스, 디지털 콘텐츠 등으로, 사람도 개인뿐만 아니라 사회나 집단으로 확대됨

• HCI는 어떤 제품이 좋은 제품인지, 어떻게 하면 좋은 제품을 만들 수 있는지 등을 연구

20-2. UX(User Experience)

• 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하게 되는 총체적 경험

• 단순히 기능이나 절차상의 만족뿐만 아니라 사용자가 참여 / 사용 / 관찰하고 상호 교감을 통해 알 수 있는 가치 있는 경험

• 기술을 효용성 측면에서만 보는 것이 아니라 사용자의 삶의 질을 향상시키는 하나의 방향으로 보는 새로운 개념

• UI가 사용성 / 접근성 / 편의성을 중시한다면 UX는 UI를 통해 사용자가 느끼는 만족, 감정을 중시

• UX의 특징

  • 주관성(Subjectivity)

    • 사람들의 개인적 / 신체적 / 인지적 특성에 따라 다르므로 주관적

  • 정황성(Contextuality)

    • 경험이 일어나는 상황 또는 주변 환경에 영향을 받는다.

  • 총체성(Holistic)

    • 개인이 느끼는 총체적인 심리적, 감성적 결과

20-3. 감성공학

• 제품이나 작업환경을 사용자의 감성에 알맞도록 설계 및 제작하는 기술

  • 감성
    • 감성공학의 '감성'은 사용자가 제품을 사용한 경험을 통해 얻은 복합적인 감각을 의미

• 인문사회과학, 공학, 의학 등 여러 분야의 학문이 공존하는 종합과학

• '감성'을 과학적으로 측정하기 위해서는 생체계측 기술 / 감각계측 기술 / 센서 / 인공지능 / 생체제어 기술 등이 요구된다.

• 감성공학의 목적은 인간의 삶을 편리하고 안전하며 쾌적하게 만드는 것

• 감성공학은 인간의 감성을 구체적으로 제품 설계에 적용하기 위해 공학적인 접근 방법을 사용한다.

• 인간의 신체적, 정신적 특성을 배려한 제품 설계에서 더 나아가 인간의 감성까지 고려한다.

• 감성공학은 인간과 컴퓨터의 상호작용을 나타내는 HCI(Human Computer Interaction or Interface) 설계에 인간의 특성과 감성을 반영하였다.

• 감성공학의 요소기술

  • 기반 기술

    • 제품 설계에 적용할 인간의 특성 파악

  • 구현 기술

    • 인간의 특성에 맞는 인터페이스 구현

  • 응용 기술

    • 인간에 맞는지 파악하여 새로운 감성을 만든다.