[자격증] 정보처리기사 실기 : 16강 화면 설계 (UI 요구사항 확인하기)

 정보

• 업무명     : 정보처리기사 실기 : 16강 화면 설계 (UI 요구사항 확인하기)

• 작성자     : 이상호

• 작성일     : 2020-05-10

• 설   명      :

• 수정이력 :

 

 

 내용

[UI 요구사항 확인]

[1] 소프트웨어 아키텍처 개념

• 1. 소프트웨어 아키텍처란 

   

  • 소프트웨어 아키텍처는 개발하고자 하는 소프트웨어의 사전 작업을 통하여 소프트웨어 개발을 쉽게 하도록 기본 틀을 만드는 것으로, 복잡한 개발을 체계적으로 접근하기 위 한 밑그림이라 할 수 있다. 학술적인 정의로는 권도형(2004)에 따르면 소프트웨어를 구성하는 컴포넌트들의 상호 작용 및 관계, 각각의 특성을 기반으로 컴포넌트들이 상호 유기적으로 결합하는 소프트웨어의 진화를 위한 여러 가지 원칙들의 집합이라고 할 수 있다. 

 

• 2. 소프트웨어 아키텍처의 활용 

   

  • 소프트웨어 아키텍처의 중요성과 활용 방법에 대해 살펴보면, 비교적 간단한 소프트웨 어를 개발할 때에는 완성해야 하는 목적과 기능을 중점으로 설계하여도 품질에는 큰 문제가 없다. 

     

  • 그렇지만 소프트웨어의 기능이 복잡, 다양해짐에 따라, 그 기능을 목적에 알맞게 정의하여 분류하여야 하는 명제를 안게 되었다. 

     

  • 분류된 기능이 세분화되면 상호간에 유기적으로 통합하는 과정이 매우 어려워진다. 그러므로 완전한 소프트웨어를 개발하기 위하여 각각의 기능적 특성을 사전에 파악하여 요구 분석 단계부터 설계 단계까지 분류된 기능과 함께 종합적인 시각으로 판단하는 것이 매우 필요해진다. 

     

  • 이런 이유로 개발하고자 하는 소프트웨어 시스템을 다양한 시각에서 모형화하고 문제 의 특성과 본질을 파악하고 필요에 따라 활용할 방안이 요구되었다. 이에 대한 방안으로 필요한 것이 아키텍처이다.

[2] UI(User Interface)의 활용

• UI 흐름 이해, 상세 내용 파악, 가이드라인 비교, 활용에 대해 알아본다. 

   

• 1. UI 흐름 이해

   

  • UI 각각의 상세 내역을 확인하기 전에 먼저 큰 흐름을 살펴보아야 한다. 목적과 그에 맞는 용도, 개발 배경 등 가장 기본이 되는 사항을 확인하여야 하며, 서로 다른 부서 또는 조직 간의 관계와 역할에 대해 명확하게 이해하고 있어야 한다. 

     

 

• 2 UI 상세 

   

  • UI를 쉽게 풀이하면 사용자와 컴퓨터 상호 간의 소통을 원활히 하게 도와주는 연계 작 업을 뜻한다. 1990년대부터 시작하였으며 초창기에는 사용자와 컴퓨터의 단순한 상호 작용에 국한된 연구에서 출발하였다. 이후 업무가 복잡해지고 다양해지면서 단순한 방 법으로는 많은 문제점이 발생함에 따라 오류를 줄이기 위한 방법으로 변화되었다. 현 재에는 작업 수행 내역을 구체적으로 작성하는 기능 위주에서 단순한 기능 전달이 아 닌 정보의 내용과 그 안에 포함된 뜻을 전달하는 표현 방법으로 변화하였다.

• (1) UI의 세 가지 분야 

   

  • (가) 정보 제공과 기능 전달을 위한 물리적 제어 분야 

     

  • (나) 콘텐츠의 상세적 표현과 전체적 구성에 관한 분야 

     

  • (다) 사용자의 편의성에 맞춰 쉽고 간편하게 사용 가능하게 하는 기능적 분야 

     

• (2) UI의 설계 원칙 

   

  • (가) 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 한다. 

     

  • (나) 유효성 : 사용자의 목적을 정확하게 달성하여야 한다. 

     

  • (다) 학습성 : 누구나 쉽게 배우고 익힐 수 있어야 한다. 

     

  • (라) 유연성 : 사용자의 요구사항을 최대한 수용하며, 오류를 최소화하여야 한다.

• (3) UI의 설계 지침 

   

  • (가) 사용자 중심 : 사용자가 이해하기 편하고 쉽게 사용할 수 있는 환경을 제공하 며 실사용자에 대한 이해가 바탕이 되어야 한다. 

     

  • (나) 일관성 : 버튼이나 조작 방법을 사용자가 기억하기 쉽고 빠른 습득이 가능하게 설계하여야 한다. 

     

  • (다) 단순성 : 조작 방법은 가장 간단하게 작동이 가능하도록 하여 인지적 부담을 감소시켜야 한다. 

     

  • (라) 결과 예측 가능 : 작동시킬 기능만 보고도 결과 예측이 가능하여야 한다. 

     

  • (마) 가시성 : 주요 기능을 메인 화면에 노출하여 조작이 쉽도록 하여야 한다.

     

  • (바) 표준화 : 디자인을 표준화하여 기능 구조의 선행 학습 이후 쉽게 사용할 수 있 어야 한다. 

     

  • (사) 접근성 : 사용자의 직무, 연령, 성별 등 다양한 계층을 수용하여야 한다. 

     

  • (아) 명확성 : 사용자가 개념적으로 쉽게 인지하여야 한다. 

     

  • (자) 오류 발생 해결 : 사용자가 오류에 대한 상황을 정확히 인지할 수 있어야 한다.

• (4) UI가 필요한 이유 

   

  • (가) 구현하고자 하는 결과의 오류를 최소화하고 적은 노력으로 구현하는 결과를 얻 을 수 있다. 

     

  • (나) 막연한 작업 기능에 대해 구체적인 방법을 제시하여 준다. 

     

  • (다) 사용자의 편의성을 높임으로써 작업 시간 단축과 업무에 대한 이해도를 높여 준다. 

     

  • (라) 정보 제공자와 공급자의 원활하고 쉬운 매개 역할을 수행한다.

 

