정보처리기사 실기 공부log - 20200929

 

유스케이스 

사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술 

 

UI 표준 및 지침 

UI 표준 : 전체 시스템에 포함된 모든 UI에 공통적으로 적용될 내용으로, 화면 구성이나 화면 이동 등이 포함 

UI 지침 : UI 요구사항, 구현 시 제약사항 등 UI 개발 과정에서 꼭 지켜야 할 공통의 조건을 의미 

 

웹의 3요소 

웹 사이트 개발 시 고려할 사항 

웹 표준(Web Standards) : 웹에서 사용되는 규칙 또는 기술을 의미하는 것으로, 웹 사이트 작성 시 이용하는 HTML, JavaScript 등에 대한 규정, 웹 페이지가 다른 기종이나 플랫폼에서도 구현되도록 제작하는 기법 등을 포함 

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

웹 호환성(Cross Browsing) : 하드웨어나 소프트웨어 등이 다른 환경에서도 모든 이용자에게 동등한 서비스를 제공하는 것 

 

UI 스타일 가이드 

개발자나 디자이너들이 UI를 작성할 때 기준이 되는 규칙들로, 구동환경, 레이아웃, 네비게이션, 기능, 구성요소 순으로 정의한다. 

 

UI 요구사항 확인 

새로 개발할 시스템에 적용할 UI 관련 요구사항을 조사해서 작성하는 단계로, 다양한 경로를 통해 사용자의 요구사항을 조사하고 분석한 후 작성해야 한다. 

목표 정의 -> 활동 사항 정의 -> UI 요구사항 작성 

 

목표 정의 

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

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

인터뷰 진행 시 유의사항 

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

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

인터뷰는 한 시간을 넘지 않도록 함 

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

<인터뷰 후 리서치> 

 

활동사항 정의 

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

사용자와 회사의 비전을 일치시키는 작업을 수행 

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

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

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

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

 

UI 요구사항 작성 

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

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

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

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

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

 

요구사항 요소 확인 

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

 

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

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

제품/서비스의 품질 : 데이터 및 기능 요구 외에 제품의 품질, 서비스, 감성적 품질 등을 고려하여 작성 

제약 사항 : 제품 완료 데드라인, 전체 개발 및 제작에 필요한 비용, 시스템 준수에 필요한 규제가 포함 

 

정황 시나리오 작성 

사용자의 요구사항을 도출하기 위해 작성하는 것으로, 사용자가 목표를 달성하기 위해 수행하는 방법을 순차적으로 묘사 

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

개발하는 서비스의 모습을 상상하는 첫 번째 단계로 사용자 관점에서 시나리오를 작성해야 한다. 

사용자가 주로 사용하는 기능 위주로 작성해야 하며, 함께 발생되는 기능들은 하나의 시나리오에 통합한다. 

육하원칙에 따라 간결하고 명확하게 작성한다. 

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

 

UI 프로토타입 

프로토타입 : 사용자의 요구사항을 기반으로 실제 동작하는 것처럼 만든 동적인 형태의 모형으로, 테스트가 가능하다 

장점 : 사용자를 설득하고 이해시키기 쉽다, 요구사항과 기능의 불일치 등으로 인한 혼선을 예방할 수 있어 개발 시간을 줄일 수 있다, 사전에 오류를 발견할 수 있다 

단점 : 부분적으로 프로토타이핑을 진행하다보면 중요한 작업이 생략될 수 있다, 프로토타입에 사용자의 모든 요구사항을 반영하기 위한 반복적인 개선 및 보완 작업 때문에 작업 시간을 증가시킬 수 있고 필요 이상으로 자원을 소모할 수 있다 

페이퍼 프로토타입 + 디지털 프로토타입 

 

UI 흐름 설계 

업무의 진행 과정이나 수행 절차에 따른 흐름을 파악하여 화면과 폼을 설계하는 단계 

기능 작성 -> 입력 요소 확인 -> 유스케이스 설계 -> 기능 및 양식 확인 

 

기능 작성 

화면에 표현할 기능을 작성하는 단계 

 

UI 상세 설계 

실제 설계 및 구현을 위해 모든 화면에 대해 자세하게 설계를 진행하는 단계 

 

상세설계순서 : 요구사항 확인 -> UI 설계서 표지 및 개정 이력 작성 -> UI 구조 설계 -> 메뉴 구조 설계 -> 화면 설계 

 

