[자격증] 정보처리기사 실기 : 17강 화면 설계 (UI 설계하기)

 정보

• 업무명     : 정보처리기사 실기 : 17강 화면 설계 (UI 설계하기)

• 작성자     : 이상호

• 작성일     : 2020-05-10

• 설   명      :

• 수정이력 :

 

 

 내용

[UI 흐름 설계]

[1] UI 설계서 구성에 따른 작성 방법

• UI 설계서 구성은 UI 설계서 표지, UI 설계서 개정 이력, UI 요구사항 정의, 시스템 구조, 사이트 맵, 프로세스 정의, 화면 설계 등으로 이루어진다. 

   

• 1. UI 설계서 표지 

   

  • UI 설계서에 포함될 프로젝트 명 또는 시스템 명을 포함시킨다. 

     

• 2. UI 설계서 개정 이력 

   

  • UI 설계서 처음 작성 시에는 첫 번째 항목으로 ‘초안 작성’을 포함시키고 그에 해당 되는 초기 버전(version)을 1.0으로 설정한다. 변경 또는 보완이 충분히 이루어져 완성 이 되었다고 판단할 경우 버전을 x.0 으로 바꾸어 설정한다. 

     

• 3. UI 요구사항 정의 

   

  • UI 요구사항들을 재확인하고 정리한다. 

     

• 4. 시스템 구조 

   

  • UI 프로토타입을 재확인한다. 

     

  • UI 요구사항들과 UI 프로토타입에 기초해 UI 시스템 구조를 설계한다.

• 5. 사이트 맵(Site Map) 

   

  • UI 시스템 구조의 내용을 사이트 맵의 형태로 작성한다. 

     

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

     

• 6. 프로세스(Process) 정의 

   

  • 사용자 관점에서 요구되는 프로세스들을 진행되는 순서에 맞추어 정리한다.

     

• 7. 화면 설계 

   

  • UI 프로토타입과 UI 프로세서 정의를 참고해 각 페이지 별로 필요한 화면을 설계한다. 

     

  • 각 화면 별로 구분되도록 각 화면 별 고유 ID를 부여하고 별도의 표지 페이지를 작성한다. 

     

  • 각 화면 별로 필요한 화면 내용을 설계한다. 

 

[2] UI 화면 설계의 기본 구성 요소

• 1. 윈도우(Window)

• 2. 메뉴(Menu)

• 3. 아이콘(Icon)

• 4. 포인터(Pointer)

 

[3] 유용성 개념 및 적용 원리 파악

• 1. 유용성 개념

   

  • (1) 유용성

     

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

       

  • (2) 유용한 시스템을 설계할 때 고려사항 

     

    • 사용자가 시스템의 구조, 기능, 가치 등에 대해 가지고 있는 마음 속 모형인 사용자 모형과 시스템 설계자가 만들려고 하는 개발자 모형 사이의 차이를 최소화하려는 노력이 필요하다. 

       

  • (3) 사용자 모형과 개발자 모형 간의 차이 발생 

     

    • 시스템에서의 실행 차, 즉 실행 가능한 기능과 사용자의 원래 목적이 서로 상이하기 때문에 발생한다.

       

    • 평가 차, 즉 시스템의 실행 결과와 사용자의 원래 목적이 서로 상이하기 때문에 발생한다. 

 

• 2. 실행 차를 줄이기 위한 UI 설계 원리 

   

  • (1) 사용 의도 파악 

     

    • 사용자의 원래 목적을 명확히 파악하여 불필요한 부가 기능 때문에 시스템 성능이 떨어지지 않도록 해야 한다. - 사용자가 보다 관심을 가지는 항목을 눈에 띄는 위치에 배치하고 적절한 시점에 해 당 기능이 제공되도록 하여야 한다. 

       

  • (2) 행위 순서 규정 

     

    • 사용자 행위의 순서를 세분화시킨 뒤 순서대로 명확하게 제시하여 선택할 수 있도록 해야 하고 또한 의도에 따라 행위의 순서를 사용자가 임의로 변경 가능하도록 해야 한다. 

    • 하나의 작업을 수행하기 위한 단계 수를 최소화시키고, 동일한 결과를 여러 가지 다 른 방법으로도 달성 가능하도록 설계 시 고려해야 하며, 행위의 순서가 사용자의 기 존 경험에 비추어 가능한 한 친숙하도록 설계해야 한다. 

  • (3) 행위의 순서대로 실행 

     

    • 프로세스의 흐름을 UI를 통해 직관적으로 알 수 있게 제공함으로써 사용자가 의도한 행위의 순서를 실제 실행으로 옮기는 데 어려움을 최소화해야 한다. 

       

    • 과도한 상호 작용으로 인해 작업이 원활히 진행되지 못하는 상황이 발생되지 않도록 고려해야 한다. 

       

    • 사용자가 의도한 행위와 가장 잘 어울리는 입력 장치를 선택하고, 사용자의 행위에 대해 적절한 피드백과 취소 기능을 제공해 주며, 디폴트 값을 적절하게 설정함으로 써 불필요한 조작을 최소화하여 사용자가 의도한 행위를 효율적으로 실행할 수 있도록 설계해야 한다. 

 