[3] UI 요구사항 정의

• 김영훈(2012)에 의하면 기술의 발전과 기업 환경의 변화에 맞춰 기업의 업무용 소프트웨어 도 기존에는 단순하고 체계적이면서 구조화된 기능 중심 관점에서 그 기능을 중심으로 획 일화된 UI를 공급하는 소프트웨어 방법을 취했다면, 이제는 시스템을 주로 이용하는 사용자 요구와 필요 기능을 중심으로 UI를 공급함으로써 실체적이고 효과적인 사용자 요구 기 능에 알맞은 서비스를 제공하는 형태로 진화하고 있다. 

   

• 1. 품질 요구사항 소프트웨어 아키텍처 품질 특성 도출은 아키텍처 방법론에 정의된 항목을 중심으로 작성한다.

 

• 2. 품질 요구사항 특성

 

• (1) 기능성(Functionality) 

   

  • 실제 수행 결과와 품질 요구사항과의 차이를 분석하고, 실제 사용 시 정확하지 않은 결과가 발생할 확률 등과 관련하여 시스템의 동작을 관찰하기 위한 품질 기준이다.

 

• (2) 신뢰성(Reliability) 

   

  • 시스템이 일정한 시간 또는 작동되는 시간 동안 의도하는 기능을 수행함을 보증한다.

 

• (3) 사용성(Usablity)

   

  • 사용자와 컴퓨터 사이에 발생하는 어떠한 행위를 정확하고 쉽게 인지 가능함을 의미 한다.

 

• (4) 효율성(Efficiency) 

   

  • 할당된 시간에 한정된 자원으로 얼마나 빨리 처리하는가를 의미한다.

 

• (5) 유지 보수성(Maintainability) 

   

  • 요구사항을 개선하고 확장하는 데 있어 얼마나 용이한가를 의미한다.

 

• (6) 이식성(Portability) 

   

  • 다른 플랫폼(운영 체제)에서도 많은 추가 작업 없이 얼마나 쉽게 적용이 가능한가를 의미한다

 

[4] UI 요구사항 확인

• 1. UI 요구사항 확인 

   

  • 프로젝트의 요구사항은 크게 시스템이 무엇을 하여야 하는지를 설명하는 기능적 요구사항 (Functional Requirements)과 개발 과정에서 지켜져야 할 제약조건들을 설명하는 비기능적 요구사항(Nonfunctional Requirements)으로 나눠진다.

     

  • (1) 기능적 요구사항 

     

    • (가) 시스템의 입력으로 무엇이 포함되어야 하나? 

       

    • (나) 시스템의 출력으로 무엇이 포함되어야 하나? 

       

    • (다) 시스템이 어떤 데이터를 저장해야 하나? 

       

    • (라) 시스템이 어떤 연산을 수행해야 하나? 

       

    • (마) 기타 요구사항(예: 동기화 등） 

       

  • (2) 비기능적 요구사항 

     

    • (가) 사용성, 효율성, 신뢰성, 유지 보수성, 재사용성 등 품질에 관한 요구사항 

       

    • (나) 플랫폼, 사용 기술 등 시스템 환경에 관한 요구사항 

       

    • (다) 비용, 일정 등 프로젝트 계획에 관한 요구사항

 

[수행]

[1] 응용 소프트웨어 개발을 위한 UI 표준 및 지침을 확인한다.

• UI 표준에 맞춰 기본 화면 구조, 액션 인터페이스(Action Interface), 화면 배치(Layout), 일 반 UI 네비게이션 표준 방식, 화면 구성 요소, 업무별 화면 샘플, 메시지 창, 버튼 목록, 배치(버튼, 필드), 데이터 포맷(Data Format)을 확인한다. 

   

• 1. UI 스타일 가이드를 정의한다. 

   

  • (1) 구동 환경을 정의한다. 

     

    • (가) 컴퓨터 OS를 확인한다. 기업이 운영하고 있는 업무와 보안성이 높은 운영 체제(OS)를 확인한다. 

       

    • (나) 웹 브라우저를 확인한다. 웹 브라우저는 익스플로러, 크롬, x-internet 등 기업 환경에 가장 적합한 것으로 확정한다.

       

    • (다) 모니터 해상도를 확인한다. 

       

      • 모니터 해상도는 1280px*1024px을 표준으로 한다. 컴퓨터 작업 표시줄 및 브라우저 의 기본 환경(Setting)을 기준으로 브라우저 스크롤이 생기지 않는 안전 지역(Safety Area)은 1280px*2014px로 한다. 

         

    • (라) 프레임 세트를 확인한다. 

       

      • 업무 처리가 주목적으로, 속도 및 업무 편의성을 고려하여 각 영역별(Top, Left, Contents 영역) 프레임을 구분해 적용한다. 

 

• (2) 레이아웃을 정의한다. 

   

  • (가) 화면 구조를 정의한다. 

     

    • 기본 배치(Layout)는 크게 Top, Left, Contents 영역의 3개 부분으로 설계하며, 하단 메뉴 구성(Footer Area)은 상황에 맞게 추가하거나 제외해도 된다. 

       

  • (나) 상단 메뉴 구성(Top Area)을 정의한다. 

     

    • 필수적으로 적용하는 사항이며, 구성 요소로는 시스템 로고(System Logo), 로그인 사용자(Login User), 바로가기 메뉴(Quick Menu), 주 메뉴(Main Navigation)가 있다. 시스템 전체 페이지에 동일하게 적용되며 변경이나 추가가 필요한 경우 주 메뉴 크기만 변경 가능하게 한다. 

    • 1) ⓐ Logo Area(로고 구역) 

       

      • 화면 왼쪽 상단에 위치하며 회사 로고(Logo) + 시스템 로고(System Logo)가 들 어간다. 여백의 사이즈는 일정하게 하며, 페이지별로 크기를 고정하여 웹 사이 트 전체에 일관성 있게 구현되도록 한다. 시스템별 특성에 맞는 로고를 제작해 적용한다. 시스템 로고에 링크(Link)를 걸어 메인 화면(Application Main Page)으 로 이동 가능하도록 한다. 

         

    • 2) ⓑ Login User(접속자) 정보 

       

      • 화면 우측 상단 첫 번째에 위치하며, 접속자에 대한 정보를 표시(Display)한다. (예) [홍길동 0000000]님 로그인 

         

    • 3) ⓒ Quick Menu(바로가기 메뉴) 

       

      • Logo 우측 상단 두 번째에 위치하며, 홈(Home), 매뉴얼(Manual), 사이트 맵(Site map), 관리자(Admin) 등 화면(Site) 전반에 걸친 메뉴를 우측 정렬로 배치한다. 

         

    • 4) ⓓ Main Navigation(주 메뉴) 

       

    • 로고 우측 상단 두 번째 줄에 위치하며, 시스템의 주 메뉴를 왼쪽 정렬로 배치 한다. 마우스 오버 시 해당 메뉴의 배경 화면색(Back Ground Color) 혹은 글자 색(Text Color)이 변경되도록 한다. 첫 번째(1 dpeth) 메뉴 항목의 폭(Width)은 일 정하게 하도록 한다. 

 

 