네비게이션 vs 사이트맵 

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

사이트맵 : UI 시스템 구조를 바탕으로 사이트에 표시할 콘텐츠를 한 눈에 알아볼 수 있도록 메뉴별로 구분한 모형 

 

--- 

 

애플리케이션 테스트 

애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차 

 

Validation 확인 

사용자의 입장에서 개발한 소프트웨어가 고객의 요구사항에 맞게 구현되었는지 확인하는 것 

 

Verification 검증 

개발자의 입장에서 개발한 소프트웨어가 명세서에 맞게 만들어졌는지 점검하는 것 

 

애플리케이션 테스트의 기본 원리 

완벽한 테스트 불가능 

애플리케이션 테스트는 소프트웨어의 잠재적인 결함을 줄일 수 있지만 결함이 없다고 증명할 수는 없다. 즉 완벽한 소프트웨어 테스팅은 불가능하다. 

 

결함 집중(Defect Clustering) 

애플리케이션의 결함은 대부분 개발자의 특성이나 애플리케이션의 기능적 특징 때문에 특정 모듈에 집중되어 있다. 애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다고 하여 “파레토 법칙"을 적용하기도 한다. 

 

살충제 패러독스(Pesticide Paradox) 

애플리케이션 테스트에서는 동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 반복되지 않는 “살충제 패러독스” 현상이 발생한다. 따라서 테스트 케이스를 지속적으로 보완 및 개선해야 한다. 

 

정황(Context) 의존 

애플리케이션 테스트는 소프트웨어 특징, 테스트 환경, 테스터 역량 등 정황(Context)에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야 한다. 

 

오류-부재의 궤변(Absence of Errors Fallacy) 

소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없다. 

 

테스트와 위험은 반비례 

테스트를 많이 하면 할수록 미래에 발생할 위험을 줄일 수 있다. 

 

테스트의 점진적 확대 

테스트는 작은 부분에서 시작하여 점점 확대하며 진행해야 한다. 

 

테스트의 별도 팀 수행 

테스트는 개발자와 관계없는 별도의 팀에서 수행해야 한다. 

 

테스트 케이스 

구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서 

 

애플리케이션 테스트의 분류 

 

프로그램 실행 여부에 따른 테스트 

정적 테스트 : 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트. 개발 초기에 결함을 발견할 수 있어 소프트웨어의 개발 비용을 낮추는 데 도움이 됨. 

워크스루, 인스펙션, 코드검사 

 

워크스루 Walkthrough = 검토회의 

소프트웨어 개발자의 작업 내역을 개발자가 모집한 전문가들이 검토하는 것 

소프트웨어 검토를 위해 미리 준비된 자료를 바탕으로 정해진 절차에 따라 평가 

오류의 조기 검출을 목적으로 하며 발견된 오류는 문서화한다. 

 

인스펙션 Inspection 

워크스루를 발전시킨 형태로, 소프트웨어 개발 단계에서 산출된 결과물의 품질을 평가하며 이를 개선하기 위한 방법 등을 제시 

 

동적 테스트 : 프로그램을 실행하여 오류를 찾는 테스트로, 소프트웨어 개발의 모든 단계에서 테스트를 수행할 수 있다. 

블랙박스 테스트 + 화이트박스 테스트 

 

테스트 기반(Test Bases)에 따른 테스트 

애플리케이션을 테스트 할 때 무엇을 기반으로 수행하느냐에 따라 명세/구조/경험 기반으로 나뉜다. 

 

명세 기반 테스트 

사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트 

동등분할, 경계 값 분석 

 

구조 기반 테스트 

소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트 

구문 기반, 결정 기반, 조건 기반 

 

경험 기반 테스트 

유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트 

경험 기반 테스트는 사용자의 요구사항에 대한 명세가 불충분하거나 테스트 시간에 제약이 있는 경우 수행하면 효과적이다. 

에러 추정, 체크 리스트, 탐색적 테스팅 

 

 

시각에 따른 테스트 

검증 테스트 : 개발자의 입장에서 개발된 소프트웨어가 명세서에 맞게 잘 작성되었는지 확인 

확인 테스트 : 사용자의 입장에서 개발된 소프트웨어가 고객의 요구사항에 맞게 잘 작성되었는지 확인 

 

목적에 따른 테스트 

회복 테스트 : 시스템에 여러 가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 테스트