I. 소프트웨어 설계 - 요구사항 확인 (2)

(1) 요구분석 기법

 1. 요구분석의 개념

  - 도출된 요구사항 간 상층을 해결하고 소프트웨어의 범위를 파악하여 외부환경과의 상호작용을 분석하는 과정

 

 2. 요구분석 기법

  - 분석 기법으로는 요구사항 분류, 개념 모델, 요구사항 할당, 요구사항 협상, 정형 분석 등이 있다

기법	설명
요구사항 분류	- 요구사항이 기능인지 비기능인지 - 요구사항이 소프트웨어에 미치는 영향의 범위를 파악 - 요구사항이 소프트웨어 생명주기 동안 변경이 발생하는지 확인
개념 모델링	- 개념 모델은 문제 도메인의 *엔터티들과 개별관계 및 종속성 반영 - 시나리오로 나타내기 위해 *유스케이스 다이어그램이 많이 사용
요구사항 할당	- 요구사항을 만족시키기 위한 아키텍처 구성요소를 식별하는 활동 - 다른 구성요소와 어떻게 상호 작용하는지 분석을 통해 추가적인 요구    사항을 발견 가능
요구사항 협상	- 두 명의 이해관계자가 서로 상충되는 내용을 요구하는 경우, 어느 한쪽을 지지하기보다는 적절한 지점에서 합의하기 위한 기법
정형 분석	- 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현 - 정확하고 명확하게 표현 - 요구사항 분석의 마지막 단계에서 이루어짐

* 엔터티 (Entity) : 실체, 객체라는 의미로 유용한 정보를 저장하고 관리하기 위한 집합적인 것

* 유스케이스 (Usecase) 다이어그램 : 프로젝트에 대한 요구사항을 정의하고 세부기능을 분석하며 개발 범위를 정할 때 작성

 

(2) UML 

 1. UML (Unified Modeling Language)

  - 산출물을 명세화, 시각화, 문서화 할 시 사용되는 모델링 기술과 방법론을 통합해 만든 범용 모델링 언어

 

2. UML 특징

  - UML은 방법론을 통합한 것으로, 표준화된 모델링 기법을 제공한다

특징	설명
가시화 언어	- 개념모델 작성 시 오류가 적고 의사소통이 용이
구축 언어	- 다양한 프로그래밍 언어로 실행 시스템의 예측 가능 - UML을 소스코드로 변환하여 구축 가능. 역 변환하여 역공학 가능
명세화 언어	- 정확한 모델 제시. 완전한 모델 작성 가능
문서화 언어	- 시스템에 대한 평가 및 의사소통의 문서

 

 3. UML 구성요소

  - UML은 사물, 관계, 다이어그램으로 구성된다.

구성요소	내용
사물 (Things)	- 추상적인 개념으로, 주제를 나타내는 요소 - 단어 관점에서 '명사' 또는 '동사'를 의미
관계 (Relationships)	- 사물의 의미를 확장하고 명확히 하는 요소 - 사물과 사물을 연결하여 관계를 표현하는 요소 - 단어 관점에서 '형용사' 똔ㄴ '부사'를 의미
다이어그램 (Diagrams)	- 사물과 관계를 모아 그림으로 표현한 상태 - 형식과 목적에 따라 9가지로 정의

 

 4. UML 다이어그램

  - UML 다이어그램은 구분에 따라 정적 모델링, 동적 모델링으로 구분된다

구분	다이어그램	설명
요구사항	유스케이스 (Usecase)	- 사용자 관점에서 시스템의 활동을 표현 - 유스케이스는 시스템의 기능적 요구 정의
정적 모델링	클래스 (Class)	- 시스템 내 클래스의 정적 구조를 표현 - 속성 (Attribute)과 동작(Behavior)로 구성
	객체 (Object)	-객체 인스턴스를 나타내는 대신 실제 클래스를 사용 - 연관된 모든 *인스턴스를 표현
	컴포넌트 (Component)	- 코드 컴포넌트 기반의 물리적 구조 표현 - 실질적 프로그래밍 작업에 사용
	배포 (Deployment)	- 컴포넌트 사이의 종속성을  표현
동적 모델링	시퀀스 (Sequence)	- 객체 간 상호작용을 메세지 흐름으로 표현 - 객체 사이 메세지를 보내는 시간을 표현
	협업 (Collaboration)	- 객체 간 연관성을 표현
	활동 (Activity)	- 활동의 순서대로 흐름을 표현
	상태 (State)	- 모든 가능한 상태와 전이를 표현 - 진입 조건, 탈출 조건, 상태 전이 등 기술

* 인스턴스 (Instance) : *객체지향 프로그래밍에서 해당 클래스의 구조로 컴퓨터 저장 공간에서 할당된 실체이다.

* 객체지향 프로그래밍 (Object Oriented Programming) : 프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체를 만들고 그 객체들 간의 유기적인 상호작용을 통해 로직을 구성하는 프로그래밍 방법 (따로 다뤄보자)

 

(3) 애자일 (Agile)

 1. 애자일 (Agile) 방법론의 개념

  - 소프트웨어 개발방법론의 하나로, 처음부터 끝까지 계획을 수립하고 개발하는 폭포수(Waterfall) 방법론과는 다르게 개발과 함께 즉시

피드백을 받아서 유동적으로 개발하는 방법

 

 2. 애자일 방법론 등장 배경

  - 애자일 방법론은 기존 개발방법론의 한계를 극복하기 위해 등장했다.

등장 배경	설명
소프트웨어 개발 환경의 변화	- 소프트웨어 개발 트렌드가 모바일 환경으로 변화 - 시장 적시성과 잦은 배포의 중요성 부각
기존 개발방법론의 한계	- 전통적 방법론은 문서 및 절차 위주로 변화에 신속한 대응이 어려움 - 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성 증가

 

3. 애자일 선언문

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

 4. 애자일 방법론 유형

  - 애자일 방법론은 대표적으로 XP, 린 (Lean), 스크럼 (SCRUM) 등이 있다.

종류	내용
XP (eXtreme Programming)	- 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론 - 5가지 가치와 12개의 실천항목이 존재 - 반복 : 1~3주의 반복 개발 주기 - 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존중
스크럼 (SCRUM)	- 매일 정해진 시간, 장소에서 잛은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론 - 백로그 (Backlog) : 제품과 프로젝트에 대한 요구사항 - 스프린트 (Sprint) : 2~4주의 짧은 개발 기간, 반복적 수행으로 개발품질 향상 - 스크럼 미팅(Scrum Meeting) : 매일 15분 정도 미팅으로 To-Do-List 계획 수립 - 스크럼 마스터 (Scrum Master) :  프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
린 (Lean)	- 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론 - JIT(Just In Time), 칸반 (Kanban) 보드 사용 - 7가지 원칙 : 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

 

5. 애자일 vs 전통적 방법론

비교 대상	애자일 방법론	전통적 방법론
계획수립	유동적 범위 설정	확정적 범위 설정
업무수행	팀 중심 업무 수행	관리자 주도적 명령과 통제 개인단위로 업무 수행
개발/검증	반복 주기 단위로 소프트웨어를 개발/검증	분석/ 설계/ 구현/ 테스트를 순차적으로 후행
팀관리	업무 몰입, 팀 평가	경쟁, 개별평가
문서화	문서화보다는 코드를 강조	상세한 문서화를 강조
성공요소	고객 가치 전달	계획/ 일정준수