• 3. 평가 차를 줄이기 위한 UI 설계 원리 

   

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

     

    • 사용자가 수행한 행위에 대해 아무런 변화된 결과가 제공되지 않는다면 사용자는 자신이 제대로 조작하였는지 의심하게 되므로, 이러한 평가 차가 발생하지 않도록 설계해야 한다. 

       

    • 가능한 한 빠른 처리를 통해 즉각적으로 반응되도록 해야 하며, 즉각적인 반응이 힘 들더라도 가능한 한 반응 속도를 높이도록 노력해야 한다. 또한 사용자가 수행한 행 위로 인해 현재 시스템의 변화가 이루어졌음을 가능한 한 직관적으로 피드백 해주어야 한다.

       

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

     

    • 사용자가 수행한 행위로 인해 변화된 시스템의 상태를 사용자가 직관적으로 인지할 수 있도록 시스템을 설계해야 한다. 이를 위해 시스템의 상태 정보를 가능한 한 단순 하게, 그리고 이해하기 쉽게 제시해야 한다. 

       

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

     

    • 사용자가 가진 원래 의도가 시스템을 통해 충족되었는지 또는 충족될 수 있는지를 사 용자가 쉽게 파악할 수 있도록 설계해야 한다. 이를 위해 미리보기 기능처럼 예상 결 과를 사전에 제시할 수 있다면 제공해 주는 것이 대부분의 경우 바람직하다. 

 

[4] 스토리보드 작성 기법

• 스토리보드는 디자이너와 개발자가 최종적으로 참고하는 산출 문서이며, 정책이나 프로세스 및 콘텐츠의 구성, 와이어프레임(UI, UX), 기능에 대한 정의, 데이터베이스의 연동 등 구축하는 서비스를 위한 대부분의 정보가 수록되어 있는 문서이다. 

   

• 1. 메뉴 구성도 만들기(스토리보드 1단계) 

   

  • 전체적인 메뉴 구성도이며, 어떤 것을 보여주고 결정된 사항을 표현하기 위한 메뉴의 순서와 구성 단계, 용어를 정의한다. 

     

• 2. 스타일 확정(스토리보드 2단계) 

   

  • 레이아웃이나 글자 모양, 크기, 색상, 그래픽에서의 일관성을 유지해야 한다. 

     

• 3. 설계하기(스토리보드 3단계) 

   

  • 화면에 보여지는 시각적인 디자인 콘셉트를 잡는다

 

[UI 상세 설계]

[1] UI 시나리오 작성 원칙

• UI 상세설계에 있어 시나리오 작성은 반드시 필요한 사항이다. 정보통신산업진흥원 부설 SW공학센터의 “소프트웨어 개발 UI/UX 참조모델 가이드“(2014)에 따르면 시나리오 작성의 원칙은 다음과 같이 설명한다. 

   

• 1. UI의 전체적인 기능과 작동 방식을 개발자가 한 눈에 쉽게 이해 가능하도록 구체적으로 작성하여야 한다. 

   

• 2. 모든 기능은 공통 적용이 가능한 UI 요소와 인터랙션을 일반적인 규칙으로 정의한다. 

   

• 3. “대표 화면의 레이아웃과 그 화면들 속의 기능”을 정의한다. 이때의 대표 화면은 시나리오에 포함되는 서로 다른 형태를 가진 독립적인 화면들을 가리 킨다. 