• (라) 내용 구성(Contents Area)을 정의한다. 

   

  • 필수적으로 적용하는 사항이며, 구성 요소로는 메인 이미지(Main Image), 시스템별 구성 콘텐츠가 있다. 시스템의 전체 콘셉트를 나타내는 메인 이미지와 시스템별로 필요한 콘텐츠를 적용하는 곳으로서 유동성 있게 구성이 가능하다. 

     

• (마) 하단 메뉴 구성(Footer Area)을 정의한다. 

   

  • 선택적으로 적용하는 사항이며, 구성 요소로는 회사 CI, Copyright가 있다. 회사 상 황에 맞춰 적용 및 삭제 가능하다. 

     

• (바) 사용 환경에 맞춰 페이지 폭을 정의한다. 

   

  • 브라우저 사이즈에 따라 페이지 폭 크기(Width Size)를 유동적으로 적용하여 화면 활용도를 높이는 것을 기본으로 한다.

 

 

• (3) 네비게이션을 정의한다. 

   

  • (가) 메뉴 네비게이션(Menu navigation)을 정의한다. 메뉴 네비게이션은 4가지 타입의 응용 프로그램(Application)의 메뉴 구조에 따라 적당한 타입을 선택하여 적용한다. 

     

    • 1) Type 1을 적용한다. Top, Left 구성을 기본 타입으로 한다. 

       

    • 2) Type 2를 적용한다. 메뉴 구조가 복잡할 경우 상단 메뉴 구성에 2dpeth를 Drop down으로 적용한다. 

       

    • 3) Type 3, 4를 적용한다. 프로그램 구성 특성상 화면의 폭(Width)을 넓게 쓰고 싶을 경우 좌측 메뉴에 대해서는 유동적 적용을 한다.

 

• (나) 모듈 뷰(Module View)를 정의한다. 효과적인 모듈의 분리를 위해 응집력(Cohesion)은 최대화하고 결합도(Coupling)는 최소화하여야 하며, 모듈 뷰 타입은 구현 단위 모듈 요소이며, 각 모듈은 기능적 책임을 할당한다.

   

  • 분할 스타일, 사용 스타일, 일반화 스타일, 레이어 스타일의 4가지 스타일을 포함하여 모듈 뷰 타입을 정의한다. 

     

  • 1) 분할 타입(Decomposition Type)을 확인한다. 

     

    • 분할 모듈 뷰 타입은 아키텍처에 대한 청사진을 그린 후 여러 사람들과 의사 소통에 많이 사용되는 방법이다. 

       

    • 변경되거나 추가되는 기능을 아키텍처의 특정 위치에 할당하여 변경이 가능 하도록 하여 품질속성의 변경을 허용하는 데 사용될 수 있다. 

       

    • 모듈을 작게 세분화한 서브 모듈로 쪼개는 기준은 사용하는 목적에 따라 달 라진다. 일정한 품질속성을 구현하기 위해 분할을 선택할 수 있다.

       

    • 데이터 숨김(Data-hiding) 원리를 이용하여 시스템에서 변경 가능한 부분을 별도의 특정 모듈로 캡슐화함으로써 변경된 기능의 영향을 최소하여 일정 부 분에서만 영향이 가도록 할 수 있다.  

       

    • 품질속성을 높이기 위해 분할을 원한다면 높은 성능을 필요로 하는 모듈을 상 대적으로 낮은 성능이 필요한 모듈에서 분리하여 각각 다른 전략을 적용한다. 

 

• 2) 사용 타입(Uses Type)을 확인한다. 

   

  • 사용 모듈 뷰 타입은 종속적인(depends on) 관계가 형성된 관계를 기반으로 한다. 사용 관계는 두 개의 모듈 사이의 관계에서 특정 모듈이 정확한 기능 을 발휘하기 위해서는 다른 하나의 모듈이 정확하게 구현되어 있어야 함을 전제로 한다. 

     

  • A 모듈과 B 모듈은 A가 B를 사용하는 관계이다. 사용 관계는 종속적인 관계 의 특이한 형태이며, 어떤 모듈 A의 정확한 정도가 모듈 B의 정확한 구현 여 부에 종속된다면 A모듈은 B모듈을 사용한다고 할 수 있다. 사용 관계에서 A 모듈이 B모듈의 호출을 항상 하지는 않는다. 

 

• 3) 일반화 타입(Generalization Type)을 확인한다.

   

  • 일반화 모듈 뷰 타입은 모듈이 일반적인 관계를 형성하는 경우 가변성 (Variation)과 공통성(Commonality)을 표현할 수 있다. 

     

  • 공통성을 가지는 부모 모듈(Parent Module)은 가변성을 이루는 자식 모듈 (Child Module)을 일반화한 것으로, 부모 모듈이 갖는 특성은 공통성을 포함하 15 며 자식 모듈은 가변성을 표현하게 된다. 일반화 관계를 사용하여 아키텍처 의 확장(Extension) 가능성과 진화(Evolution) 가능성을 이룰 수 있다. 

     

  • 자식 모듈의 추가나 변경 또는 삭제를 통하여 아키텍처를 확장할 수 있으며, 부모 모듈이 변경하면 모든 자식 모듈도 다 같이 변경되어 진화를 이룰 수 있게 한다

 

• 4) 레이어 타입(Layered Type)을 확인한다. 

   

  • 레이어 타입은 개발 팀에게 작업 할당의 기준을 제시한다. 레이어는 또한 분 석 도구로서 활용 가치가 있으며, 시스템의 변경이 필요한 경우 변경 영역을 결정하고 변경된 사항을 개발 팀에 넘겨 설계에 반영하게 한다. 

 

• (4) 기능을 정의한다. 

   

  • 시스템 요구사항에 대한 개념 모델을 논리적 모델(프로세스 모델, UI설계, 논리 데이터 모델, 아키텍처 정의, 인터페이스 설계 측면)로 상세화한다. 

     

  • (가) 프로세스 모델링(Process Modeling)을 정의한다. 신규 시스템으로 적용할 해당 업무 과정에서 일어나는 모든 활동들을 알기 쉽게 파악하고 정확한 영역 등의 파악을 위해 업무 기능 모델(Function Process Model)을 수립한다. 

 

• (나) 데이터 모델(Data Model)을 정의한다. 

   

  • 적용할 해당 업무 영역에 필요한 데이터 엔티티를 식별하고 정의하며, 이를 기반으 로 데이터 엔티티 및 엔티티 간의 관계를 논리적 데이터 모델로 정의한다. 

 

• (5) 구성 요소를 정의한다. 

   

  • (가) 그리드를 정의한다. UI를 구성하는 방법 중 테이블(Table) 형태로 구성한다.

 

• 1) Type A는 그리드 데이터 처리(Grid Data Fetch) 방식으로 기존에 조회된 데이 터에 새로 조회된 데이터가 추가되는(Append) 방식으로 한다. 

   

• 2) 한 번 처리(1 Fetch)에 대한 양은 업무(Business) 특성에 맞게 20, 30, 50, 100, 150건 등에서 적절한 값을 선택한다(한 번의 처리로 업무의 80% 정도를 수행 할 수 있는 양을 정한다). 

   

• 3) 스크롤 내림(Scroll Down) 시 마지막 조회 데이터가 화면에 표시(Display)될 시 다음 페이지를 자동 조회하여 추가(Append)한다. 

   

• 4) 데이터 디스플레이는 선택 항목이 없을 시에는 조회된 데이터가 추가(Append) 되면 해당 페이지의 첫 행(row)이 화면의 첫 부분에 보임(Display), 선택 항목 이 있을 시에는 현재 페이지가 보이고 데이터만 추가(Append)한다.

   

• 5) Type B는 대상 데이터 건수가 적은 화면에 사용한다. 데이터가 많아도 관리 업무나 해당 화면의 사용 빈도수가 적은 화면, 데이터의 총 건수가 중요한 화 면은 이 타입을 적용한다. 

   

• 6) 이 타입은 총 건수 처리에 대한 시스템 부하가 많으므로 가급적 사용하지 않는다.

 

• (나) 버튼을 정의한다. 기능 버튼, 검색 버튼, 그리드 관련 버튼, 기타 버튼 4가지로 구분해 제작한다. 

   

  • 1) 기능 버튼을 정의한다. 조회, 저장과 같이 화면마다 공통으로 사용되면서 화면 전체에 영향을 미치는 버튼으로, 화면 상단에 위치한다. 좌측에 아이콘 이미지가, 우측에 버튼 명이 위치하도록 한다. 

     

  • 2) 검색 버튼을 정의한다. 검색 영역 안에 위치하는 버튼으로 색(Color)과 스타일(Style)은 애플리케이션별 로 자유롭게 디자인하도록 한다. 

     

  • 3) 그리드(Grid) 관련 버튼을 정의한다. 그리드의 데이터를 처리(Handling)하는 버튼이다

 

 

• 4) 기타 버튼을 정의한다. 

   

  • 업무 관련 버튼, 그리드 버튼을 제외한 모든 버튼을 말하며 도움말 버튼을 제외 하고는 모두가 한 화면의 특정 영역 내에서만 사용된다

 

• 2. UI 패턴 모델을 정의한다. 

   

  • CRUD 방식을 기반으로 하여 데이터의 입력과 출력을 처리하는 화면 플로우(Flow)를 포함 하여 오퍼레이션 방식에 대한 표준 절차를 표시하고, UI 패턴 모델(Pattern Model)을 개발 표준 프레임워크(Framework)로 개발하고, 유스케이스(Use Case)를 이용해 패턴별 표준 개 발 방법 총 7가지 영역을 정의한다. 

     

  • (1) 업무 화면 클라이언트(Client)를 정의한다. 어느 형태의 클라이언트를 사용할 것인가는 제안 단계에서 결정된다. 설계자(Architect) 는 결정된 클라이언트를 가지고 개발 시에 필요한 공통 요소 식별, 디렉토리 구성, 개 발 환경 구축에 관여해야 한다. 클라이언트에 출력되는 UI는 X-Internet으로 대변되는 리치 클라이언트(Rich Client) 도구와 일반 JSP, Html 기반의 신 클라이언트(Thin Client) 방식이 대표적으로 사용된다

 

 

• (2) 서버 컨트롤러(Controller)를 정의한다. 

   

  • 프레임워크를 도입한다면 해당 프레임워크가 제공하는 방식을 채택한다. 두 가지 방식 을 다 지원하면 기준을 정하여 상황에 맞게 적용한다. 또한 별도의 클라이언트 제품을 도입하는 경우 서버 컨트롤러와의 연동 방식을 결정한다. 

     

• (3) 서버 메시지 및 예외(Exception) 처리를 정의한다. 

   

  • 서버의 메시지 및 예외 처리를 클라이언트 UI에 전달하는 방식을 결정한다.

 

