코딩묻은 디자이너

사용자 인터페이스(UI; User Interface)

사용자와 시스템간의 상호작용이 원할하게 이루어지도록 도와주는 장치나 소프트웨어

사용자 인터페이스의 세 가지 분야

• 정보 제공과 전달을 위한 물리적 제어에 관한 분야
• 콘텐츠의 상세저인 표현과 전체적인 구성에 관한 분야
• 모든 사용자가 편리하고 간편하게 사용하도록 하는 기능에 관한 분야

특징

• 사용자 만족도에 가장 큰 영향을 미치는 중요한 요소, 소프트웨어 영역 중 변경이 가장 많이 발생
• 사용자의 편리성과 가독성을 높임으로써 작업 시간을 단축, 업무 이해도 향상
• 최소한의 노력으로 원하는 결과 도출
• 수행 결과의 오류를 줄인다
• 사용자의 막연한 작업 기능에 대해 구체적인 방법을 제시
• 정보 제공자와 공급자 간의 매개 역할 수행
• 사용자 인터페이스를 설계하기 위해서는 소프트에어 아키텍처를 반드시 숙지해야한다

*소프트웨어 아키텍처 - 전체 시스템 전반적인 구조 설계, 시스템 구축 및 개선을 용이하게 함

사용자 인터페이스 구분

사용자 인터페이스의 기본 원칙

• 직관성 : 이해하기 쉬워야 한다
• 유효성 : 사용자의 목적을 정확하게 달성해야한다
• 학습성 : 누구나 배울 수 있어야 한다
• 유연성 : 사용자의 요구사항을 최대한 수용하고 실수를 최소화해야 한다

사용자 인터페이스의 설계 지침

• 사용자 중심 : 사용자가 쉽게 이해하기 편리하게 사용할 수 있는 환경을 제공하며, 실사용자에 대한 이해가 바탕이 되어야한다
• 일관성 : 버튼이나 조작 방법 등을 일관성 있게 제공하므로 사용자가 쉽게 기억하고 습득할 수 있게 설계해야 한다.
• 단순성 : 조작 방법을 단순화시켜 인지적 부담을 감소시켜야 한다
• 단순성 : 조작 방법을 단순화시켜 인지적 부담을 감소시켜야 한다
• 결과 예측 가능 : 작동시킬 기능만 보고도 결과를 미리 예측할 수 있게 설계해야 한다
• 가시성 : 메인 화면에 주요 기능을 노출시켜 최대한 조작이 쉽도록 설계해야 한다
• 표준화 : 기능 구조와 디자인을 표준화하여 한 번 학습한 이후에는 쉽게 사용할 수 있도록 설계해야 한다
• 접근성 : 사용자의 연령, 성별, 인종 등 다양한 계층이 사용할 수 있도록 설계해야한다
• 명확성 : 사용자가 개념적으로 쉽게 인지할 수 있도록 설계해야 한다
• 오류 발생 해결 : 오류가 발생하면 사용자가 쉽게 인지할 수 있도록 설계해야한다

사용자 인터페이스 개발 시스템의 기능

• 사용자의 입력 검증 가능
• 에러 처리 와 에러 메시지 표시
• 도움과 프롬프트 제공

2021 시나공 정보처리기사 필기 도서를 학습하고 정리하였습니다

CASE(자동화도구)

자동으로 요구사항을 분석하고, 분석명세서를 기술하도록 개발된 도구

- 표준화와 보고를 통해 문서화 품질 개선

- DB가 모두에게 이용 가능하다는 점에서 분석자들 간의 적절한 조정

- 교차 참조도와 보고서를 통한 결함, 생략, 불일치 발견 용이성

- 변경이 주는 영향 추적의 용이성

- 명세에 대한 유지보수 비용의 축소

자동화 도구는 SADT, SREM, PSL/PSA, TAGS, EPOS등이 있다

SADT