• 4. 인터랙션의 흐름을 정의하며, 화면 내와 화면 간 인터랙션의 순서(Sequence), 분기 (Branch), 조건(Condition), 루프(Loop) 등을 명시한다. 이때의 인터랙션은 페이퍼 프로토타입에서 발견된 문제점을 모두 개선하여 적용한 최종 인터랙션이어야 한다.

   

• 5. 예외 상황에 대비한 케이스를 정의한다. 대부분의 소프트웨어 개발자와 품질 관리자 들이 UI 시나리오 문서에서 가장 많은 불만을 드러내는 부분이 예외 케이스의 정리가 부실하다는 것이다. 

   

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

   

• 7. UI 시나리오 규칙을 지정한다.

 

프로토타입 제작 구분

• 주요 키의 위치와 기능 

   

  • 화면상에 공통적으로 배치되는 주요 키의 위치와 기능을 설명한 것 으로 여러 화면 간의 일관성을 보장하기 위한 것이다. 

     

• 공통 UI 요소 

   

  • 체크 박스, 라디오 버튼, 스크롤 바, 텍스트 입력 필드, 상하/좌우 휠, 모드 설정, 탭, 팝업 등의 각 UI 요소를 언제 사용하며 어떤 형태인 지 정의하고 사용자의 조작에 어떻게 반응하는지 그 흐름을 상세하게 설명한 것이다. 

     

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

   

  • 여러 화면 내에 공통적으로 나타나는 Indicators, Titles, Ok/Back, Soft Key, Option, Functional Buttons 등의 위치와 속성을 정의한 것으로서 여러 기능들 간에 화면 레이아웃의 일관성을 보장하기 위한 것이다. 

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

   

  • 터치 제스처 등의 공통적으로 사용되는 조작의 방법, 홈 키의 동작 방식과 같은 운항 규칙, 실행, 이전, 다음, 삭제, 이동 등의 화면 전 환 효과 등에 대해 기술한 것이다. 

     

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

   

  • 많은 기능들에 공통적으로 자주 나타나는 삭제, 검색, 매너 모드 상 태에서의 소리 재생 등의 인터랙션 흐름을 설명한 것이다. 

     

• 케이스 문서

   

  • 다양한 상황에서의 공통적인 시스템 동작에 대해 정의한 문서이다. (ex. 사운드, 조명, 이벤트 케이스 등) 

     

• 출처 : 정보통신산업진흥원 부설 SW공학센터. 소프트웨어 개발 UI/UX 참조

 

[2] UI 시나리오 문서 작성의 요건

• 정보통신산업진흥원 부설 SW공학센터의 “소프트웨어 개발 UI/UX 참조모델 가이드 “(2014)에 따르면 시나리오 작성의 요건은 다음과 같이 설명한다. 

   

• 1. 완전성(Complete) 

   

  • (1) (누락 없이) 완전해야 한다. 

     

  • (2) 최대한 빠짐없이 가능한 한 상세하게 기술한다. 

     

  • (3) 시스템 기능보다 사용자의 태스크에 초점을 맞춰 기술한다. 

     

• 2. 일관성(Consistent) 

   

  • (1) 일관성이 있어야 한다(서비스에 대한 목표, 시스템 및 사용자의 요구사항). 

     

  • (2) 모든 문서의 UI 스타일(Flow 또는 Layout)을 일관적으로 구성한다. 

     

• 3. 이해성(Understandable) 

   

  • (1) 처음 접하는 사람도 이해하기 쉽도록 구성하고 설명한다. 

     

  • (2) 이해하지 못하는 추상적인 표현이나 이해하기 어려운 용어는 사용하지 않는다.

• 4. 가독성(Readable) 

   

  • (1) 문서를 쉽게 읽을 수 있어야 한다(문서 템플릿과 타이포그래피).

     

  • (2) 표준화된 템플릿을 작성하여 적용한다(회사의 고유한 문서 양식). 

     

  • (3) 버전의 넘버링은 v1.0, v2.0 등과 같이 일관성 있게 한다. 문서의 인덱스에 대한 규칙 적용, 목차 제공이 중요하다. 

     

  • (4) 줄의 간격은 충분하게 유지하며, 단락에 대한 구분과 들여쓰기의 기준을 마련하여 읽기에 쉽고 편해야 한다. 

     

  • (5) 여백과 빈 페이지는 적절하게 활용하여 여백의 미를 살리도록 한다. 

     

  • (6) 시각적인 효과를 위한 하이라이팅은 일관성 있게 활용하도록 한다. 

     

  • (7) 편집기의 상호 참조(Cross-referencing) 기능을 활용한다(하이퍼링크 등)

     