• (4) 클라이언트(Client) – 서버 간 데이터 변환을 정의한다. 

   

  • 어떤 방식의 오브젝트(Object)를 사용할 것인지를 먼저 결정하고, 이에 따라 클라이언 트와 서버 간의 데이터 형태 변환을 어떻게 처리할 것인지 방안을 마련한다.

     

  • 유형(Type) 1은 별도의 명백한(Plain) 자바 빈(Java Bean. Domain Object)을 DTO로 구현하여 Request 객체 내에 있는 해당 데이터를 Plain VO로 전환하는 방식이다. 예를 22 들면, 고객(Customer), 주문(Order), 상품(Product) 등을 표현하는 클래스들을 일일이 개발하여 활용한다. 유형(Type) 2는 별도의 구현 없이 자바 맵(Java Map) 기반의 공통 데이터 클래스를 활 용하는 방식이다. 

 

• (5) EP 연계를 정의한다. EP - SSO - Client 간 연계 방안을 URL 연계 시와 포틀릿(Portlet) 연계 시를 고려하여 마련한다. 

   

• (6) 보고서를 정의한다. 클라이언트와 리포트(Report) 솔루션 간의 연계 방식을 결정한다. 

   

• (7) 신 클라이언트(Thin Client)에 외부 컴포넌트 연계를 정의한다. 외부 UI 컴포넌트를 도입할 시 서버와의 연계 방식을 결정한다. 

 

• 3. UI표준 수립을 위한 조직을 구성한다. 

   

  • (1) 조직 구성 및 역할을 정의한다. 효과적인 프로젝트 추진을 위하여 UI 팀 및 표준 개발 팀을 주축으로 한 추진 조직 구성을 확정한다.

 

• (2) 커뮤니케이션 방안을 수립한다. 

   

  • 프로젝트가 원활히 수행되도록 정식 보고 및 정기적인 회의뿐 아니라 이슈 회의 등 다양한 방식의 커뮤니케이션을 수행한다.

 

• 4. UI표준을 위한 환경을 분석한다. 

   

  • (1) 사용자 트렌드를 분석한다. 

     

    • (가) 기존 UI와 현재 UI 트렌드를 숙지한다. 

       

    • (나) 현재 UI의 단점을 상세히 나열한다. 

       

    • (다) 사용자가 필요로 하는 핵심 요구사항을 파악한다. 

       

    • (라) 사용자가 쉽게 이해 가능한 기능을 위주로 기술 영역을 정의한다. 

       

  • (2) 기능 및 설계를 분석한다. 

     

    • (가) 기능 조작성에 대해 분석한다. 

       

      • 1) 사용자 편의를 위한 조작에 대해 확인한다. 

         

      • 2) 스크롤바는 지원 가능한지 확인한다. 

         

      • 3) 마우스 조작 및 업무 처리 시 동선에 대해 확인한다. 

         

    • (나) 오류 방지에 대해 분석한다. 

       

      • 1) 사용자 조작 시 오류에 대해 예상 가능한지 확인한다. 

         

      • 2) 사용자 의도와 관계 없는 페이지 이동이 있는지 확인한다. 

         

      • 3) 기능 버튼은 사용자가 명확한 구분이 가능한지 확인한다. 

         

      • 4) 기능 버튼 명이 사용자 조작과 일치하는지 확인한다.

    • (다) 최소한의 조작으로 업무 처리 가능한 형태를 확인한다. 

       

      • 1) 작업 흐름에 가장 적합한 레이아웃을 확인한다.

         

      • 2) 기능 특성에 맞는 UI를 확인한다. 

         

      • 3) 조작 단계를 최소화하고 동선은 단순한지 확인한다. 

         

    • (라) UI의 정보 전달력을 확인한다. 

       

      • 1) 중요 정보에 대해 사용자가 인지하기 쉽도록 전달 가능한지 확인한다. 

         

      • 2) 정보 제공 방식이 일관적이며 사용자가 쉽게 이해 가능한지 확인한다. 

         

      • 3) 상호 연관성이 높은 정보가 쉽게 인지 가능한지 확인한다. 

         

      • 4) 오류 발생 시 조치를 위한 접근이 쉬운지 확인한다. 

         

      • 5) 사용자 정보 제공이 간결하고 명확한지 확인한다. 

 

[2] 개발하고자 하는 응용 소프트웨어에 적용될 UI 요구사항을 확인한다.

• 다음은 정보통신산업진흥원 부설 SW공학센터의 “소프트웨어 개발 UI/UX 참조모델 가이드”를 적용한 처리 절차이다.

   

• 1. 비즈니스 요구사항을 확인한다. 

   

  • (1) 목표를 정의한다. 

     

    • (가) 사용자를 대상으로 심층 인터뷰를 통해 의견을 수렴하여 비즈니스 요구사항을 정의한다. 

       

    • (나) 인터뷰를 통해 사업적, 기술적인 요소를 깊게 이해하여 목표를 명확히 한다. 

       

    • (다) 사업적, 기술적 목표가 확정되면 UI/UX 디자인 프로세스를 정의한다. 

       

    • (라) 인터뷰 시 주의할 사항은 사용자 리서치 시작 전에 선행되어야 한다는 점이다 (인터뷰 후 취득한 결과를 바탕으로 보다 효율적인 리서치를 준비할 수 있다). 

  • (2) 활동 사항을 정의한다. 

     

    • (가) 초기 비전과 기대 : 사용자, 고객, 회사의 비전을 일치시키는 작업을 진행한다. 

       

    • (나) 비용과 일정 확인 : UX 리서치와 UI/GUI 디자인에 필요한 예산과 일정을 결정한 다(리서치의 규모, 디자인 목표 등이 결정된다). 

       

    • (다) 기술적 제약과 가능성 : 현재 기술의 발전 가능성 파악, UI/UX 디자인 미래와 나아갈 방향을 제시한다. 

       

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

       

    • (마) 경영진의 프로젝트의 이해도 : 인터뷰한 내용을 기반으로 경영진 내의 서로 다 른 UI/UX 개발 프로젝트의 이해를 돕고 협의하도록 한다.

       

  • (3) 인터뷰를 진행한다.

     

    • (가) 인터뷰는 가능하면 한꺼번에 여러 명을 하지 않고 개별 진행한다. 

       

    • (나) 다수의 목소리에 집중하여 개인의 중요한 목소리를 놓칠 위험을 염두해야 한다. 

       

    • (다) 각 인터뷰는 한 시간을 넘어서는 안 된다. 

 

