소프트웨어 설계 - UX 설계 편

사용자에게 초점이 맞춰진 애자일 기반 개발이 주목 받으면서 UX 에 대한 관심이 한층 더 높아지고 있다. UX(User eXperience) 는 소프트웨어에 대한 리서치 , 디자인처럼 과거에는 프로젝트에서 신경을 쓰지 않던 분야였다.

더구나 , UX 는 개발자가 전혀 못하는 영역이었기 때문에 반드시 외부 전문가의 도움을 받아야 했지만 UX 전문가가 프로젝트에 포함되는 경우가 늘어나는 추세이고 만족도는 기대 이상으로 알려져 있다.

UX 는 소프트웨어 개발에서 빠지면 안될 요소로 자리 잡았고, UI(User Interface) 까지 개발자에게서 가져오면서 개발자는 개발에 더집중하도록 하였다 . 최근에는 역할이 더 넓어진 UX 를 더 체계적으로 적용하기 위해 많은 노력이 이어지고 있다.

이번 공학트렌드에서는 소프트웨어를 설계할 때 UX 는 어떻게 설계하는지 살펴보고자 한다 . 소프트웨어 개발 입장에서 바라보는 UX를 살펴보면서 UX 의 역할을 재정의해보고 , 이를 위해 필요한 UX 설계 방법에 대해 알아본다.

소프트웨어 개발에서 바라보는 UX

UX 를 말할 때 “UX 는 UI(User Interface) 와는 다르다” 는 말을 가장 많이 듣는다. 하지만, 이 말로는 UX 가 소프트웨어에서 어떤 역할인지 알 수가 없다 . UX 는 사용자가 경험한 것을 소프트웨어에 반영하여 사용자가 쉽게 소프트웨어를 사용할 수 있게 해준다.

사용자 요구사항으로 소프트웨어 설계가 시작 

소프트웨어를 만들기 위해 사용자 요구사항을 분석해서 모델링을 시작한다 (그림 1 참조). 사용자 요구사항을 분석해서 컨셉 모델(Conceptual Model) 과 논리 모델 (Logical Model) 을 만들고, 이 것을 바탕으로 시스템과 유사한 형태로 물리 모델 (Physical Model)을 만든다.

< 그림 1> 사용자 요구사항에서 시작하는 소프트웨어의 모델링

<그림 1> 의 순서로 프로세스, 데이터, 이벤트, 아키텍처 등을 모델링 한다. 개발자는 물리 모델을 바탕으로 개발을 시작한다. 기존 개발에서는 사용자가 요구사항을 전달하면 프로젝트에 다시 참여할 기회가 거의 없기 때문에 소프트웨어가 원하는 대로 만들어지는지확인이 어려웠다.

UX 는 최상의 품질로 소프트웨어가 만들어질 수 있도록 프로젝트 초기부터 사용자를 지속적으로 참여시키며 의견을 반영한다. UX 가사용자 요구사항을 정리하는 방법 자체를 바꾼 것이다.

사용자 요구사항을 정리하는 방법의 변화 

기존 개발에서는 < 그림 1> 을 개발자가 모두 하였지만, 현재는 사용자와 시스템 간의 흐름이나 인터페이스는 UX 전문가가 전담하는추세다 ( 그림 2 참조 ). 많은 기업들이 UX 를 도입하고 있고 애플이나 삼성과 같은 글로벌 기업은 UX 를 중심으로 제품을 만들고 있다.

< 그림 2> 사용자 요구사항 정리를 개발자에서 UX 전문가로 변화

사용자 요구사항을 정리하기 위해 기존에 썼던 방법은 회의나 인터뷰가 대부분이었다. 회의나 인터뷰는 개발자가 주도했기 때문에 사용자가 알아듣지 못하는 기술 용어가 많았다 . 사용자와 개발자 간의 대화가 어려운 가장 큰 이유다.

UX 전문가는 가급적 사용자의 입장에서 사용자의 용어로 대화하기 때문에 사용자 요구사항을 정확하고 빠르게 정리할 수 있다. 좋은소프트웨어를 만들기 위해서는 사용자 경험을 제대로 이해할 수 있어야 한다.

더 보기 >>>

공공SW 발주관리 해외사례

공공SW 발주시 미국과 유럽의 경우, 민간 전문가와 PMO 등을 활용하여 내용을 전문화 하고 있다.

구분	내용	비고
미국	SW사업 추진시 사업계획을 명확히 하고, 비용 추정의 정확도 향상을 위해 관련 문서를 철저히 작성/검증 발주계획서(AP), 시스템결정서(SDP), PWBS(요구사항 리스트), 정보화원가분석서(IGCE) 등 프로세스별 전문화된 문서 작성 SW사업의 특성을 고려하여 과업내용의 추가 및 변경에 대해 관련 예산을 충분히 확보	민간전문가 채용 순환보직 제외
유럽	영국, 핀란드, 네덜란드 등 SW사업주진시 PMO 적극활용 SW사업 추진 시 요구사항 도출, 예산수립, 과업변경 관리 등을 위해 발주·관리 전문가(Scope Manager) 운영 Scope Manager협회를 구성하고, 발주 요청시 사업에 참여	PMO활용 Scope Manager 참여