• 5. 수정 용이성(Modifiable) 

   

  • (1) 쉽게 변경이 가능해야 한다. 

     

  • (2) 수정 또는 개선 사항을 시나리오에 반영함에 있어 쉽게 적용할 수 있어야 한다. 

     

  • (3) 동일한 수정 사항을 위해 여러 문서를 편집하지 않도록 한다. 

     

• 6. 추적 용이성(Traceable) 

  •  

    (1) 쉽게 추적이 가능해야 한다. 

     

  • (2) 변경 사항들이 언제, 어디서, 어떤 부분들이, 왜 발생하였는지 추적이 쉬워야 한다. 

     

• 7. 모범적인 UI 시나리오 문서의 효과 

   

  • (1) 요구사항 오류가 감소한다. 

     

  • (2) 의사소통 오류가 감소한다. 

     

  • (3) 개발 과정에서의 재 작업이 감소하고, 혼선이 최소화된다. 

     

  • (4) 불필요한 기능을 최소화한다. 

     

  • (5) 시나리오 작성과 소프트웨어 개발 비용을 절감한다. 

     

  • (6) 개발 속도를 향상시킨다. 

     

  • (7) 유관 부서 만족도를 제고한다.

 

[수행]

[1] UI 요구사항과 UI 표준 및 지침에 따라, 사용자의 편의성을 고려한 메뉴 구조를 설계한다.

• 1. UI 상세설계를 위한 요구사항을 최종 확인한다. 

   

  • (1) UI 설계는 다수의 페이지를 대상으로 다양한 구조 및 디자인에 대한 고민이 필요하 기에 요구사항을 다시 한번 살펴보고 검증 후 진행한다. 

     

    • (가) 수집된 요구사항을 바탕으로 기능 및 제약조건을 확인한다. 

       

    • (나) 구조 및 디자인은 사용자의 목적에 맞게 동선의 편리함과 기능을 위주로 철저 히 준비한다.

• 2. UI 설계서 표지 및 개정 이력을 작성한다. 

   

  • (1) UI 설계서 표지를 작성한다. 

     

    • (가) UI 설계서에 포함될 프로젝트 명 또는 시스템 명을 재확인한다. 

       

      • 1) 타 문서와 혼동되지 않도록 프로젝트 명 또는 시스템 명은 동일하게 사용한다.

 

• (2) UI 설계서 개정 이력을 작성한다. 

   

  • (가) UI 설계서를 처음 작성 시에는 첫 번째 항목으로 ‘초안 작성’을 포함시키고, 그에 해당되는 초기 버전(Version)을 1.0으로 설정한다. 

     

  • (나) 이후 여러 회의를 거치며 회의 내용을 반영하기 위해 변경 및 보완을 할 경우 각 항목을 추가하고 버전을 0.1씩 더한다. 

     

  • (다) 변경 또는 보완이 충분히 이루어져 완성이 되었다고 판단할 경우 버전을 x.0 으로 바꾸어 설정한다.

 

• 3. UI 구조를 설계한다. 

   

  • (1) UI 요구사항들과 UI 프로토타입에 기초하여 UI 구조를 설계한다. 

     

    • (가) UI 요구사항들을 재확인한다. 

       

      • 1) 필요 시 UI 요구사항들을 다시 정리하고 확정/미정 여부를 표시한다.

 

• (나) UI 프로토타입을 재확인한다.

 

• (다) UI 요구사항들과 UI 프로토타입에 기초해 UI 시스템 구조를 설계한다.

 

• 4. 사용자 기반 메뉴 구조를 설계한다. 

   

  • (1) 사이트 맵(Site Map) 구조를 통해 사용자 기반 메뉴 구조를 설계한다. 

     

    • (가) UI 시스템 구조를 바탕으로 사이트 맵 구조를 설계한다. 

       

      • 1) UI 시스템 구조의 내용을 사이트 맵의 형태로 작성한다.

 