• 2. 요구사항을 작성한다. 

   

  • 여러 경로를 통해 수집, 작성된 요구사항을 검토하고, 목적을 기준으로 데이터 요구, 기능 요구, 제품 품질속성, 제약사항으로 요구사항을 작성한다. 다음과 같이 UI 요구사항들을 바탕으로 UI의 전체적인 구조를 파악 및 검토하고, 내부에 구성될 여러 가지 요소들의 종 류와 각각의 표현 방식 등을 검토한다. 

     

  • (1) 요구사항 요소를 확인한다. 

     

    • (가) 데이터 요구 : 사용자가 요구하는 모델과 객체들의 주요한 특성에 기반한 데이 터 객체들을 정리한다. 인터페이스에 영향을 주므로 초기에 확인해야 한다. ex) 이메일의 메시지 속성에는 제목, 발신일, 발신인, 참조인, 답변 

       

    • (나) 기능 요구 : 사용자의 목적 달성을 위해 무엇을 실행해야 하는지를 동사형으로 설명한다. 기능 요구 리스트로 정리하며, 최대한 철저하게 해야 한다. ex) 페르소나(Persona)는 이메일의 메시지 내용을 읽거나 삭제하며, 일정한 양 식으로 다른 메시지와 함께 보관한다. 

       

    • (다) 제품, 서비스의 품질 : 데이터 및 기능 요구 외에 중요하게 고려할 몇 개의 속 성은 제품 품질이 있으며, 여기에는 감성적인 품질도 고려한다. ex) 시스템이 얼마나 빨리 파일을 처리하는지 여부와 같이 실용적이며 정량화 가능한 요구사항들을 확인한다. 

       

    • (라) 제약사항 : 제품 출시의 데드라인, 개발 및 제작에 드는 비용, 시스템 준수에 필요한 규제가 포함되며, 사전에 제약사항의 변경 여부(변경 가능, 변경 불가)를 확인한다. 

  • (2) 정황 시나리오를 작성한다. 

     

    • (가) 요구사항 정의의 가장 기초적인 시나리오를 뜻하는 것으로, 높은 수준과 낙관 적인 상황에서의 이상적인 시스템 작동에 초점을 맞춘다. 개발하는 서비스의 모습을 상상하는 단계이며, 사용자 관점에서 시나리오를 작성한다. 

       

    • (나) 사용자가 주로 사용하는 기능 위주로 작성하여야 하며, 같이 동작하는 기능들 은 하나의 시나리오에 통합한다. 

       

    • (다) 정리된 리스트를 기반으로 사용자의 관점에서 서술한다. 육하원칙에 따르고 간 결하고 명확하게 작성하여 정확하게 전달한다. 

       

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

 

[프로토타입 제작, 검토]

[1] UI 프로토타입 이해

• 1. 프로토타입(Prototype)의 뜻 

   

  • 프로토타입은 원래의 온전한 형태, 전형적인 예, 기초적인 표준이다. 시제품 전의 제품 원 형으로 개발 검증과 양산 검증의 과정을 거쳐 시제품이 완성된다. 프로토타입은 “새로운 컴퓨터 시스템이나 소프트웨어의 설계 또는 성능, 구현 가능성, 운 용 가능성을 평가하거나 요구 사항을 좀 더 잘 이해하고 결정하기 위하여 전체적인 기능 을 간략한 형태로 구현한 시제품”(한국어사전)이다. 프로토타입은 사용자의 요구사항이 모두 정확하게 반영될 때까지 계속하여 개선, 보완된다. 실제 수많은 애플리케이션들이 프 로토타입의 지속적인 확장, 보강을 통해 최종 설계가 완성된다.

     

• 2. 어원에 따른 접근 

   

  • “프로토타입(prototype)의 사전적 의미는 대량 생산에 앞서 미리 제작해보는 원형 또는 시제품으로, 제작물의 모형이라 할 수 있다. 소프트웨어 개발에서는 정식 절차에 따라 완 전한 소프트웨어를 만들기 전에 사용자의 요구를 받아 일단 모형을 만들고 이 모형을 사 용자와 의사소통하는 도구로 활용한다. ”(김치수, 2015). 이는 원초적이라는 뜻의 ‘프로 토타이포스’의 중간 음에서 온 것으로, 더 들어가면 “최초의”라는 뜻의 ‘프로토스’ 와 “인상”이라는 뜻의 ‘타이포스’에서 비롯된 것이다. UI에 있어 프로토타이핑이란 추후 구현될 시스템의 골격으로서, 사전에 시스템의 일부분 또는 시스템의 기초 모형이 될 것을 수행하는 과정이다.

• 3. 프로토타입의 의의 

   

  • 프로토타이핑은 설계의 결과물이 아닌 과정으로 요구사항을 반영하고, 1차 검토 후 수정 하고, 2차 요구사항을 반영하여 최종적인 시제품을 완성하기 위해 반복적으로 수행되어야 하는 단계이다. 사전에 프로토타입을 먼저 제작하고 이를 바탕으로 향후 설계될 UI의 적 정성을 평가해 수정 보완함으로써 추후 발생 가능한 오류들을 사전에 방지하여 시스템 설 계 및 개발에 소요되는 총 비용 및 노력을 절감할 수 있다. 

     

• 4. 프로토타입의 활용 

   

  • 소프트웨어 개발에 있어 프로토타입은 설명에 대한 시간을 줄여 주며, 특히 고객과 개발 스펙을 논의 시 설득과 이해를 돕기 위해 UI 프로토타입을 만든다. 또한 추가적으로 기술 적인 검증을 위해서 프로토타입을 만드는 경우도 있다. 개발 스펙을 작성하다 보면 구현 이 가능한지 불가능한지를 미리 예측할 필요가 생기는데 이때 먼저 제작해서 사전 검증을 하는 것이다. 프로토타입 작성 후 확실하지 않으면 수정 보완 후 다시 검증한다. 이렇게 함으로써 실제 개발에 들어가기 전 최대한의 오류를 줄일 수 있다. 프로토타입은 검증을 위한 것이므로 최대한 간단하게 만든다. 

 

