정보 처리 기사

소프트웨어

 

소프트웨어의 특징

• 상품성: 소프트웨어를 개발하면 상품이 되어 판매가 된다
• 복잡성: 개발하는 과정이 복잡하고 관리가 어렵다.
• 변경 가능성: 프로그램을 일부 수정하여 업그레이드 및 오류 수정 등을 할 수 있다.
• 복제성: 복제가 용이해 쉽게 복사, 유통이 가능하다.

 

시스템의 개요와 기본 요소

• 시스템이란 하나의 조직을 의미
• 기본 요소: 입력, 처리, 출력, 제어, 피드백으로 구성

그림 출제

 

소프트웨어의 위기

• 소프트웨어가 하드웨어의 개발 속도를 따라가지 못해 사용자들의 요구 사항을 감당할 수 없는 문제
• 원인
  • 하드웨어 비용을 초과하는 개발 비용의 증가
  • 개발 기간의 지연
  • 개발 인력 부족 및 인건비 상승
  • 성능 및 신뢰성 부족
  • 유지보수의 어려움에 따른 엄청난 비용

 

소프트웨어 공학

• 경제적으로 신뢰도 높은 소프트웨어를 만들기 위한 방법, 도구와 절차들의 체계
•  IEEE는 소프트웨어의 개발, 운용, 유지보수 및 파기에 대한 체계적인 접근 방법이라 정의
• 기본 원칙
  • 현대적인 프로그래밍 기술 적용
  • 신뢰성이 높아야 한다
  • 사용의 편리성과 유지보수성이 높아야 한다
  • 지속적인 검증 시행을 해야 한다

---

재공학

 

소프트웨어 재공학

• 소프트웨어 위기를 개발의 생산성이 아닌 유지보수의 생산성으로 해결하려는 방법을 의미
• 현재의 시스템을 변경 또는 재구조화하는 것
• 장점
  • 개발 시간 및 비용 감소
  • 품질 향상
  • 생산성 향상
  • 신뢰성 향상
  • 구축 방법에 대한 지식의 공유
  • 프로젝트 실패 위험 감소: 이미 쓰고 있는 것을 쓰는 것이므로 검증 된 것
• 목표
  • 소프트웨어의 유지보수성 향상이 최우선
  • 복잡한 시스템을 다루는 방법 구현, 다른 뷰의 생성, 잃어버린 정보의 복구 및 제거
  • 재사용을 수월하게 하며 소프트웨어의 수명을 연장
• 과정
  • 분석 ➡️ 구성  ➡️ 역공학 ➡️ 이식

 

역공학

• 소프트웨어를 분석하는 기법
• 소프트웨어 개발 과정과 데이터 처리 과정을 설명하는 분석 및 설계 정보를 재발견하거나 다시 만들어내는 작업
• 기존에 만들어져있는 것을 가지고 재문서화

 

CASE

• 소프트웨어 엔지니어링을 도와주는 자동화 도구
• 제공하는 기능
  • 개발을 신속하게 할 수 있고, 오류 수정이 쉬워 소프트웨어 품질이 향상
  • 소프트웨어 생명주기의 전체 단계 연결해주고 자동화시켜 주는 통합된 도구 제공
  • 소프트웨어 시스템의 문서화 및 명세화를 위한 그래픽 기능 제공
  • 소프트웨어 개발 단계의 표준화를 기할 수 있으며 자료 흐름도 작성 기능을 제공
  • 모델들 사이의 모순 검사 기능을 제공하며 다양한 소프트웨어 개발 모형 지원
• 원천 기술
  • 구조적 기법, 프로토타이핑 기술, 정보 저장소 기술
• 장점
  • 개발 기간 단축 및 개발 비용 절약하여 생산성 향상
• 문서화 도구: 설계, 구현,유지보수 등 총괄
• 분류
  • 상위(Upper) CASE: 요구분석 및 설계 단계 지원
  • 하위(Lower) CASE: 소스 코드 작성, 테스트, 문서화 과정 지원
  • 통합(Integrate) CASE: 소프트웨어 개발 주기 전체 과정 지원
• 도구
  • SADT: SoftTech사에서 개발, 구조적 요구분석 위한 블록 다이어그램 채택

---

소프트웨어 설계 방법론

 

소프트웨어 생명주기

• 타당성 검토 ➡️ 개발 계획 ➡️ 요구사항 분석 ➡️ 설계 ➡️ 구현 ➡️ 테스트 ➡️ 운용 ➡️ 유지보수

 

폭포수 모형

• 소규모에 적합: 정확하게 계획하고 빠르게 개발
• 나선형 모형
• 반복적인 작업을 수행
• 중간에 위험 분석이 있음
• 계획 수립 ➡️ 위험 분석 ➡️ 개발 및 검증 ➡️ 고객 평가

폭포수

하향식과 상향식

• 하향식 설계: 가장 중요한 기능 먼저 만들고 나머지 부가적인 것들을 만듦
• 상향식 설계: 가장 단순한 애들을 모아 기둥을 세움

 

프로토타입 모형

• 실제 개발될 시스템의 견본을 미리 만듦
• 문제점을 알 수 있어 요구사항을 충실 반영
• 폭포수 모델의 단점을 보완

 

HIPO