시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널리 이용된 구조적 분석 및 설계도구

구조적 요구 분석을 위해 블록 다이어그램을 채택했다

SREM = RSL/REVS

우주 국방 시스템 그룹 실시간 처리 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 것,

RSL과 REVS를 사용하는 자동화 도구

RSL - 요소, 속성, 관계, 구조들을 기술하는 요구사항 기술 언어

REVS - RSL로 기술된 요구사항을 분석

PSL/PSA

PSL/PSA를 사용하는 자동화 도구

PSL - 기술 언어

PSA - 분석기

TAGS

개발 주기의 전 과정에 이용 할 수 있는 자동화 도구

HIPO(Hierarchy Input Process Output)

시스템의 분석 및 설계나 문서화할 때 사용되는 기법, 시스템 실행 과정인 입려그 처리, 출력의기능 나타냄

- 하향식 소프트웨어 개발을 위한 문서화 도구

- 체계적인 문서 관리 가능

- 기호, 도표 등을 사용해 보기 쉽고 이해하기 쉽다

- 기능과 자료 의존관계 동시 표현 가능

- 변경, 유지보수 용이

HIPO Char는

- 가시적 도표(도식 목차) Visual Table of Contents

- 총체적 도표(총괄도표, 개요 도표) Overview Diagram

- 세부적 도표(상세 도표) Detail Diagram

이 있다

자료 흐름도(Data Flow Diagram)

자료의 흐름 및 변환 과정과 기능을 도식화하여 기술하는 요구사항 분석 기법

자료흐름 그래프, 버블 차트라고도 한다

구조적 분석 기법에 이용된다

- 자료 흐름은 process를 거쳐 변환될 때마다 새로운 이름을 부여받는다

- 처리가 출력 자료를 산출하기 위해서는 반드시 입력 자료가 발생해야 한다

- 처리와 하위 자ㅛㄹ 흐름도의 자료 흐름은 서로 일치되어야 한다

- 자료 저장소에 입력 화살표가 있다고 하여 반드시 출력 화살표가 표시될 필요는 없다

- 도형으로 그려진다

구성요소

- 프로세스(process)

•   동그라미

- 자료 흐름(Flow)

•   화살표

- 자료 저장소(Data Store)

•   평행선

- 단말(Terminator)

•   사각형

자료 사전(Data Dictionary)

자료, 자료들의 집합, 자료의 흐름, 자료 저장소와 그들간의 관계,범위,단위들을 궃적으로 명시

메타 데이터라고도 한다

-특정한 자료 용어가 무엇을 의미하는지 알린다

- 정보를 체계적이고 조직적으로 모아 개발자나 사용자가 편리하게 사용할 수 있다

- 사용 기호

• = is composed of
• + and
• () optional
• {}∩ iteration
• [] selection
• | seperator
• @ key field
• * comment
• ** no comment

기능 요구사항과 비기능 요구사항

요구사항은 일반적으로 기술하는 내용에 따라 기능 요구사항과 비기능 요구사항으로 구분된다.

기능 요구사항

- 시스템의 입, 출력과 관련된 것

- 시스템이 관리하는 데이터와 관련된 것

- 시스템이 무엇을 하는지

- 사용자가 해당 시스템을 통해 제공 받고자 하는 것

비기능 요구사항

- 시스템 장비 등에 대한 요구사항 : 하드웨어, 소프트웨어, 네트워크 등

- 시스템의 성능과 관련된 사항

- 인터페이스와 관련된 사항

- 데이터가 필요로 하는 사항

- 보안, 품질과 관련된 사항

- 정치적, 문화적 요구사항

기능적인 것은 입, 출력과 관련되며 반드시 실행되는 사항 비기능적 요구사항은 입, 출력과 직접적으로 관련이 없는 사항으로 암기해야겠다

XP(eXtreme Programming)

비즈니스 상의 요구 변동이 심한 경우 적합한 개발 방법이다