[2] UI 프로토타입 상세

• 1. UI 프로토타입 전략 

   

  • 확정된 요구사항을 기반으로 UI전략을 실체화하는 과정이며, UI 디자인 작성 이전에 미리 화 면을 설계하는 단계이다. 아날로그적인 방법으로 스케치, 그림, 글 등을 손으로 직접 작성하 는 페이퍼 프로토타입(Paper Prototype)과 컴퓨터 등 도구를 사용하여 작성하는 디지털 프로 토타입(Digital Prototype)이 있다. 환경 및 상황에 따라 적절하게 선택하여 사용하면 된다.

• 2. UI 프로토타입의 장점과 단점 

   

  • (1) 장점 

     

    • (가) 사용자 설득과 이해가 쉽다. 

       

    • (나) 개발 시간이 감소한다. 

       

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

       

  • (2) 단점 

     

    • (가) 너무 많은 수정 과정을 거친다면 오히려 작업 시간이 늘어날 수 있다. 사용자 의 요구사항은 가능한 들어주되 적절한 타협이 필요하다. 

       

    • (나) 자원 효율성 관점에서 보면 필요 이상으로 자원을 많이 소모한다. 

       

    • (다) 정확한 문서 작업이 생략될 수 있다. 

 

[3] UI 프로토타입 작성 도구 및 방법

 

[4] UI 프로토타입 작성 시 고려할 사항

• 1. 프로토타입 계획 작성 

   

  • 프로젝트의 상황에 따라 다르지만 일반적으로 프로토타입 작성은 계획을 수립하는 과정과 실행 후 결과를 보고하는 프로세스로 진행된다. 프로토타입 계획을 세울 때 고려할 부분 과 결과서를 작성할 때 고려할 부분을 고려하여야 한다. 

     

• 2. 프로토타입 범위 확인 

   

  • 프로토타입의 범위는 프로젝트의 범위나 리스크 상황 등의 주변 여건을 감안해서 정해야 한다. 우선 목적을 명확히 하고 그 목적을 수행할 수 있는 환경이 마련되었는지 확인해야 한다. 특히 프로토타입 팀을 별도로 구성할 수 있는지 반드시 확인해야 한다.

     

• 3. 프로토타입 목표 확인 

   

  • 프로토타입을 통해서 얻고자 하는 목표를 미리 명확하게 준비해야 한다. 기능과 관련된 것인지, 성능과 관련된 것인지, 개발 환경에 관련된 것인지에 대한 부분을 고객과 협의하 여 명확하게 준비하고 진행해야 한다. 

• 4. 프로토타입 기간 및 비용 확인 

   

  • 가급적 프로토타입에 투입되는 기간 및 비용은 최소화하여 목적을 달성할 수 있도록 계획 하는 것이 좋다. 검증할 범위를 너무 넓게 잡거나 기간을 많이 잡으면 고객이 원하는 목 표가 너무 커져서 오히려 문제가 될 수도 있으므로 주의해야 한다. 

     

• 5. 프로토타입 산출물 확인 

   

  • 프로토타입에서 나오는 산출물은 실제 개발에 그대로 참조될 수 있는 수준이 되어야 한 다. 하지만 프로토타입을 통해 개발된 UI를 실제 개발 범위에 넣는 것은 좋은 방법이 아 니다. 실제 기능 요구사항을 가지고 개발되었다 하더라도 아키텍처 요소 검증을 위한 것 이므로 실제 개발에서는 참조만 하는 수준으로 활용해야 한다. 

     

• 6. 프로토타입 유의 사항 확인 

   

  • 프로토타입은 작은 범위와 적은 인원을 가지고 최소 기간 내에 위험 요소를 식별하고 해 결하는 것이 중요하다. 가급적 프로토타입에 투입되는 기간 및 비용을 최소화하여 목적을 달성할 수 있도록 계획하는 것이 좋다. 검증할 범위를 너무 넓게 잡거나 기간을 많이 잡 으면 원하는 목표가 너무 커져서 오히려 문제가 될 수도 있으므로 주의해야 한다. 

 

[5] UI 프로토타입 계획 시 고려할 사항

• 프로젝트의 상황에 따라 다르지만 일반적으로 프로토타입은 계획을 수립하고 실행한 후에 그 결과를 보고하는 프로세스로 진행된다. 다음과 같이 프로토타입 계획을 세울 때 고려 할 부분과 권고 사항을 확인한다. 

   

  • 1. 프로토타입 목표 확인

     

  • 2. 프로토타입 환경 확인

     

  • 3. 프로토타입 일정 확인

     

  • 4. 프로토타입 범위 확인

     

  • 5. 프로토타입 인원 확인

     

  • 6. 프로토타입 아키텍처 검증 확인

     

  • 7. 프로토타입 이슈 및 해결

     

  • 8. 프로토타입 가이드 확정

     

  • 9. 프로토타입 개발 생산성 확인

     

  • 10. 프로토타입 결과 시연

 

[수행]

[1] 응용 소프트웨어 개발을 위한 UI 표준 및 지침에 의거하여, 소프트웨어 아키텍처의 설계 원리를 확인한다.

• 1. 구축할 시스템의 인터페이스 설계 시 소프트웨어 아키텍처의 설계 원리가 어떻게 사용 될 수 있는지 확인한다. 여기에서는 도서대출 예약시스템을 예시로 삼는다. 

   

  • (1) UI 흐름을 확인한다. 

  • (2) 사용자의 행동 흐름을 확인한다

 

• 2. 개발 요청자가 가장 이해하기 편한 방법이 무엇인지 확인한다.

 

[2] UI 설계 원리를 바탕으로 프로토타입 유스케이스(USE CASE)를 작성한다.

• 1. 유스케이스를 작성한다. 

   

  • (1) 유스케이스의 개요를 작성한다. 

     

  • (2) 액터를 정의한다. 

     

  • (3) 이벤트 흐름을 작성한다. 

     

    • (가) 기본 사항을 작성한다. 

       

    • (나) 추가 사항을 작성한다.

       

  • (4) 처리 내용을 작성한다. 

     

  • (5) 도서 대출 예약 시스템의 도서 대출 유스케이스 사례와 같이 작성한다.

     

  • (6) 도서 대출 예약 시스템의 도서 반납 유스케이스 사례와 같이 작성한다.

 

 