• 2) 사이트 맵 상세 내용을 표 형태로 작성한다. 
  

 

• (나) 사용자 관점에서 요구되는 프로세스들을 진행되는 순서에 맞추어 정리한다.
  

 

• 5. 화면을 설계한다.
  

  • (1) UI 프로토타입과 UI 프로세스 정의를 참고해 화면을 설계한다.
    

    • (가) UI 프로토타입과 UI 프로세스 정의를 참고해 각 페이지별로 필요한 화면을 설계 한다. 
      

      • 1) 필요한 화면 수를 산출한다. 
        

      • 2) 각 화면별로 구분되도록 각 화면별 고유 ID를 부여하고 별도의 표지 페이지를 작성한다. 
        

      • 3) 각 화면별로 필요한 화면 내용을 설계한다. 
        

 

 

 

 

 

 

[2] UI 요구사항과 UI 표준 및 지침에 따라, 하위 시스템 단위의 내·외부 화면과 폼을 설계한다.

• 1. 실행 차를 줄이기 위한 UI 설계 원리를 검토한다. 
  

  • (1) 사용 의도를 파악한다. 
    

    • (가) 구축할 시스템의 UI 설계서를 통해 각 화면 설계 결과에서 불필요한 부가 기능 이 있는지 조사한다. 
      

    • (나) 구축할 시스템의 UI 설계서를 통해 각 화면 설계 결과에서 중복되는 기능이 있는지 조사한다. 
      

  • (2) 행위 순서를 검토한다. 
    

    • (가) 구축할 시스템의 UI 설계서를 통해 사용자가 시스템의 각 기능을 사용하기 위 해 어떤 사전 행위들이 수행되어야 하는지 나열하고 조사한다. 
      

    • (나) 구축할 시스템의 UI 설계서를 통해 각 기능들의 상대적 중요도를 상, 중, 하로 나눈 후 적절성을 비교한다.
      

    • (다) 각 기능을 사용하기 위해 필요한 사전 행위들을 바탕으로 중요도가 상 등급인 기능들이 수행되기 위해 필요한 단계 수가 최소화되어 있는지 분석한다. 
      

    • (라) 전반적으로 기능들을 사용하기 위해 필요한 단계 수가 저마다 적절한지 분석한다. 
      
      

  • (3) 행위의 순서대로 실행을 검토한다. 
    

    • (가) 각 기능을 사용하기 위해 필요한 사전 행위들을 바탕으로 구축할 시스템의 UI 설계서 화면 설계 결과에서 편집 창(Editor)이 활용되는 경우, 커서와 포인터 중 무엇이 먼저 활성화되어야 하는지 파악한다. 
      

    • (나) 각 기능을 사용하기 위해 필요한 사전 행위들을 바탕으로 구축할 시스템의 UI 설계서 화면 설계 결과에서 여러 개의 편집 창(Editor)이 활용되는 경우 커서의 올바른 시작 위치를 파악한다. 
      

    • (다) 각 기능을 사용하기 위해 필요한 사전 행위들을 바탕으로 구축할 시스템의 UI 설계서 화면 설계 결과에서 메뉴(Menu)가 활용되는 경우 초기 값으로 무엇이 먼저 활성화되어야 하는지 조사한다. 
      

    • (라) 그 외 초기 값 설정이 필요한 다른 요소들이 없는지 조사한다.

 

• 2. 평가 차를 줄이기 위한 UI 설계 원리를 검토한다. 
  

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

    • (가) 구축할 시스템의 UI 설계서 각 화면 설계 결과에서 각 메뉴/아이콘/윈도우가 활 성화될 경우 적절한 포인터의 형태를 헤아려 결정한다.
      

    • (나) 구축할 시스템의 UI 설계서 각 화면 설계 결과에서 각 기능이 수행되는 동안 적절한 포인터의 형태를 헤아려 결정한다. 
      

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

    • (가) 구축할 시스템에서 다수의 사용자가 동시 접속함에 따라 하나의 처리 업무를 여러 사용자가 동시 접근할 경우 처리 방법을 정리한다. 
      

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

    • (가) 구축할 시스템에서 이미 처리 중인 업무를 사용자가 다시 처리하고자 할 경우 시스템은 결과를 어떻게 알려주어야 하는지 파악한다.

 

[3] UI 검토(Iteration)를 수행하고 보완한다.