애자일 개발 프로세스의 대표적인 하나로 꼽힌다

짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것이 목적이다

비교적 작은 규모의 인원의 개발 프로젝트에 적용하기 좋으며 개발 문서보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기에 중점을 두는 경향이 있다

릴리즈의 기간을 짧게 반복아혀 고객의 요구사항 반영에 대한 가시성을 높인다

XP의 가치

의사소통, 단순성, 피드백, 용기, 존중

XP의 원칙

인간성, 경제성, 상호이익, 자기 유사성, 개선, 다양성, 반성, 흐름, 잉여, 실패, 품질

XP의 실천방법

XP 개발 프로세스

유저스토리(사용자스토리)

- 고객의 요구사항을 적어논 것

- 사용자의 입장에서 적으며 개발자 입장에서 재해석 해서는 안된다

릴리즈 계획

- 개발 완료 시점에 대한 일정을 수립한다

스파이크

- 요구사항의 신뢰를 높이고 기술 문제 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램

- 핵심 기능 이외에는 모두 무시하고 최대한 간단하게 작성한다

이터레이션

- 하나의 릴리즈를 더 세분화 한 단위

- 이 기간 중에 새로운 스토리가 작성될 수 있으며, 작성된 스토리는 진행 중인 이터레이션 혹은 다음 이터레이션에 포함될 수있다

승인검사

- 부분 완료 제품이 구현되면 수행한다

- 사용자가 직접 작성한 시나리오를 바탕으로 테스트 코드를 작성한다

- 테스트를 반드시 통과해야 유저스토리 처리가 완료된다

- 테스트가 완료되면 다음 이터레이션을 진행한다

소규모 릴리즈

- 릴리즈를 소규모로 진행하며 고객의 반응을 기능별로 확인할 수 있다

스크럼 기법

- 팀이 중심이 되어 개발의 효율성을 높이는 기법이다

- 팀원은 스스로가 스크럼 팀을 구성하며 개발에 관련된 모든 것을 스스로 해결할 수 있어야 한다

- 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성된다

스크럼이 추구하는 가치

확약 : 약속한 것을 확실히 실현하는 것

전념 : 확약한 것의 실현에 전념하는 것

정직 : 어떤 것이 자신에게 불리해도 숨기지 않는 것

존중 : 자신과 다른 사람에게 경의를 표하는 것

용기 : 팀 구성원은 자신이 옳은 일을 할 수 있도록 팀원간 갈등과 도전을 통해 작업 할 수 있는 용기

스크럼의 진행 순서

스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 ->스프린트 회고

제품 백로그

- 제품 개발에 필요한 요구사항 목록

- 지속적으로 업데이트된다

스프린트 계획 회의

- 스프린트 목표와 스프린트 백로그를 계획하는 외의

- 요구사항을 개발자들이 나눠서 작업할 수 있도록 task라는 작업 단위로 분할한 후 백로그를 작성한다

스프린트

- 반복적인 개발 주기

- 보통 2 ~ 4주 정도의 기간 내에서 진행된다

- 개발자가 원하는 task를 직접 선별하여 담당할 수 있도록 하는 것이 좋다

일일 스크럼 회의

- 날마다 진행되는 미팅으로 어제 한 일, 오늘 할 일, 장애 현상 등을 공유한다

스프린트 검토 회의

- 제품이 요구사항에 잘 부합되는지 테사용자가 포함된 참석자 앞에서 테스팅을 수행한다

- 제품 책임자는 개선할 사항에 대한 피드백을 정리해 백로그를 업데이트 한다

스프린트 회고

- 정핻놓은 규칙을 잘 준수하고, 개선할 점은 없었는지 기록한다

소프트웨어 생명 주기

소프트웨어 생명 주기(Software Life Cycle)이란 소프트웨어의 계획, 개발, 시험, 채용하는 과정을 뜻하는 용어이다.