• 계층적 입력 처리 출력
• 가시적 도표: 전체적인 기능과 흐름을 보여주는 구조
• 보기 쉽고 이해하기 쉬우며 유지보수가 쉬움
• 총체적 다이어그램, 세부적 다이어그램
• 하향식 소프트웨어 개발을 위한 문서화 도구

 

V-모델

• 요구사항 분석 ➡️ 기능명세 분석 ➡️ 설계 ➡️ 개발
• 테스트를 단위별로 적용
• 정적: 코드 분석, 동적: 코드 실행
• 폭포수 모형에 시스템 검증과 테스트 작업을 강조한 모델

V 모델

 

애자일 개발 방법론

• 날렵한, 재빠른이란 의미
• 다른거 다 필요없고 고객의 목표만 적용
• 절차와 도구보다 개인과 소통을 중요시하고 고객과의 피드백을 중요하게 생각
• 종류: 익스트림프로그래밍, 스크럼, 린, DSDM, FDD

 

애자일 선언문

• 고객과 제대로 의사소통해서 원하는 것을 만들어 주자

 

XP(eXtremeProgramming)

• 빠르게 양질의 소프트웨어 만드는 것
• 핵심 가치
  • 소통: 개발자, 관리자, 고객 간의 원활한 소통 지향
  • 단순성: 부가적 기능 또는 미사용 구조와 알고리즘 배제
  • Feedback: 지속적 테스와 통합, 반복적 결함 수정
  • 용기: 고객 요구사항 변화에 능동적으로 대응
  • 존중: 개발 팀원 간 상호 존중
• 용어
  • User Story: 일종의 요구사항으로 UML의 유즈케이스와 같은 목적으로 생성되나 형식이 없고 고객에 의해 작성
    • Spike: 어려운 요구사항, 잠재적 솔루션 고려하기 위해 작성하는 간단한 프로그램
    • User Stories: 사용자의 요구사항을 간단한 시나리오로 표현 
  • Release Planning: 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것으로 부분/전체 개발 완료 시점에 대한 일정을 수립
  • Iteration: 하나의 릴리즈를 세분화한 단위이며 1~3주 단위로 진행, 반복 진행 중 스토리가 추가될 때 진행 중 반복이나 다음 반복에 추가
  • Acceptance Test: 테스트를 통해 원하는 것이 만들어지는지를 확인
  • Small Release: 실제 프로그램이 실행 가능한 단위로 만들어내는 것

 

XP의 12가지 실천사항

• Fine Scale Feedback
  • Pair Programming: 한 사람은 코드 짜고, 한 사람은 테스트
  • Planning Game: 게임처럼 선수와 규칙, 목표를 두고 기획에 임함
  • Test Driven Development: 실제 코드 작성하기 전에 단위 테스트부터 작성 및 수행해서 이를 기반으로 코드 작성
  • Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주
• Continuous Process
  • Continuous Integration: 상시 빌드 및 배포를 할 수 있는 상태 유지
  • Design Improvement: 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등 위한 재구성 수행
  • Small Releases: 짧은 주기, 잦은 릴리즈로 고객의 변경사항을 확인
• Shared Understanding
  • Coding Standards: 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성
  • Collective Code Ownership: 시스템에 있는 소스 코드는 팀의 모든 프로그래머가 언제든 수정 가능
  • Simple Design: 가능한 가장 간결한 디자인 상태 유지
  • System Metaphor: 최종적으로 개발되어야 할 시스템의 구조 기술
• Programmer Welfare
  • Sustainable Pace: 개발자에게 과도한 업무를 주지 않는다

 

효과적인  프로젝트 관리 위한 3대 요소(3P)

• 사람: 인적 자원
• 문제: 문제 인식
• 프로세스: 작업 계획

 

SCRUM

• 요구사항 빠르게 적용해서 소프트웨어를 빠르게 개발
• 기본 원리
  • 스프린트 단위로 소프트웨어 개발
  • 스프린트는 고정된 30일의 반복, 스프린트 시행하는 작업은 고정
  • 요구사항, 아키텍처, 설계가 프로젝트 전반에 걸쳐 잘 드러나야 함
  • 정해진 시간을 철저히 지키며, 완료된 작업은 제품 백로그에 기록
  • 가장 기본적인 정보 교환 수단은 일일 스탠드 업 미팅 또는 일일 스크럼

스크럼 팀

• 소멸차트:
  • 작업해야할 내용을 쭉 만들어 놓고 매일매일 한 일을 소거
• 스프린트:
  • 반복 주기(2~4)주마다 이해관계자에게 일의 진척도를 보고

 

스크럼 팀의 역할

• 제품 책임자:
  • 개발 목표에 이해도가 높은 개발 의뢰자, 사용자가 담당
  • 제품 요구사항 파악해 기능 목록 작성
  • 제품 테스트 수행 및 요구사항 우선순위를 갱신
  • 업무 관점에서 우선순위와 중요도 표시하고 신규 항목 추가
  • 스프린트 계획 수립까지만 임무 수행
  • 스프린트 시작되면 팀 운영에 관여하지 않음
• 스크럼 마스터:
  • 업무 배분만 하고 일은 강요하지 않으며 팀을 스스로 조직하고 관리하도록 지원, 장애 요소 찾아 제거
  • 개발 과정에서 스클럼의 원칙과 가치를 지키도록 지원