소프트웨어공학센터는 공공SW사업의 성공적인 추진을 위한 발주기술지원을 위해, 

공공SW사업 발주관리 全과정에 걸쳐, 전문성이 요구되는 발주업무에 대해 발주관리 전문가 직접투입 지원 추진을 시도하고 있다.

관련 사업 발주 자세히 보기 >>>

구조설계서 구성 항목별 작성 방법

표지
구조설계서에는 SW 프로젝트 명, 담당자, 작성 일자 및 문서 관리 버전 등을 포함하여 작성

목차
구조설계서를 구성하는 항목을 나열하여 작성하고 보고서 내용과 페이지가 일치하게 작성

구조설계문서 개요
프로젝트 구축시 요구되는 하드웨어 자원과 Architecture를 명시

○ 고려사항
아키텍처 설계를 위한 표준(사용도구, 표준 표기법, 표준 양식 등)에 맞게 기술

인터페이스 관계도
아키텍처 간의 외부 인터페이스를 식별하여 명시

○ 고려사항: 다음의 관심사항(Concern) 유형이 식별되었는지 여부를 확인

• 소프트웨어의 목적 또는 미션
• 목적 달성을 위한 소프트웨어 사용상의 적절성
• 외부 시스템과의 연동이 필요한 경우 인터페이스 관계
• 소프트웨어 개발 및 운영상의 위험
• 소프트웨어의 유지보수성

개발 산출물

프로젝트 개발 산출물을 명시한다. 필수 산출물들이 빠짐없이 명시되도록 입력한다.

구조설계서

구조 설계서는 소프트웨어 구성항목에 대한 구조적 설계를 나타내는 문서 요구사항 분석활동에서 정의 및 산출되었던 산출물과 추가로 작성되거나 보충되는 자료를 입력으로 하여 분할되어 구성된 시스템 요소들, 품질속성을 만족하는 아키텍처 패턴 및 설계전술이 적용된 아키텍처 설계 뷰를 기술하는 문서이다.

설계 뷰 작성 활동은 앞에서 수행한 요구사항 분석 활동은 물론, 이후에 수행할 검증활동과 밀접하게 연관되어 수행해야 하며, 분석에서 제시된 품질속성을 기반으로 시스템을 분할하여 아키텍처를 설계하고, 설계된 결과물을 기반으로 아키텍처 검증활동에서 사용된다.

구조설계서에 반드시 포함되어야 할 사항은 다음과 같다.
① 개요: HW SPEC, Architecture
② 내부 시스템간 인터페이스 관계도, 외부 시스템과의 인터페이스 관계도
③ 개발 산출물

위험관리 계획서 구성 항목별 작성 방법

표지
프로젝트 관리 계획서란 제목으로 프로젝트 명, 담당자, 작성 일자 및 문서관리 버전 등을 포함하여 작성

목차
위험관리 관리 계획서를 구성하는 항목을 나열하여 작성하고 보고서 내용과 페이지가 일치하게 작성

프로젝트 개요
프로젝트의 명칭과 기간, 목적 및 기대효과 등을 명시

프로젝트 위험관리 추진체계
프로젝트 위험관리 수행 조직도, 조직 별 역할, 인력 투입 계획 등 위험관리 영역의 인적자원에 해당하는 활동을 기술

○ 고려사항
위험관리 담당자의 역할 및 책임을 명확하게 표준에 맞게 모두 기술

프로젝트 위험관리
프로젝트 이슈 관리 보고 계획, 예상 위험요소 및 대응 방안, 이슈 및 변경관리의 조건 및 관리 절차 등 프로젝트 위험관리 방안을 작성

○ 고려사항

• 위험관리 절차가 기술되었는지의 여부를 확인
• 수행활동 : 위험식별, 분석/평가, 우선순위결정, 완화/대응계획 수립, 완화/대응 활동 수행, 위험 추적 및 모니터링, 위험보고
• 고려할 위험 유형, 위험모니터링 및 재분석 주기, 위험분석/평가방법, 기준
• 위험추적 및 모니터링 방법 또는 사용될 측정지표, 우선순위 결정 방법 등
• 분석 결과 기반으로 위험 대응활동 계획을 기술

요구사항 관리 문서 구성 항목별 작성 방법

표지 및 목차
요구사항 관리 문서에는 SW 프로젝트 명, 담당자, 작성 일자 및 문서 관리 버전 등을 포함하여 작성

목차
요구사항 관리 문서를 구성하는 항목을 나열하여 작성하고 보고서 내용과 페이지가 일치하게 작성