대개 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 유지보수 단계로 구성되어있다.

소프트웨어 생명주기 모델

일반적으로 사용되는 소프트웨어 생명 주기 모델에는 폭포수 모형, 프로토타임 모형, 나선형 모형, 애자일 모형이 있다

폭포수 모델

- 순차적인 소프트웨어 개발 프로세스로 마치 폭포수처럼 지속적으로 아래로 향하는 것 처럼 보이는 데서 이름이 붙여졌다.

- 가장 오래되고 폭넓게 사용되는 전통적인 소프트웨어 생명 주기 모형이다

- 전 단계가 수행되어 완료되어야 다음 단계로 진행할 수 있다

- 설계자들이 향후 구현 작업의 난이도를 예측하기 어려워 설계가 어렵다는 단점이 있다

- 수정 모델로는 생선회를 겹쳐 내놓는 모양처럼 간 단계들이 서로 겹쳐 있는 사시미 모델이 있다

프로토타입 모델

- 사용자의 모든 요구사항이 정확하게 반영될 때 까지 계속해서 개선/보완하는 모델

- 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다

- 프로토타이핑 과정은 4단계로 구분된다.

    1. 기본적인 사용자 요구사항을 분석한다. 시스템 설계자는 기본적인 요구사항이 도출되기까지 사용자와 함께 작업한다.

    2. 시스템 설계자가 위에 단계에서 도출된 요구사항을 만족시키는 프로토타입을 4세대언어로 알려진 프로그래밍 언어 또는 CASE 도구를 이용하여 개발한다. 이때 프로토타입은 앞으로 개발될 시스템의 가장 핵심적인 기능  위주로 개발된다

    3. 사용자가 개발된 프로토타임을 실제 사용함으로써 요구사항이 이행되고 있는지를 확인하며 프로토타입의 보완을 위한 여러 가지 제안을 하게 된다.

    4. 프로토타입의 수정과 보완이 이루어진다. 시스템 설계자는 사용자가 요구한 모든 제안사항과 이에 따르는 보완작업을 하게 된다. 프로토타입이 수정된 후에는 3단계로 돌아간다. 사용자가 만족할 때 까지 3단계와 4단계는 계속 반복된다.

- 사용자 중심의 개발 방법으로 사용자 요구를 극대화 할 수 있다

- 폭포수 모델에 비해 개발시간을 줄일 수 있다

- 오류를 초기에 발견할 수 있다

- 변경성이 용이하다

- 최종적으로는 시간과 비용이 훨씬 많이 들 수 있다. 언제든지 변경이 용이하지만 이러한 시스템의 변경이 계속되면 오히려 시간과 비용이 많이 들게 된다

나선형모형

- Boehm이 제안한 모델로 폭포수 모형과 원형 모형의 장점을 수용하고 위험 분석을 추가한 점증적 갭라 모델이다

- 프로젝트를 개발하면서 발생하는 위험을 관리하고 최소화하는 것이 목적이다

- 점진적으로 성과를 보면서 개발을 진행하므로 정밀도가 높고 유지보수 과정이 필요없다

- 대규모 프로젝트, 국책사업 및 위험 부담이 큰 시스템 개발에 적합하다

- 진행 순서는 목표설정 -> 위험분석 -> 구현 및 테스트 -> 고객평가 순이다

애자일 모델

- 기민한, 날렵한 이란 뜻으로 좋은 것을 빠르게 취하고, 낭비없게 만드는 다양한 방법론을 통칭해 일컫는다.

- 일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구사항을 더하고 수정하여 개발을 진행한다

- 일직선 과정인 폭포수 모델과 반대의 개념이다

- 계획 -> 설계 -> 개발 -> 테스트 -> 피드백 순으로 반복적으로 진행된다

애자일 소프트웨어 개발 선언

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업ㅇ르 통해 우리는 다음으 가치 있게 여기게 되었다

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas