정보처리기사 실기 - 화면 설계 : UI 요구사항 확인 수행

정보처리기사 실기 - 화면 설계 : UI 요구사항 확인 수행

 

UI 요구사항 확인 수행

 

① 응용 소프트웨어 개발을 위한 UI 표준 및 지침을 확인

 

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

 

(1) UI 스타일 가이드를 정의

 

(가) 구동 환경 정의

 

• 컴퓨터 OS 확인 : 기업이 운영하고 있는 업무와 보안성이 높은 운영 체제(OS) 확인
• 웹 브라우저 확인 : 웹 브라우저는 익스플로러, 크롬, x-internet 등 기업 환경에 가장 적합한 것으로 확정
• 모니터 해상도 확인 : 모니터 해상도는 1280px*1024px을 표준, 컴퓨터 작업 표시줄 및 브라우저 의 기본 환경(Setting)을 기준으로 브라우저 스크롤이 생기지 않는 안전 지역(Safety Area)은 1280px*2014px
• 프레임 세트 확인 : 업무 처리 주목적으로 속도 및 업무 편의성을 고려하여 각 영역별(Top, Left, Contents 영역) 프레임을 구분해 적용

 

(나) 레이아웃 정의

 

(a) 화면 구조 정의

 

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

 

(b) 상단 메뉴 구성(Top Area) 정의

 

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

 

1) Logo Area(로고 구역) 

 

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

 

⁠2) Login User(접속자) 정보

 

• 화면 우측 상단 첫 번째에 위치
• 접속자에 대한 정보를 표시(Display)

 

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

 

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

 

4) Main Navigation(주 메뉴) 

 

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

 

(c) 내용 구성(Contents Area) 정의

 

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

 

(d) 하단 메뉴 구성(Footer Area) 정의

 

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

 

(e) 사용 환경에 맞춰 페이지 폭 정의

 

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

 

(다) 네비게이션 정의

 

(a) 메뉴 네비게이션(Menu navigation) 정의

 

• Type 1을 적용 : Top, Left 구성을 기본 타입
• Type 2를 적용 : 메뉴 구조가 복잡할 경우 상단 메뉴 구성에 2dpeth를 Drop down으로 적용
• Type 3, 4를 적용 : 프로그램 구성 특성상 화면의 폭(Width)을 넓게 쓰고 싶을 경우 좌측 메뉴에 대해서는 유동적 적용

 

(b) 모듈 뷰(Module View) 정의

 

• 효과적인 모듈의 분리를 위해 응집력(Cohesion) 최대화/결합도(Coupling) 최소화
• 모듈 뷰 타입은 구현 단위 모듈 요소이며 각 모듈은 기능적 책임 할당

 

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)을 일반화한 것으로 부모 모듈이 갖는 특성은 공통성을 포함하며 자식 모듈은 가변성 표현
• 일반화 관계를 사용하여 아키텍처의 확장(Extension) 가능성과 진화(Evolution) 가능성을 이룸
• 자식 모듈의 추가나 변경 또는 삭제를 통하여 아키텍처를 확장할 수 있으며 부모 모듈이 변경하면 모든 자식 모듈도 다 같이 변경되어 진화

 

⁠4) 레이어 타입(Layered Type) 확인

 

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

 

(라) 기능 정의

 

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

 

⁠(a) 프로세스 모델링(Process Modeling) 정의

 

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

 

(b) 데이터 모델(Data Model) 정의

 

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

 

(마) 구성 요소 정의 

 

(a) 그리드 정의

 

• 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. 이 타입은 총 건수 처리에 대한 시스템 부하가 많으므로 가급적 사용하지 않기

 

(b) 버튼 정의

 

1) 기능 버튼 정의

 

• 조회, 저장과 같이 화면마다 공통으로 사용되면서 화면 전체에 영향을 미치는 버튼으로 화면 상단에 위치
• 좌측에 아이콘 이미지, 우측에 버튼명 배치

 

2) 검색 버튼 정의

 

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

 

⁠3) 그리드(Grid) 관련 버튼 정의

 

• 그리드의 데이터를 처리(Handling)하는 버튼

 

4) 기타 버튼을 정의

 

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

 

(2) UI 패턴 모델 정의

 

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

 

(가) 업무 화면 클라이언트(Client) 정의

 

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

 

(나) 서버 컨트롤러(Controller) 정의

 

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

 

(다) 서버 메시지 및 예외(Exception) 처리 정의

 

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

 

(라) 클라이언트(Client)/서버 간 데이터 변환 정의

 

• 어떤 방식의 오브젝트(Object)를 사용할 것인지를 결정하고 클라이언트와 서버 간의 데이터 형태 변환을 어떻게 처리할 것인지 방안 마련
• 유형(Type) 1은 별도의 명백한(Plain) 자바 빈(Java Bean. Domain Object)을 DTO로 구현하여 Request 객체 내에 있는 해당 데이터를 Plain VO로 전환 ex. 고객(Customer), 주문(Order), 상품(Product) 등을 표현하는 클래스들을 일일이 개발하여 활용
• 유형(Type) 2는 별도의 구현 없이 자바 맵(Java Map) 기반의 공통 데이터 클래스 활용

 

(마) EP 연계 정의

 

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

 

(바) 보고서 정의

 

• 클라이언트와 리포트(Report) 솔루션 간의 연계 방식 결정

 

(사) 신 클라이언트(Thin Client)에 외부 컴포넌트 연계 정의

 

• 외부 UI 컴포넌트를 도입할 시 서버와의 연계 방식 결정

 

(3) UI표준 수립을 위한 조직 구성

 

(가) 조직 구성 및 역할 정의

 

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

 