• 스크럼 팀:
  • 제품 책임자, 스크럼 마스터를 제외한 나머지 개발자(디자이너, 제품 검사기 등)
  • 기능을 작업 단위로 분류하며, 요구사항을 사용자 스토리로 도출, 구현
  • 일정 속도를 추정한 뒤 제품 책임자에게 전달
  • 스프린트 결과물을 제품 책임자에게 시연
  • 매일 스크럼 회의에 참여해 진행 상황 점검

---

현행 시스템 분석

 

정의와 목적

• 정의
  • 현행 시스템이 어떤 하위 시스템으로 구성되어 있는지 파악하는 절차를 의미
  • 현행 시스템의 제공 기능과 타 시스템과의 정보 교환 분석을 파악
  • 현행 시스템의 기술 요소와 소프트웨어, 하드웨어를 파악
• 목적
  • 개발 시스템의 개발 범위를 확인하고 이행 방향성을 설정

 

파악 절차

• 시스템이 어떻게 운영되나 ➡️ 아키텍처(설계도) ➡️ 하드웨어, 네트워크
  • 1단계(시스템 구성 파악 - 시스템 기능 파악 - 시스템 인터페이스 현황 파악)
  • 2단계(아키텍처 파악 - 소프트웨어 구성 파악)
  • 3단계(시스템 하드웨어 현황 파악 - 네트워크 구성 파악)

 

시스템 아키텍처(= 조직 설계도)

• 시스템 내의 상위 시스템과 하위 시스템들이 어떠한 관계로 상호작용하는지 각각의 동작 원리와 구성을 표현
• 단위 업무 시스템별로 아키텍처가 다른 경우 핵심 기간 업무 처리 시스템을 기준으로 함
• 시스템의 전체 구조, 행위, 그리고 행위 원리를 나타내며 시스템이 어떻게 작동하는지 설명하는 틀

상호관계 존재

 

시스템 및 인터페이스 현황 파악

 

시스템 구성 파악

• 조직 내의 주요 업무를 기간 업무와 지원 업무로 구분하여 기술
• 모든 단위 업무를 파악 가능하며, 시스템 내의 명칭, 기능 등 주요 기능 명시

 

시스템 기능 파악

• 단위 업무 시스템이 현재 제공하고 있는 기능을 주요 기능과 하부 기능으로 구분하여 계층형으로 표시

 

인터페이스 현황 파악

• 현행 시스템의 단위 업무 시스템이 타 단위 업무 시스템과 서로 주고받는 데이터의 연계 유형, 데이터 형식과 종류, 프로토콜 및 주기 등을 명시

 

EAI(기업 애플리케이션 통합, SW)

• 기업 내의 다양한 소프트웨어를 통합하고, 조정하는 것을 목표로 하는 도구

 

FEP(전위 처리기, HW)

• 입력 데이터를 프로세서가 처리하기 전에 미리 처리하여 프로세서가 처리하는 시간을 줄여주는 프로그램

 

소프트웨어, 하드웨어, 네트워크 현황 파악

 

소프트웨어 구성 파악

• 시스템 내의 단위 업무 시스템의 업무 처리용 소프트웨어의 품명, 용도, 라이선스 적용 방식, 라이선스 수를 명시
• 시스템 구축 시 많은 예상 비중을 차지하므로 라이선스 적용 방식과 보유한 라이선스 수량 파악이 중요

 

하드웨어 구성 파악

• 각 단위 업무 시스템의 서버 위치 및 주요 사양, 수량, 이중화 여부를 파악

 

플랫폼

 

플랫폼

• 응용 소프트웨어 + (하드웨어 + 시스템 소프트웨어)
• 다양한 애플리케이션이 작동하는 기본이 되는 운영체제 소프트웨어

 

플랫폼 성능 특성 분석

• 현행 사용자가 요구사항을 통해 시스템의 성능상의 문제를 요구할 경우 플랫폼 성능 분석을 통해 사용자가 느끼는 속도를 파악하고 개선 방향을 제시
• 특성 분석 항목: 응답 시간, 가용성, 사용률
• 방법
  • 기능테스트: 현재 시스템의 플랫폼을 평가할 수 있는 기능 테스트 수행
  • 사용자 인터뷰: 사용자 대상으로 현행 플랫폼 기능의 불편함을 인터뷰
  • 문서 점검: 플랫폼과 유사한 플랫폼의 기능 자료 분석

 

현행 시스템의 OS 분석

• 분석 항목:
• OS 종류와 버전
• 패치 일자
• 백업 주기 분석
• 고려 사항:
• 가용성
• 성능
• 기술 지원
• 주변 기기
• 구축 비용(TCO: 일정 기간 사용 비용)
• 메모리 누수:
• 실행 SW가 정상 종료되지 않고 남아있는 증상
• 내가 사용하고 있는 메모리에 운영체제가 사용하고 있는 비율

 

오픈소스 라이선스 종류