SW 개발 요구사항 문서의 개요
요구사항 관리 문서의 개요는 문서 목적 및 개발 목표, 개략적인 개발 항목, 용어 정의, 참고 문헌 등을 명시

○ 고려사항
작성된 요구사항을 이해관계자들이 이해할 수 있는 수준으로 작성하여야 하며 이를 지원하기 위한 용어집 등을 추가하여야 함

○ 작성 예시

- 문서 개요 및 목적

• 본 문서는 ○○○ 데이터 분석 소프트웨어 개발을 위한 요구사항을 명세하고 있다.
• 본 문서는 설계팀, 개발팀, QA팀, 마케팅팀을 대상으로 한다.
• 본 문서는 기본 사양서를 바탕으로 고객의 요구사항을 명확하게 도출하여 향후 개발 과정에서 이를 반영하는데 그 목적이 있다. 따라서 본 문서는 고객의 정확한 요구사항을 수집하고 이를 분석하여 명세한다.

- 개발 범위

• ○○○ 소프트웨어는 ○○○ 의 데이터 정제, 분석, 시각화 기능을 처리하는 소프트웨어다.
• ○○○ 소프트웨어는 사용자의 이용로그와 사용자 기본 정보를 입력받아, 이들을 분석하고 요약하여 실시간으로 반영되는 리포트와 차트를 생성하여 제시한다.
• ○○○ 소프트웨어는 관리자가 지정한 측정지표를 계산하여, 주기적으로 저장하고 특이상황이 발생하였을 때 이를 알려준다.

시스템 개요
SW 개발 프로젝트의 시스템 목적과 시스템의 범위를 기술한다.

○ 시스템의 목적

• 시스템이 무엇을 수행할 것인가, 누구에게 필요한가, 왜 필요한가, 누가 사용할 것인가 등을 기술

○ 시스템의 범위

• 현행 시스템과의 GAP 분석을 통해 개발 대상 시스템의 범위를 기술 배경도(Context diagram) 등을 이용해 개발 프로젝트에 포함할 것/ 하지 않을 것을 명확히 구분한다.
• 요구사항의 확장을 고려하여 범위를 기술한다.

○ 일반 제약 사항

• 소프트웨어 제약사항과 시스템 구현/운영상의 제약 사항이 있는 경우 기술한다.

소프트웨어 개발 상세 요구사항
제시한 개략적인 기능을 상세하게 정의하는 단계

○ 고려사항

• 설계자들이 요구사항을 만족하는 시스템을 설계하는 데 충분하도록, 그리고 시험자들이 이 시스템이 주어진 요구사항을 제대로 만족하는지를 시험해 볼 수 있도록 충분히 상세한 수준의 소프트웨어 요구사항을 모두 포함
• 사용자와 운영자, 또는 다른 외부의 시스템들은 이 절을 통해서 작성된 모든 요구사항들을 확실히 이해할 수 있어야 함
• 요구사항들은 최소한 시스템에 들어오는 모든 입력과 출력, 시스템에 의해 수행되는 모든 기능들을 포함
• 요구사항 관리 문서에서 가장 크고 중요한 부분이기 때문에 전에 작성된 관련 문서와 상호 참조되어야 하며, 모든 요구사항들은 유일하게 식별되어야 함
• 또한 판독성이 최대한 요구사항들을 구성하는데 세심한 주의가 필요

소프트웨어 개발 일정 계획
개발 일정을 해당 SW의 상세 항목 별로, 주 단위로 표현

요구사항 관리 문서의 구성

요구사항 관리 문서(SRS)는 특정한 환경에서 어떤 기능을 수행하는 프로그램들의 집합 혹은 소프트웨어 제품, 프로그램을 위한 명세서이다. 요구사항 정의서, 요구사항 명세서라고 명칭하기도 하며 요구사항 정의 및 요구사항 분석, 요구사항 변경관리에 대한 내용을 포함해야 한다.

요구사항명세서 작성자들이 다음의 주제를 고려하여 작성해야 한다.

1. 기능 : 소프트웨어가 해야 하는 일은 무엇인가?
2. 외부 인터페이스: 사람들, 시스템내의 하드웨어, 다른 하드웨어, 다른 소프트웨어들과 어떻게 대화하는가?
3. 성능 : 다양한 소프트웨어 기능들의 속도, 가용성, 반복 시간, 회복 시간 등은 무엇인가?
4. 속성: 이식성, 정확성, 유지보수성, 보안성 등의 고려사항은 무엇인가?
5. 구현상의 설계 제약사항: 요구된 표준, 구현 언어, 데이터베이스 무결성 정책, 자원의 제한, 운영 환경 등의 제약사항은 무엇인가?

요구사항 관리 문서에 반드시 포함되어야 할 사항은 다음과 같다.

① 개요: 개발 목표, 개발 항목
② 기술 개발 환경
③ 상세 개발 내용: 모듈 구성, 제공 서비스 기능
④ 일정 계획