[3] UI 요구사항을 반영한 프로토타입을 제작한다.

• 1. 실질적인 제작에 앞서 UI 프로토타입 제작 단계를 숙지한다.

   

  • (1) 1단계 사용자 요구사항을 분석하는 단계이다. 작업 담당자는 기본적인 요구사항이 도출되어 확정되기 전까지 사용자 관점에서 사용자처럼 수행한다. 

     

  • (2) 2단계 작업 담당자가 위의 1단계에서 도출된 요구사항을 충족하는 프로토타입을 종이 등에 손으로 직접 그리거나 프로그래밍 언어나 편집 도구 등의 디지털 방식을 이용하여 개 발한다. 프로토타입은 개발이 필요한 시스템의 핵심적인 기능을 중심으로 개발한다. 

     

  • (3) 3단계 작성 또는 개발된 프로토타입을 사용자가 실제적으로 사용하여 요구사항이 잘 수행되 고 있는가를 확인하는 과정이다. 프로토타입의 추가 사항이나 보완을 위해 다양한 제안 과정이 있는 단계이다. 

     

  • (4) 4단계 프로토타입의 결과를 토대로 수정과 합의가 이루어지는 단계이다. 작업 담당자는 사용 자가 요청한 다양한 제안 사항을 포함하고 수용하여 보완 작업을 한다. 프로토타입 결 과물이 완성된 후에는 3단계로 다시 되돌아간다. 사용자의 최종 승인 완료까지 3단계 와 4단계는 반복된다.

 

• 2. 프로토타이핑(Prototyping)을 초기 작성한다. 

   

  • (1) 페이퍼 프로토타이핑을 초기 작성한다. 종이와 펜을 활용해 화면의 구조를 스케치하는 방법으로 가장 쉽게 만들 수 있는 형 태이다. [그림 1-22]와 같이 UI 페이퍼 프로토타이핑을 초기 작성한다.

 

• (2) 디지털 프로토타이핑을 초기 작성한다. 

   

  • 디지털 편집기(자신이 가장 잘 사용하는 편집 프로그램), HTML 등의 프로토타이핑 도 구를 사용해 화면의 구조를 만들어 내는 방법으로 가장 폭넓게 사용된다. 

     

  • (가) 디지털 편집기 기반 프로토타이핑을 초기 작성한다. [그림 1-23]과 같이 화면의 구조를 디지털 편집 도구를 활용해 프로토타이핑을 초기 작성한다. 

 

• (나) HTML 기반 디지털 프로토타이핑을 초기 작성한다. 

   

  • HTML을 이용한 프로토타이핑은 기본적으로 HTML, CSS, JavaScript 등과 같은 프 로그래밍 언어들을 이해하고 활용한다. HTML을 이용한 프로토타이핑의 경우 다음 의 절차를 통해 진행한다. 

     

  • 1) 프로토타이핑 대상이 되는 화면의 구조와 구성 요소들을 파악한다. 

     

  • 2) HTML의 다양한 태그들을 통해 화면의 레이아웃을 구상한다. 

     

  • 3) 적절한 HTML 화면 구성 요소들을 이용해 각 UI 표현 요소들을 표현한다.

 

• 3. 프로토타이핑을 상세 수행한다. 

   

  • (1) 페이퍼 프로토타이핑을 상세 수행한다. 

     

    • (가) 앞서 초기 작성한 페이퍼 프로토타입을 바탕으로 UI 페이퍼 프로토타이핑을 상세 수행한다. 

       

      • 1) UI 요구사항을 바탕으로 각 화면 구조를 구상한다.

         

        • 어떤 형태의 배치를 통해 각 기능을 표현할 것인지 각 화면별로 구상한다. 

           

      • 2) 화면에 표현되는 각 요소들을 설계한다.

         

        • 각 입력 요소들의 형태와 입력 방법에 대해서 구상한다.

           

        • 각 화면 요소들의 배치에 대해서 구상한다.

           

        • 각 요소들을 설계한다.

 

• (2) 디지털 프로토타이핑을 상세 수행한다. 

   

  • (가) 앞서 초기 작성한 디지털 프로토타입을 바탕으로 파워포인트 기반 디지털 프로 토타이핑을 상세 수행한다. 구체적인 방법은 앞의 “(1) 페이퍼 프로토타이핑”의 경우와 같다.

 

• (나) 앞서 초기 작성한 디지털 프로토타입을 바탕으로 HTML 기반 디지털 프로토타이핑을 수행한다. 구체적인 방법은 앞의 “(1) 페이퍼 프로토타이핑”의 경우와 같다

 

• 2. 평가 차를 줄이기 위한 UI 적정성을 확인한다. 

   

  • (1) 수행한 키 조작의 결과를 사용자가 빠르게 지각 가능한지 확인한다. 

     

  • (2) 키 조작으로 변화된 시스템의 상태를 사용자가 쉽게 인지 가능한지 확인한다.

     

  • (3) 사용자가 가진 원래 의도와 시스템 결과 간의 유사 정도를 사용자가 쉽게 파악 가 능한지 확인한다.

 

[연습문제]

• 품질 요구사항 특성이 아닌 것은?

   

  • 기능성

     

  • 신뢰성

     

  • 효율성

     

  • 기밀성

 

• UI 요구사항 중 기능적 요구사항이 아닌 것은? 

   

  • 시스템의 입력으로 무엇이 포함되어야 하나? 

     

  • 시스템의 출력으로 무엇이 포함되어야 하나? 

     

  • 시스템이 어떤 데이터를 저장해야 하나? 

     

  • 사용성, 효율성, 신뢰성, 유지 보수성, 재사용성 등 품질에 관한 요구사항

 

 참고 문헌

[논문]

• 없음

[보고서]

• 없음

[URL]

• 없음

 

 문의사항

[기상학/프로그래밍 언어]

• sangho.lee.1990@gmail.com

[해양학/천문학/빅데이터]

• saimang0804@gmail.com

 

 

 

 

 

 

 

 

 

 

 

본 블로그는 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음