• GNU(GNU's Not Unix): 컴퓨터 프로그램은 물론 모든 관련 정보를 돈으로 주고 구매하는 것을 반대하는 것이 기본 이념,  ➡️ Linux
• GNU GPLv1(General Public License): 소스 코드 공개하지 않으면서 바이너리만 배포하는 것을 금지하며, 사용할 수 있는 쉬운 소스 코드를 같이 배포해야 함 ➡️ 소스 코드를 공개하라는 약관에 해당
• BSD(Berkeley Software Distribution): 아무나 개작할 수 있고, 수정한 것을 제한 없이 배포 가능하지만 수정본의 재배포는 의무적인 사항이 아니다 ➡️ 공개하지 않아도 되는 상용 소프트웨어에서도 사용 가능
• Apache 2.0: Apache 재단 소유의 SW 적용을 위해 제공하는 라이선스 ➡️ Android, HADOOP
  • HADOOP: 다수의 저렴한 컴퓨터를 하나로 묶어 대량 데이터를 처리하는 기술

 

현행 시스템 DBMS 분석

 

DBMS(DataBase Management System)

• 종속성과 중복성의 문제를 해결
• 응용 프로그램과 데이터의 중재자로서 모든 응용 프로그램들이 데이터베이스를 공유할 수 있도록 관리
  • 종류: Oracle, IBM DB2, ms SQL server, SQ Lite, MongoDB, Redis

 

현행 시스템 DBMS 분석

• 표준화 명령어지만 DBMS 마다 접근하는 명령어가 차이가 날 수 있으므로 분석

 

고려사항

• 가용성: 장시간 운영 시 장애 발생 가능성, 패치 설치 위한 재 기동 시간과 이중화 및 복제 지원, 백업 및 복구 편의성 등
• 성능: 대규모 데이터 처리 성능, 대량 거래 처리 성능 및 다양한 튜닝 옵션 지원, 비용 기반 최적화 지원 및 설정의 최소화 등
• 기술 지원: 제조업체의 안정적인 기술 지원, 같은 DBMS 사용자들 간의 정보 공유 여부와 오픈소스 여부 등
• 상호 호환성: 설치 가능한 운영체제 종류를 파악하여 다양한 운영체제에서 지원되는지 확인
• 구축 비용: 라이선스 정책 및 비용 유지 또는 관리 비용, 총 소유 비용(TCO) 고려

---

요구사항 개발

 

요구공학

• 고객이 원하는 것을 어떻게 하면 정확하고 확실하게 뽑아낼 수 있을 지를 공부하는 것
• 도구: 자료 흐름도, 자료 사전 등을 이용해 소단위 명세서 구축

 

목적

• 이해관계자 사이의 원활한 의사소통 수단 제공
• 요구사항 누락 방지, 상호 이해 오류 등의 제거로 경제성 제공
• 요구사항 변경 이력 관리를 통해 개발 비용 및 시간 절약 가능
• 비용과 일정에 대한 제약설정과 타당성 조사, 요구 사항 정의 문서화 등을 수행

 

요구사항 베이스라인(기준선)

• 이해 당사자 간의 명시적 합의 내용이며 프로젝트 목표 달성 여부를 확인하는 기준

 

요구공학(개발) 프로세스

• 요구사항을 명확히 분석하여 검증하는 진행 순서를 의미
• 개발 대상에 대한 요구사항을 체계적으로 도출
• 도출된 요구사항을 분석하여 분석 결과를 명세서에 정리
• 정리된 명세서를 마지막으로 확인, 검증하는 일련의 단계
• 경제성, 기술성, 적법성, 대안성 등 타당성 조사가 선행되어야 함

 

SWEBOK에 따른 요구사항 개발 프로세스

• 도출 ➡️ 분석 ➡️ 명세 ➡️ 확인

SWEBOK

 

요구사항 도출

• 소프트웨어가 해결해야 할 문제를 이해하는 단계
• 현재의 상태의 파악하고 문제 정의한 후 문제 해결과 목표를 명확히 도출하는 단계
• 요구사항 도출 기법:
  • 고객의 발표, 문서 조사, 설문 업무 절차 및 양식 조사, 브레인스토밍, 워크숍, 인터뷰, 관찰 및 모델의 프로토타이핑, Use Case, 벤치마킹, BPR(업무 재설계), REP(제안 요청서)

 

요구사항 분석

• 사용자 요구사항이 실제 무엇인지 걸러내는 단계

 

요구분석을 위한 기법:

• 사용자 의견 청취, 사용자 인터뷰, 현재 사용 중인 각종 문서 분석과 중재, 관찰 및 모델 작성 기술, 설문 조사

 

요구사항 분석 단계: 

• 문제인식: 요구사항 파악
• 전개: 파악한 문제 조사
• 평가와 종합: 요구들을 종합하는 과정
• 검토: 적용 가능한지 검토
• 문서화: 요구사항 분석 내용을 문서로 만드는 단계

 

요구사항 분류:

• 기술 내용에 따른 분류: 기능 요구사항, 비기능 요구사항
• 기술 관점 및 대상에 따른 분류: 시스템 요구사항, 사용자 요구사항

 

요구사항 분류 기준:

• 기능 요구사항, 비기능 요구사항 구분하고 우선순위 여부 확인
• 요구사항이 하나 이상의 고수준 요구사항으로부터 유도된것인지 확인
• 이해관계자나 다른 원천으로부터 직접 발생한 것인지 확인
• 요구사항이 제품에 관한 것인지 프로세스에 관한 것인지 확인하고 소프트웨어에 미치는 영향의 범위 확인
• 요구사항이 소프트웨어 생명주기 동안 변경이 발생하는지 확인

 

기능적 요구사항 vs 비기능적 요구사항

• 기능적 요구사항: 시스템이 실제로 어떻게 동작하는지에 관점을 둠
• 비기능적 요구사항: 시스템 구축에 대한 성능, 보안, 품질, 안정성 등으로 실제 수행에 보조적인 요구사항

 

요구사항 명세: 요구사항을 문서화하는 것

• 명세 기법: 정형 명세, 비정형 명세
• 정형 명세:
  • 기법 - 수학적 기반/모델링 기반
  • 종류 - Z, VDM, Petri-Net, LOTOS, CSP, CCS
  • 장점 - 시스템 요구 특성 정확하고 명세가 간결
  • 단점 - 낮은 이해도, 이해관계자의 부담 가중
• 비정형 명세:
  • 기법 - 자연어 기반, 상태/기능/객체 중심 명세 기법
  • 종류 - FSM, Decision Table, ER 모델링, State Chart, UseCase, 사용자 기반 모델링
  • 장점: 명세 작성 이해 용이, 의사전달 방법 다양성
  • 단점: 불충분한 명세 기능, 모호성

 

요구사항 명세 속성

• 정확성
• 명확성: 단 한가지로만 해설되어야 함
• 완전성: 모든 것이 표현(기능+비기능) 가능해야 함
• 일관성: 요구사항 간 충돌이 없어야 함
• 수정 용이성
• 추적성: Rep, 제안성을 통해 추적 가능해야 함

 

요구사항 확인

• 요구사항 분석 단계를 거쳐 문서로 만들어진 내용을 확인하고 검증하는 단계
• 일반적으로 이해 관계자들이 문서 검토해야 하고, 요구사항 정의 문서들에 대해 형상 관리
• 회사의 표준에 적합하고 이해할 수 있고, 일관성 있고, 완전한지 검증
• 필요성: 요구사항 변경으로 인한 비용 편익 분석, 요구사항 변경의 추적, 요구사항 변경에 따른 영향 평가

 

형상 관리

• 소프트웨어 개발 과정에서 나오는 모든 것(문서, 데이터, 자료 등)

 

요구사항 할당

• 요구사항 만족시키기 위한 아키텍처 구성 요소를 식별하는 활동
• 식별된 타 구성 요소와 상호작용 여부 분석을 통하여 추가 요구사항 발견 가능

 

정형 분석

구문과 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현

정확하고 명확하게 표현하여 오해를 최소화 가능

요구사항 분석의 마지막 단계

 

요구사항 확인을 위한 도구

프로토타이핑, 모델 검증, 요구사항 검토, 인수 테스트

 

프로토타이핑:

시제품을 만들어 요구사항을 지속해서 재작성

새로운 요구사항을 도출하기 위한 수단

- 절차: 요구사항 분석 단계 ➡️ 프로토타입 설계 단계 ➡️ 프로토타입 개발 단계 ➡️ 고객의 평가 단계 ➡️ 프로토타입 정제 단계 ➡️ 완제품 생산 단계

장점: 요구사항 분석에 굉장히 용이, 요구사항의 가변성이 프로토타이핑 이후에 급격히 감소, 빠르게 제작하며 반복 제작을 통해 발전된 결과

단점: 완제품이 아니므로 품질이 떨어질 수 있음, 시제품 생성 비용이 발생, 전체 범위 중 일부 대상 범위만 프로토타입 제작하면 사용성이 과대 평가될 수 있음

 

모델 검증:

분석 단계에서 개발된 모델의 품질을 검증

정적 분석: 코드, 일관성 등 문서화 처리

동적 분석: 직접 실행

 

요구사항 검토

 

인수 테스트: 고객에서 전달하는 것으로 최종 단계

최종 제품이 설계시 제시한 요구사항을 만족하는지 확인하는 단계

종류: 계약 인수 테스트, 규정 인수 테스트, 알파 검사, 베타 검사, 사용자 인수 테스트, 운영 인수 테스트

---

UML

(UML, 럼바우 각각 1문제 꼭 출제)

 

개념 모델링(= 도식화)

모델: 요구사항 이해하기 쉽도록 실 세계의 상황을 단순화하여 개념적으로 표현한 것

개념 모델링: 이렇게 표현된 모델을 생성해 나가는 과정

종류: Use Case Diagram, Data Flow Model, State Model, Goal-Based Model, User Interactions, Object Model, Data Model

 

UML(도식화)

객체지향 소프트웨어 개발 과정에서 시스템 분석, 설계, 구현 등의 산출물을 명세화, 시각화, 문서화할때 사용하는 모델링 기술과 방법론을 통합하여 만든 범용 모델링 언어

럼바우의 OMT + 부치의 Booch + 제이콥슨의 OOSE 방법론

 

럼바우(Rumbaugh) 객체지향 분석 기법 (종류 or 각 다이어그램)

객체 모델링(형체): 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체를 다이어그램으로 표시

동적 모델링(행동): 제어흐름, 상호작용, 동작순서 등의 상태를 시간 흐름에 따라 상태 다이어그램으로 표시

기능 모델링: 여러 프로세스 간의 자료 흐름(데이터 흐름)을 표시

 

UML의 특성

비주얼화: 시각화

문서화

명세화: 해당 내용을 구체적으로 기술

구축

 

UML 소프트웨어에 대한 관점

기능적 관점: 사용자 측면에서 본 소프트웨어의 기능, 사용 사례 모델링, Use Case Diagram 사용

정적 관점: 객체 사이의 구조적 관계, Class Diagram 사용

동적 관점: 시스템의 내부 동작, Sequence(순서) Diagram, State(상태) Diagram, Activity(활동) Diagram 사용

 

UML의 기본 구성

사물: 모델 구성하는 기본 요소

관계: 객체 관의 연관성

다이어그램: 객체의 관계를 도식화

- 정적 모델: 구조 다이어그램, 동적 모델: 행위 다이어그램

 

스테레오 타입

UML 확장 모델에서 스테레오 타입 객체 표현할 때 사용하는 기호는 길러멧(Guillemet) << >>이며, 길러멧 안에 확장 요소를 적는다

 

UML 접근 제어자

Public(+): 어떤 클래스의 객체에서든 접근 가능

Private(-): 해당 클래스로 생성된 객체만 접근 가능

Protected(#): 해당 클래스와 동일 패키지에 있거나 상속 관계에 있는 하위 클래스의 객체들만 접근 가능

Package(~): 동일 패키지에 있는 클래스의 객체들만 접근 가능

 

연관 관계 다중성 표현(필기에 나옴)

1: 1개체 연결

* 또는 0..*: 0이거나 그 이상 객체 연결

1..*: 1이거나 1이상 객체 연결

0..1: 0이거나 1객체 연결

1, 3, 6: 1이거나 3이거나 6객체 연결

n: n개 객체 연결

n..*: n이거나 n개 이상 객체 연결

 

UML 다이어그램의 분류

구조적 다이어그램: 정적이고 구조 표현을 위한 다이어그램(움직이지 않는 것)

- 클래스 다이어그램: 시스템 내 클래스의 정적 구조를 표현

- 객체 다이어그램: 객체 정보

- 복합체 구조 다이어그램: 북합 구조의 클래스와 컴포넌트 내부 구조

- 배치 다이어그램: 실행시스템의 물리 구조

- 컴포넌트 다이어그램: 컴포넌트 구조 사이의 관계

- 패키지 다이어그램: 여러 모델 요소들을 그룹화해 패키지 구성하고 패키지 사이 관계를 표현

 

행위 다이어그램: 동적이고 순차적인 표현을 위한 다이어그램(실제 움직이는 것)

- 유스케이스 다이어그램: 사용자 관점에서 시스템 행위

- 활동 다이어그램: 업무 처리 과정이나 연산이 수행되는 과정

- 상태 머신 다이어그램: 객체의 생명주기

- 콜라보레이션 다이어그램: 시퀀스 다이어그램과 같으며 모델링 공간에 제약이 없어 구조적인 면을 중시

- 상호작용 다이어그램: 순차 다이어그램, 상호작용 개요 다이어그램, 통신 다이어그램, 타이밍 다이어그램

-- 순차 다이어그램의 요소: 생명선, 통로, 상호작용, 발생, 실행, 상태불변, 메세지, 활성, 객체, Actor

 

클래스 다이어그램 관계 표현

Class Diagram: 시스템을 구성하는 객체 간의 관계를 추상화

클래스 다이어그램

 

UML 관계 표현(일반화 관계 자주 나옴 - 상속)

구성, 표시, 설명

 

UML 연관 관계

한 사물의 객체가 다른 사물의 객체와 어떻게 연결되었는지

이름: 관계의 의미를 표현하기 위해 이름을 가질 수 있음

역할: 수행하는 역할을 명시적으로 이름을 가질 수 있음

연관 관계

 

UML 의존 관계

연관 관계와 같지만 메소드를 사용할 때와 같이 매우 짧은 시간만 유지

영향을 주는 객체에서 영향 받는 객체 방향으로 점선 화살표 연결

의존 관계

 

UML 일반화 관계

객체지향에서 상속 관계를 표현

일반화 관계

 

UML 집합 관계

A객체가 B객체에 포함된 관계

부분을 나타내는 객체를 다른 객체와 공유 가능

전체 클래스 방향에 빈 마름모 표시하고, or 관계에 놓이면 선 사이를 점선으로 잇고 {or} 표시

집합 관계

 

UML 포함 관계

부분 객체가 전체 객체에 속하는 강한 집한 연관 관계

부분 객체는 다른 객체와 공유 불가능

전체 객체 방향에 채워진 마름모로 표시

포함 관계

 

UML 실체화 관계

인터페이스와 실제 구현된 일반 클래스 간의 관계로 존재하는 행동에 대한 구현

한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계

실체화 관계

 

Use Case Diagram

개념: Actor가 어떤 활동을 하는지를 보는 것

오른쪽은 고객이 아닌 점원

 

Use Case Diagram 요소

시스템 경계: 시스템이 제공해야 하는 사례들의 범위

액터: 서비스 이용하는 외부객체

유스케이스: 시스템이 제공해야 하는 개별적인 서비스 기능

접속 관계: 액터나 유스케이스가 다른 유스케이스의 서비스 이용하는 상황

사용 관계: 여러 개의 유스케이스에서 공통으로 수행해야 하는 기능 모델링

확장 관계: 확장 대상 유스케이스 수행할 때 특정 조건에 따라 확장 기능 유스케이스를 수행하는 경우

 

Usc Case Diagram 작성 단계

액터 식별: 모든 사용자 역할과 상호작용하는 타 시스템 식별

Use Case 식별: 액터가 요구하는 서비스와 정보 식별

관계 정의: 서로의 관계

Use Case 구조화: 구조화

---

소프트웨어 아키텍처

 

소프트웨어 아키텍처

개발 대상 시스템의 전반적인 구조를 체계적으로 설계

 

소프트웨어 아키텍처 품질 요구사항

소프트웨어의 기능, 성능, 만족도 등의 요구사항이 얼마나 충족하는가를 나타내는 소프트웨어 특성의 핵심 집합

 

ISO/IEC 9126 모델

소프트웨어 품질 특성과 평가를 위한 국제 표준

내외부 품질: 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성(기신사효유이)

사용 품질: 효과성, 생산성, 안정성, 만족도

외부지표: 실제 운영하는데 있어 사용자, 평가자, 시험자를 기준으로 지표를 만들어내는 것

내부지표: 실제 설계나 코딩에서 품질 평가

내/외부 품질과 사용 품질 구분 시험에 나옴

 

ISO/IEC 25010

9126에서 개정되어 특성 기준이 6개에서 8개로 증가

내외부 품질: 기능 적합성, 실행 효율성, 호환성, 사용성, 신뢰성, 보안성, 유지보수성, 이식성, 부특성 일부가 증가

 

UI 표준을 위한 환경 분석

사용자 경향 분석: 사용자 요구사항 파악하고, 쉽게 이해 가능한 기능 위주로 기술 영역 정의

 

기능 및 설계 분석

기능 조작성 분석: 사용자 편의를 위한 조작에 관한 분석 확인(스크롤바 지원 가능 여부, 마우스 조작시 동선 확인)

오류 방지 분석: 조작시 오류에 대해 예상 가능한지 확인(의도치 않은 페이지 이동, 기능 버튼의 명확한 구분 가능한지)

최소한의 조작으로 업무 처리 가능한 형태 분석: 작업 흐름에 가장 적합한 레이아웃인지 확인

UI의 정보 전달력 확인: 주요정보 인지, 쉽게 전달 가능한지, 정보제공의 간결성, 사용자 이해성 확인(오류 발생시 해결 방법 접근 용이성 확인)

 

요구사항 요소

데이터 요구, 기능 요구, 제품, 서비스 품질, 제약 사항

 

정황 시나리오 작성

개발하는 서비스의 초기 모양을 상상하는 단계

사용자 관점에서 작성하며 요구사항 정의에서 가장 기초적인 시나리오

사용자가 어떻게 움직이는지에 대한 것을 6하원칙에 의해 만듦

예시

---

UI 표준 및 지침

 

UI

인간, 디지털기기, 소프트웨어 사이에서 의사소통 할수 있도록 만들어진 매개체

 

UI 분야

표현에 관한 분야, 정보 제공과 전달 분야, 기능 분야

 

UI의 특징

실사용자의 만족도에 직접적인 영향을 준다

적절한 UI 구성으로 편리성, 가독성, 동선의 축약 등으로 업무 효율을 높임

실사용자가 수행해야 할 기능을 구체적으로 제시

UI 설계 전 소프트웨어 아키텍처를 우선 숙지

 

UI 개발 시스템이 가져야 할 기능

사용자 입력의 검증, 에러 처리와 에러 메세지 처리, 도움과 프롬프트(입력창) 제공

 

UI 설계 원칙 (시험에 자주 나옴)

직관성: 누구나 쉽게 이해하고 사용

유효성: 사용자의 목적 정확히 달성할 수 있도록 유용하고 효과적이어야 함

학습성: 사용자가 쉽게 배우고 익힐 수 있어야 함

유연성: 사용자의 요구 최대한 수용하면서 오류 최소화

 

UI 설계의 필요성

 

UI 설계 지침

사용자 중심

일관성

단순성

가시성

표준화

접근성

결과 예측 가능

명확성

오류 발생 해결

 

UI 표준

전체 시스템 개발 중에 개발자 간 협업을 통해 각기 개발한 화면 간에 갖추어야 할 최소한의 UI 요소 및 배치 규칙 등의 규칙

 

UI 구현 지침

 

한국형 웹 콘텐츠 접근성 지침 2.1 4가지 원칙

인식의 용이성: 대체 텍스트, 멀티미디어 대체 수단, 명료성

운용의 용이성: 입력 장치 접근성, 충분한 시간 제공, 광과민성 발잔 예방, 쉬운 내비게이션(메뉴)

이해의 용이성: 가독성, 예측 가능성, 콘텐츠의 논리성, 입력 도움

견고성: 문법 준수, 웹 애플리케이션 접근성

 

UX, 사용자 경험(감성공학)

사용자가 제품을 대상으로 직접/간접적으로 사용하면서 느끼고 생각하게 되는 지각과 반응, 행동 등 모든 경험

 

모바일 사용자 UX 설계 시 고려사항(행정안전부 고시)

시스템을 사용하는 대상, 환경, 목적, 빈도 등을 고려

사용자가 직관적으로 서비스 이용 방법을 파악할 수 있게 함

입력의 최소화, 자동 완성 기능 제공

사용자의 입력 실수를 수정할 수 있도록 되돌림 기능 제공

모바일 서비스의 특성에 적합한 디자인 제공

---

UI 설계

 

UI 설계 단계

문제 정의: 시스템의 목적과 해결해야 할 문제 정의

사용자 모델 정의: 사용자 특성 결정하고, 소프트웨어 작업 지식 정도에 따라 초보자, 중급자, 숙련자로 구분

작업 분석: 사용자의 특징 세분화하고 수행되어야 할 작업 정의

컴퓨터 오브젝트 및 기능 정의: 작업 분석을 통해 어떤 사용자 인터페이스에 표현할지 정의

사용자 인터페이스 정의: 물리적 입출력 장치 등 상호작용 오브젝트를 통해 시스템 상태를 명확히 함

디자인 평가: GOMS, Heuristics 기법

- GOMS: 인간이 어떤 행위를 할지 예측하여 그 문제를 해결하는데 필요한 소요시간, 학습시간 등을 평가

- Heuristics: 논리적 근거가 아닌 어림짐작을 통해 답을 도출해내는 방법

 

UI 상세 설계 단계

UI 메뉴 구조 설계

내/외부 화면과 폼 설계

UI 검토 수행

 

UI 상세 설계 - 시나리오 작성 원칙

UI의 전체적 기능, 작동 방식을 개발자가 쉽게 이해할수 있도록 구체적으로 작성

대표 화면 레이아웃 및 하위 기능 정의하고 Tree 구조 또는 Flowchar 표기법 이용

공통 적용이 가능한 UI 요소와 상호작용을 일반적인 규칙으로 정의

상호작용의 흐름 및 순서, 분기, 조건, 루프를 명시

예외 상황에 관한 사례 정의하고 UI 시나리오 규칙 지정

기능별 상세 기능 시나리오를 정의하되 UI 일반 규칙 준수

시나리오 문서 작성 요건: 완전성, 일관성, 이해성, 가독성, 수정 용이성, 추적 용이성

 

UI 흐름 설계서 구성

 

UI 요구사항 정의

 

UI 설계 도구

도움을 주는 것들:

와이어 프레임: UI 중심의 화면 레이아웃을 선을 이용하여 계략적으로 작성

목업: 실물과 흡사한 정적인 모형

프로토타입: 상호작용이 결합하여 실제 작동하는 모형

스토리보드: 정책, 프로세스, 와이어 프레임, 설명이 모두 포함된 설계 문서

 

와이어 프레임: 기획 초기 단계에 작성, 구성할 화면의 개략적인 레이아웃이나 UI 요소 등의 틀을 설계하는 단계

- 툴: 핸드라이팅, 파워포인트, 키노트, Sketch, Balsamiq, Mockup, Adobe Experience Design, 카카오 오븐

 

목업:  와이어 프레임보다 좀 더 실제 제품과 유사하게 만들어지는 실물 크기의 정적 모형으로 시각적으로만 구현

- 툴: 카카오 오븐, Balsamiq Mockup, Power Mockup

 

스토리 보드(이야기 판)

UI/UX 구현에 수반되는 사용자와 작업, 인터페이스 간 상호작용을 시각화

개발자/디자이너와의 의사소통을 돕는 도구

뭘 누르면 어디로 가고 어디 있고 어떻게 되는지를 기록하는 것

 

UI Prototype

도출된 요구사항을 토대로 프로토타입(시제품)을 제작하여 대상 시스템과 비교하면서 개발 중에 도출되는 추가 요구사항을 지속해서 재작성

와이어 프레임, 스토리보드에 Interaction(상호작용)을 적용한 것

툴: HTML/CSS, Axure, Invision Studio, 카카오 오븐, Flinto, 네이버 Proto Now

 

프로토타입의 장단점

장점: 사용자 설득과 이해가 쉽다, 개발 시간이 감소한다, 오류를 사전에 발견할 수 있다.

단점: 수정이 많아지면 작업 시간이 늘어날 수 있다, 필요 이상으로 자원 소모가 많다, 정확한 문서 작업이 생략되는 경우가 있다

 

프로토타입 작성 도구 및 방법

Analog: 손, 펜

Digital: Digital Tool

 

UI Prototype 작성 시 고려사항

 

UI Prototype 계획 시 고려사항

 

UI Prototype 제작 단계

 

감성 공학

인간의 소망으로 이미지나 감성을 구체적 제품 설계를 통해 실현해 내는 공학적 접근 방법

감각 및 생체계측, 센서, 인공지능 등의 생체 제어 기술 등을 통해 과학적으로 접근

 

감성 공학 접근 방법

1류(의미 미분법): 인간의 감각, 감성을 표현

2류: 1류와 기본 틀은 공유하고, 감성 어휘 수집의 전 단계에서 평가자들의 생활 양식을 추가

3류: 1류의 감성 어휘 대신 평가자의 특정 시제품을 사용하여 자신의 감각 척도로 감성을 표출하는 방법

 

HCI

인간과 컴퓨터의 상호작용을 연구해 어떻게 하면 좋은 제품 만들 수 있는지 연구

 

HCI 목적

컴퓨터를 인간이 쉽게 쓸 수 있게 하는 것

 

감성 공학 요소 기술

기초 기술, 구현 기술, 응용 기술

 

감성 공학 관련 기술