• 정보통신산업진흥원 부설 SW공학센터의 “소프트웨어 개발 UI/UX 참조모델 가이드 “(2014)에 따라 다음과 같이 수행한다. 
  

• 1. UI 검토를 수행한다. 
  

  • (1) UI 상세설계를 위한 단계에서 사용성의 반복적인 검토를 통함으로써 완성도가 높은 UI 상세설계 수행이 가능하므로 UI 검토를 2-3번 확인한다. 
    

  • (2) UI 스토리보드 활용을 통해 페이퍼 프로토타입의 평가는 짧은 단위로 개발 및 평가 를 반복하여 확인한다.
    

• 2. UI 검토를 보완한다. 
  

  • (1) 대표 화면이나 인터페이스 위젯(아이콘, 팝업, 체크 박스 등), 물리적인 버튼을 사용 하여 인터랙션에 대한 흐름이 눈에 보이도록 스토리보드를 제작한다. 
    

  • (2) 사용자가 페이퍼 프로토타입을 실제 상황처럼 시뮬레이션하여 사용하면, 컴퓨터의 역할을 하는 사람은 인터랙션을 시뮬레이션하여 시연한다. 
    

    • (가) 컴퓨터 역할을 하기 위해 페이퍼를 조작하는 사람 1~2명 : 매우 중요한 역할을 수 행하므로 가능한 한 인터페이스에 대한 이해도가 가장 높은 사람으로 추천한다. 
      

    • (나) 전체적인 평가를 위한 평가 진행자(Facilitator) 1명 : 평가 진행자가 사용자에게 수행할 과업(Task)을 제시하고 질문 사항에 응답을 받는 실험을 진행한다. 
      

    • (다) 관찰자(Observer) 1명 이상 : 사용자가 수행하는 말과 행동을 관찰하고, 사용자 가 실제 체험하는 어려움이나 설계의 문제점을 관찰 후 기록한다. 
      

  • (3) 위의 사용자 평가 결과를 토대로 설계를 보완한다
    

• 3. UI 시연을 통한 사용성에 대한 검토 및 검증을 수행한다. 
  

  • 소프트웨어의 개발이 시작되면, 각 스크린의 레이아웃과 인터랙션의 대부분이 적용된 고 수준(High-Fidelity)의 프로토타입을 활용하여 내부 개발자 및 전문가의 평가를 거침으로써 개선 사항을 지속적으로 반영하려는 목적으로 UI 사용성 평가를 작성한다. 
    

[연습문제]

• UI 설계서 구성에 따른 작성 방법이 잘못된 것은?

   

  • 1. UI 설계서 표지 : UI 설계서에 포함될 프로젝트 명 또는 시스템 명을 포함시킨다. 

     

  • 2. UI 설계서 개정 이력 : UI 설계서 처음 작성 시에는 첫 번째 항목으로 ‘초안 작성’을 포함시키지 않고 그에 해당 되는 초기 버전(version)을 1.0으로 설정한다. 변경 또는 보완이 충분히 이루어져 완성 이 되었다고 판단할 경우 버전을 x.0 으로 바꾸어 설정한다. 

     

  • 3. UI 요구사항 정의:  UI 요구사항들을 재확인하고 정리한다. 

     

  • 4. 시스템 구조 : UI 프로토타입을 재확인한다.  UI 요구사항들과 UI 프로토타입에 기초해 UI 시스템 구조를 설계한다.

 

• UI 시나리오 작성 원칙이 잘못된 것은?

  • UI의 전체적인 기능과 작동 방식을 개발자가 한눈에 쉽게 이해 가능하도록 구체적으로 작성하여야 한다.  

     

  • 모든 기능은 공통 적용이 가능한 UI 요소와 인터랙션을 일반적인 규칙으로 정의한다.  

     

  • 인터랙션의 흐름을 정의하며, 화면 내와 화면 간 인터랙션의 순서(Sequence), 분기 (Branch), 조건(Condition), 루프(Loop) 등을 명시한다.  

     

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

 

 참고 문헌

[논문]

• 없음

[보고서]

• 없음

[URL]

• 없음

 

 문의사항

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

• sangho.lee.1990@gmail.com

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

• saimang0804@gmail.com

 

 

 

 

 

 

 

 

 

 

 

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