(나) 커뮤니케이션 방안 수립

 

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

 

(4) UI표준을 위한 환경 분석

 

(가) 사용자 트렌드 분석

 

1. 기존 UI와 현재 UI 트렌드 숙지
2. 현재 UI의 단점 상세히 나열
3. 사용자가 필요로 하는 핵심 요구사항 파악
4. 사용자가 쉽게 이해 가능한 기능을 위주로 기술 영역 정의

 

(나) 기능 및 설계 분석

 

(a) 기능 조작성에 대해 분석

 

1. 사용자 편의를 위한 조작에 대해 확인
2. 스크롤바는 지원 가능한지 확인
3. 마우스 조작 및 업무 처리 시 동선에 대해 확인

 

(b) 오류 방지에 대해 분석

 

1. 사용자 조작 시 오류에 대해 예상 가능한지 확인
2. 사용자 의도와 관계 없는 페이지 이동이 있는지 확인
3. 기능 버튼은 사용자가 명확한 구분이 가능한지 확인
4. 기능 버튼 명이 사용자 조작과 일치하는지 확인

 

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

 

1. 작업 흐름에 가장 적합한 레이아웃 확인
2. 기능 특성에 맞는 UI 확인
3. 조작 단계를 최소화하고 동선은 단순한지 확인

 

(d) UI의 정보 전달력 확인

 

1. 중요 정보에 대해 사용자가 인지하기 쉽도록 전달 가능한지 확인
2. 정보 제공 방식이 일관적이며 사용자가 쉽게 이해 가능한지 확인
3. 상호 연관성이 높은 정보가 쉽게 인지 가능한지 확인
4. 오류 발생 시 조치를 위한 접근이 쉬운지 확인
5. 사용자 정보 제공이 간결하고 명확한지 확인

 

② 개발하고자 하는 응용 소프트웨어에 적용될 UI 요구사항 확인

 

(1) 비즈니스 요구사항 확인

 

(가) 목표 정의

 

• 사용자를 대상으로 심층 인터뷰를 통해 의견을 수렴하여 비즈니스 요구사항 정의
• 인터뷰를 통해 사업적, 기술적인 요소를 깊게 이해하여 목표 명확히
• 사업적, 기술적 목표가 확정되면 UI/UX 디자인 프로세스 정의
• 인터뷰는 사용자 리서치 시작 전에 선행(인터뷰 후 취득한 결과를 바탕으로 보다 효율적인 리서치를 준비할 수 있다)

 

(나) 활동 사항 정의

 

1. 초기 비전과 기대 : 사용자, 고객, 회사의 비전을 일치시키는 작업 진행
2. 비용과 일정 확인 : UX 리서치와 UI/GUI 디자인에 필요한 예산과 일정 결정(리서치의 규모, 디자인 목표 등이 결정)
3. 기술적 제약과 가능성 : 현재 기술의 발전 가능성 파악, UI/UX 디자인 미래와 나아갈 방향 제시
4. 사업 전략과 사업 목표, 프로세스의 책임자 선정, 회의 일정 및 계획 작성, 우선순위의 선정, 개별적인 단위 업무 구분
5. 경영진의 프로젝트의 이해도 : 인터뷰한 내용을 기반으로 경영진 내의 서로 다른 UI/UX 개발 프로젝트의 이해를 돕고 협의

 

(다) 인터뷰 진행

 

1. 인터뷰는 가능하면 한꺼번에 여러 명을 하지 않고 개별 진행
2. 다수의 목소리에 집중하여 개인의 중요한 목소리를 놓칠 위험을 염두
3. ⁠각 인터뷰는 한 시간 초과 금지

 

(2) 요구사항 작성

 

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

 

(가) 요구사항 요소 확인

 

1. 데이터 요구 : 사용자가 요구하는 모델과 객체들의 주요한 특성에 기반한 데이터 객체 정리, 인터페이스에 영향을 주므로 초기에 확인 ex) 이메일의 메시지 속성에는 제목, 발신일, 발신인, 참조인, 답변 
2. 기능 요구 : 사용자의 목적 달성을 위해 무엇을 실행해야 하는지를 동사형으로 설명, 기능 요구 리스트로 정리, 최대한 철저하게 ex) 페르소나(Persona)는 이메일의 메시지 내용을 읽거나 삭제, 일정한 양식으로 다른 메시지와 함께 보관
3. 제품, 서비스의 품질 : 데이터 및 기능 요구 외에 중요한 속성으로 제품 품질이 있는데 여기에 감성적인 품질도 고려 ex) 시스템이 얼마나 빨리 파일을 처리하는지 여부와 같이 실용적이며 정량화 가능한 요구사항들 확인 
4. ⁠제약사항 : 제품 출시의 데드라인, 개발 및 제작에 드는 비용, 시스템 준수에 필요한 규제가 포함되며, 사전에 제약사항의 변경 여부(변경 가능, 변경 불가) 확인

 

(나) 정황 시나리오 작성

 

• 요구사항 정의의 가장 기초적인 시나리오
• 높은 수준과 낙관 적인 상황에서의 이상적인 시스템 작동에 초점
• 개발하는 서비스의 모습을 상상하는 단계로 사용자 관점에서 시나리오 작성
• 사용자가 주로 사용하는 기능 위주로 작성하며 같이 동작하는 기능들은 하나의 시나리오에 통합
• 정리된 리스트를 기반으로 사용자의 관점에서 서술
• 육하원칙에 따라 간결하고 명확하게 작성하여 정확하게 전달
• 작성된 시나리오는 외부 전문가 또는 경험이 풍부한 사람에게 검토 의뢰