나도개발자

1) 데이터베이스 종류

데이터베이스란?

다수의 인원, 시스템 또는 프로그램이 사용할 목적으로 통합하여 관리되는 데이터의 집합.

데이터에 대한 효과적인 관리를 위해 자료의 중복성 제거, 무결성 확보, 일관성 유지, 유용성 보장 중요.

데이터베이스는 통합된 데이터, 저장된 데이터, 운영 데이터, 공용 데이터

- 통합된 데이터(Integrated Data) : 자료의 중복을 배제한 데이터의 모임

- 저장된 데이터(Stored Data) : 저장 매체에 저장된 데이터

- 운영 데이터(Operational Data) : 조직의 업무를 수행하는 데 필요한 데이터

- 공용 데이터(Shared Data) : 여러 애플리케이션, 시스템들이 공동으로 사용하는 데이터

데이터베이스 특성

- 실시간 접근성 (Real-Time Accessibility) : 쿼리에 대해 실시간 응답 가능

- 계속적인 변화 (Continuous Evolution) : 새로운 데이터의 삽입, 삭제, 갱신으로 항상 최신 데이터 유지

- 동시 공용 (Concurrent Sharing) : 다수의 사용자가 동시에 같은 내용의 데이터를 이용 가능

- 내용 참조 (Content Reference) : 데이터베이스에 있는 데이터를 참조할 때 데이터 레코드의 주소나 위치에 의해서가 아닌, 사용자가 요구하는 데이터 내용으로 데이터를 찾음.

데이터베이스 관리 툴이란?

DB관리자들이 데이터베이스를 편리하고 쉽게 다룰 수 있도록 도와주는 도구.

오픈 소스 기반으로 무료로 사용할 수 있는 툴과 상용화로 비용을 지불해야 사용할 수 있는 툴이 존재.

DB 생성 및 삭제 / SQL 명령어 작성 및 실행 / 상태 모니터링 / 사용자 계정 관리 / DB 내보내기 및 가져오기 / 환경 설정

[데이터베이스 종류]

파일 시스템이란?

파일에 이름을 부여하고 저장이나 검색을 위하여 논리적으로 그것들을 어디에 위치시켜야 하는지 등을 정의한 뒤 관리하는 데이터베이스 전 단계의 데이터 관리 방식.

파일 시스템의 종류

- ISAM (Indexed Sequential Access Method) : 자료 내용은 주 저장부, 자료의 색인은 자료가 기록된 위치와 함께 색인부에 기록되는 시스템. 

- VSAM (Virtual Storage Access Method) : 대형 운영체제에서 사용되는 파일 관리시스템

관계형 데이터베이스 관리시스템(RDBMS : Relational Database Management System)

관계형 모델을 기반으로 하는 가장 보편화된 DBMS.

데이터를 저장하는 테이블의 일부를 다른 테이블과 상화 관계로 표시하며 상관관계 정리.

변화하는 업무나 데이터 구조에 대한 유연성이 좋아 유지 관리 용이.

Oracle / SQL Server / MySQL / Maria DB

계층형 데이터베이스 관리시스템(HDBMS : Hierarchical Database Management System)

데이터를 상하 종속적인 관계로 계층화하여 관리하는 DB

데이터에 대한 접근 속도가 빠르지만, 종속적인 구조로 인하여 변화하는 데이터 구조에 유연하게 대응하기 쉽지 않다.

IMS / System2000

네트워크 데이터베이스 관리시스템(NDBMS : Network Database Management System)

데이터의 구조를 네트워크상의 망상 형태로 표현한 데이터 모델.

트리 구조나 계층형 데이터베이스보다는 유연하지만 설계가 복잡한 단점.

IDS / IDMS

DBMS란?

데이터 관리의 복잡성을 해결하는 동시에 데이터 추가, 변경, 검색, 삭제 및 백업, 복구, 보안 등의 기능을 지원하는 소프트웨어

DBMS 유형

- 키-값(Key-Value) DBMS : 키 기반 Get / Put / Delete 제공, 메모리 기반에서 성능 우선 시스템 및 빅데이터 처리 가능 DBMS. 유니크한 키에 하나의 값을 가지고 있는 형태.

Redis / DynamoDB

- 컬럼 기반 데이터 저장(Column Family Data Store) DBMS : Key 안에 (Column, Value) 조합으로 된 여러 개의 필드를 갖는 DBMS. 테이블 기반, 조인 미지원, 컬럼 기반으로 구글의 Bigtable 기반으로 구현.

HBase / Cassandra

- 문서 저장(Document Store) DBMS : 값의 데이터 타입이 문서라는 타입을 사용하는 DBMS. 문서 타입은 XML, JSON과 같이 구조화 된 데이터 타입으로, 복잡한 계층 구조 표현이 가능.

MongoDB / Couchbase

- 그래프(Graph) DBMS : 시맨틱 웹과 온톨로지 분야에서 활용되는 그래프로 데이터를 표현하는 DBMS. 노드와 엣지로 특징되는 요소 특화. 노드 간 관계를 구조화하여 저장.

Neo4j / AllegroGraph

* 시맨틱 웹(Semantic Web)?

온톨로지를 활용하여 서비스를 기술하고, 온톨로지의 의미적 상호 운용성을 이용해 서비스 검색, 조합, 중재 기능을 자동화하는 웹.

* 온톨로지(Ontology)?

실세계에 존재하는 모든 개념들과 개념들의 속성, 그리고 개념들 간의 관계 정보를 컴퓨터가 이해할 수 있도록 서술해 놓은 지식베이스.

DBMS 특징

- 데이터 무결성 : 부적절한 자료가 입력되어 동일한 내용에 대하여 서로 다른 데이터가 저장되는 것을 허용하지 않음.

- 데이터 일관성 : 삽입 / 삭제 / 갱신 / 생성 후에도 저장된 데이터가 변함없이 일정.

- 데이터 회복성 : 장애가 발생하였을 시 특정 상태로 복구되어야 하는 성질.

- 데이터 보안성 : 불법적인 노출, 변경, 손실로부터 보호되어야 하는 성질.

- 데이터 효율성 : 응답 시간, 저장 공간 활용 등이 최적화되어 사용자, 소프트웨어, 시스템 등의 요구 조건을 만족시켜야 함.

상용 DBMS란?

특정 회사에서 유료로 판매하는 시스템. 유지보수와 지원이 원활함.

오픈소스 기반 DBMS

오픈 소스 라이선스 정책을 준용하는 범위 내에서 자유로운 사용.

오픈소스 기반 DBMS 고려 사항

- 기업들의 원가 절감 노력과의 상관 관계파악.

- 인공 지능, 클라우드, 빅데이터 등 새로운 기술의 증가에 따른 오픈 소스 DBMS의 대응 동향 분석

- 오픈소스 진영에서 보안, 안정성에 대한 우려를 해결하고자 하는지 조사.

- 정책적으로 오픈소스 DBMS 활성화를 추진하는 사례 정리.

[ 데이터베이스 기술 트렌드 ]

빅데이터란?

시스템, 서비스, 조직 등에서 주어진 비용, 시간 내에 처리 가능한 데이터 범위를 넘어서는 수십 PB크기의 비정형 데이터.

빅데이터의 특성

- 양 : PB수준의 대규모 데이터. 디지털 정보량이 기하급수적으로 폭증. 분석 규모

- 다양성 : 정형 / 비정형 / 반정형의 다양한 데이터. 로그, 소셜, 위치 등 데이터의 유형이 다양해짐. 자원 유형

- 속도 : 빠르게 증가하고 수집 및 처리되는 데이터. 가치 있는 정보 활용을 위해 실시간 분석 중요. 수집 / 분석 / 활용 속도

빅데이터 수집, 저장, 처리 기술

- 비정형 / 반정형 데이터 수집 : 내·외부 정제되지 않은 데이터를 확보, 이를 통해 필요 정보를 추출하여 활용하기 위해 효과적으로 수집 및 전송하는 기술. 척와(Chukwa) / 플럼(Flume) / 스크라이브(Scribe)

- 정형 데이터 수집 : 내·외부 정제된 대용량 데이터의 수집 및 전송기술. ETL / FTP / 스쿱(Sqoop) / 하이호(Hiho)

- 분산데이터 저장 / 처리 : 대용량 파일의 효과적인 분산 저장 및 분산 처리 기술. HDFS / 맵 리듀스

* HDFS(Hadoop Distributed File System)이란?

대용량 데이터의 집합을 처리하는 응용 프로그램에 적합하도록 설계뙨 하둡 분산 파일 시스템.

* 맵 리듀스(Map Reduce)이란?

구글에서 대용량 데이터 처리를 분산 병렬 컴퓨팅에서 처리하기 위한 목적으로 제작하여 2004년에 발표한 소프트웨어 프레임워크.

- 분산데이터 베이스 : HDFS의 컬럼 기반 DB로 실시간 랜덤 조회 및 업데이트 가능. HBase

빅데이터 분석, 실시간 처리 및 시각화를 위한 주요 기술

- 빅데이터 분석 : 빅데이터 분석을 위한 데이터의 가공과 분류, 클러스터링, 패턴 분석을 처리하는 기술.

데이터 가공 솔루션 => 피그(Pig), 하이브(Hive) / 데이터 마이닝 솔루션 => 머하웃(Mahout)

- 빅데이터 실시간 처리 : 하둡 기반의 실시간 SQL 질의 처리와 요청된 작업을 최적화하기 위한 워크플로우 관리 기술.

실시간 SQL 질의 솔루션 => 임팔라(Impala) / 워크플로우 관리 솔루션 => 우지(Oozie)

- 분산 코디네이션 : 분산 환경에서 서버들 간에 상호조정이 필요한 다양한 서비스를 분산 및 동시처리 제공 기술.

분산 코디네이션을 위한 솔루션 => 주키퍼(Zookeeper)

- 분석 및 시각화 : 빅데이터 분석 기술을 통해 분석된 데이터의 의미와 가치를 시각적으로 표현하기 위한 기술.

분선 및 시간화를 위한 솔루션 => 알(R)

NoSQL(Not Only SQL)이란?

전통적인 RDBMS와 다른 DBMS를 지칭하기 위한 용어로 데이터 저장에 고정된 테이블 스키마가 필요하지 않고 조인 연산을 사용할 수 없으며, 수평적으로 확장이 가능한 DBMS.

NoSQL 특성

- Basically Available : 언제든지 접근할 수 있어야 함. 분산 시스템이기에 항상 가용성을 중시.

- Soft-State : 노드의 상태는 내부에 포함된 정보에 의해 결정되는 것이 아닌 외부에서 전송된 정보를 통해 결정됨. 특정 시점에서는 데이터의 일관성이 보장되지 않음.

- Eventually Consistency : 일정 시간이 지나면 데이터의 일관성이 유지되는 속성. 일관성을 중시하고 지향함.

NoSQL 유형

(DBMS 유형과 같음)

- Key-Value Store

- Column Family Data Store

- Document Store

- Graph Store

데이터 마이닝이란?

대규모로 저장된 데이터 안에서 체계적이고 자동적으로 통계적 규칙이나 패턴을 찾아내는 기술. 대규모 데이터에서 의미 있는 패턴을 파악하거나 예측하여 의사결정에 활용하는 기법.

데이터 마이닝은 데이터의 숨겨진 정보를 찾아내어 이를 기반으로 서비스와 제품에 도입하는 과정.

통계분석은 가설이나 가정에 따른 분석, 검증을 하지만 데이터 마이닝은 수리 알고리즘을 활용하여 대규모 데이터에서 의미 있는 정보를 찾아냄.

데이터 마이닝 절차

목적 설정 -> 데이터 준비 -> 가공 -> 마이닝 기법 적용 -> 정보 검증

1. 목적 설정 : 데이터 마이닝을 통해 얻고자 하는 명확한 목적 설정. 목적에 따라 사용할 모델과 필요 데이터 정의.

2. 데이터 준비 : 거래정보, 웹로그 데이터, 고객 정보, 데이터 사용량, 소셜 데이터 등 다양한 데이터 활용. 사전에 운영 데이터 접근에 따른 부하 고려. 필요시 작업 서버에 저장하여 운영에 지장이 없도록 데이터를 준비하고 데이터 정제를 통해 데이터의 품질을 보장, 필요시 데이터 추가 등을 통해 충분한 양의 데이터  확보.

3. 가공 : 모델링 목적에 따라 목적 변수 정의. 필요한 데이터를 데이터 마이닝 소프트웨어에 적용할 수 있는 형식으로 가공 처리.

4. 마이닝 기법 적용 : 1단계의 명확한 목적에 맞도록 데이터 마이닝 기법을 적용하여 정보 추출.

5. 정보 검증 : 데이터 마이닝으로 추출된 정보를 검증함. 테스트 데이터와 과거 데이터를 활용하여 최적의 모델을 선정. 데이터 마이닝 결과의 업무 적용 보고서 작성 및 활용.

데이터 마이닝 주요 기법

- 분류 규칙 (Classification) : 과거 데이터로부터 특성을 찾아내어 분류모형을 만들어 이를 토대로 새로운 레코드의 결과 값을 예측하는 기법. 마케팅, 고객 신용평가 모형에 활용.

- 연관 규칙 (Association) : 데이터 안에 존재하는 항목들 간의 종속관계를 찾아내는 기법. 제품이나 서비스의 교차판매, 매장 진열, 사기 적발 등 다양한 분야에서 활용.

- 연속 규칙 (Sequence) : 연관 규칙에 시간 관련 정보가 포함된 형태의 기법. 개인별 트랜잭션 이력 데이터를 시계열적으로 분석하여 트랜잭션의 향후 발생 가능성 예측.

- 데이터 군집화 (Clustering) : 대상 레코드들을 유사한 특성을 지닌 몇 개의 소그룹으로 분할하는 작업으로 작업의 특성이 분류규칙과 유사. 정보가 없는 상태에서 데이터를 분류하는 기법. 분석대상에 결과값이 없으며 판촉활동이나 이벤트 대상을 선정하는데 활용.

데이터 마이닝은 텍스트 마이닝, 웹 마이닝과 함께 다양한 분야에서 활용됨.

* 텍스트 마이닝?

대량의 덱스트 데이터로부터 패턴 또는 관계를 추출하여 의미 있는 정보를 찾아내는 기법. 비정형·반정형 데이터에 대하여 자연어·문서 처리기술을 적용하여 의미있는 정보를 추출.

* 웹 마이닝?

웹으로부터 얻어지는 방대한 양의 정보로부터 유용한 정보를 찾아내기 귀해 분석하는 기법. 웹 자원으로부터 의미있는 패턴, 프로파일, 추세 등을 발견하기 위해 데이터 마이닝 기술을 응용한 것.

1) 물리 데이터 모델 설계

물리 데이터 모델링이란?

논리모델을 적용하고자 하는 기술에 맞도록 상세화해가는 과정.

물리 데이터 모델링 변환 절차

논리 -> 물리

1. 개체를 테이블로 변환

2. 속성을 컬럼으로 변환

3. UID를 기본키로 변환

4. 관계를 외래키로 변환

5. 컬럼 유형과 길이 정의

6. 반 정규화 수행

2) 물리 데이터 저장소 구성

테이블 제약 조건 설계

- 참조무결성 제약 조건

> 제한(Restricted) : 릴레이션과 릴레이션 사이에 대해 참조의 일관성을 보장하기 위한 조건.

> 연쇄(Cascade)

> 널값(Nullify) : 참조되는 릴레이션에서 튜플 삭제하고 참조하는 릴레이션에서 해당 튜플을 참조하는 튜플들의 외래 키에 NULL값을 넣는 옵션.

인덱스란?

검색 연산의 최적화를 위해 DB 내 열에 대한 정보를 구성한 데이터 구조.

인덱스를 통해 전체 데이터의 검색 없이 필요한 정보에 대해 신속한 조회가 가능.

인덱스 적용 기준

인덱스 분포도가 10~ 15% 이내인 경우.

분포도가 범위 이상이더라도 부분처리를 목적으로 하는 경우 적용.

조회 및 출력 조건으로 사용되는 컬럼인 경우 적용.

인덱스 자동생성 기본키와 Unique 키의 제약 조건을 사용할 경우 적용.

인덱스 컬럼 선정

분포도가 좋은 컬럼은 단독 생성!

자주 조합되어 사용되는 컬럼은 결합 인덱스로 생성!

결합 인덱스는 구성되는 컬럼 순서 선정에 유의.

가능한 한 수정이 빈번하지 않은 컬럼으로 선정.

인덱스 설계 시 고려사항

지나치게 많은 인덱스는 오버헤드 작용.

인덱스는 추가적인 저장 공간이 필요함을 고려.

넓은 범위를 인덱스 처리 시 오히려 전체 처리보다 많은 오버헤드를 발생시킬 수 있음에 유의.

인덱스와 테이블의 저장 공간을 적절히 분리될 수 있도록 설계.

뷰 속성

- REPLACE : 뷰가 이미 존재하는 경우 재생성

- FORCE : 본 테이블의 존재 여부에 관계없이 뷰 생성

- NOFORCE : 기본 테이블이 존재할 때 뷰 생성

- WITH CHECK OPTION : 서브 쿼리 내의 조건을 만족하는 행만 변경

- WITH READ ONLY : 데이터 조작어 작업 불가

뷰 설계 시 고려 사항

뷰 사용에 따라 수행속도에 문제 발생 가능.

뷰의 조건은 최적의 액세스 경로를 사용할 수 있도록!

클러스터의 적용 기준

인덱스의 단점 해결.

액세스 기법이 아니라 액세스 효율 향상을 위한 물리적 저장 방법

분포도가 넓을수록 유리. 분포도가 넓은 테이블의 클러스터링은 저장 공간의 절약 가능

대량의 범위를 자주 액세스하는 경우 적용

인덱스를 사용한 처리 부담이 되는 넓은 분포도에 활용

여러 개의 테이블이 빈번하게 조인을 일으킬 때 활용

클러스터 설계 시 고려사항

검색 효율은 높여주지만 입력, 수정, 삭제 시에 부하 증가.

UNION, DISTINCT, ORDER BY, GROUP BY가 빈번한 컬럼이면 검토 대상.

수정이 자주 발생하지 않는 컬럼은 검토 대상.

처리 범위가 넓어 문제가 발생하는 경우 단일 테이블 클러스터링 고려.

조인이 많아 문제가 발생되는 경우 다중 테이블 클러스터링 고려.

파티션의 종류

- 레인지 파티셔닝 : 연속적인 숫자나 날짜를 기준으로 하는 기법. 손쉬운 관리 기법으로 시간 단축 가능

- 해시 파티셔닝 : 파티션 키의 해시 함수 값에 의한 기법. 균등한 데이터 분할 가능. 질의 성능 향상 가능

- 리스트 파티셔닝 : 특정 파티션에 저장 될 데이터에 대한 명시적 제어가 가능한 기법. 분포도 비슷하고 데이터가 많은 SQL에서 컬럼의 조건이 많이 들어오는 경우 유용.

- 컴포지트 파티셔닝 : 2개 이상의 파티셔닝 결합하는 기법. 큰 파티션에 대한 I/O 요청을 여러 파티션으로 분산 가능.

- 라운드로빈 파티셔닝 : 라운드로빈 분할로 회전하면서 새로운 행이 파티션에 할당하는 방식. 파티션에 행의 고른 분포를 원할 때 사용.

파티션의 장점

- 성능 향상 : 데이터 액세스 범위를 줄여 성능 향상

- 가용성 향상 : 전체 데이터의 훼손 가능성이 감소 및 데이터 가용성 향상

- 백업 가능 : 분할 영역을 독립적으로 백업하고 복구 가능

- 경합 감소 : 디스크 스트라이핑으로 입출력 성능 향상. 디스크 컨트롤러에 대한 경합 감소

디스크 구성 설계

- 정확한 용량을 산정하여 디스크 사용의 효율 높임.

- 업무량이 집중되어 있는 디스크를 분리하여 설계.

- 입출력 경합을 최소화하여 데이터의 접근 성능 향상.

- 디스크 구성에 따라 테이블스페이스 개수와 사이즈 등 결정.

- 파티션 수행 테이블은 별도 분류.

1) 데이터 모델

데이터 모델이란?

현실 세계의 정보를 인간과 컴퓨터가 이해할 수 있도록 추상화하여 표현한 모델

데이터 모델의 요소

- 연산 : 데이터베이스에 저장된 실제 데이터를 처리하는 작업에 대한 명세. 릴레이션을 조작하기 위한 관계 연산 (SELECT / PROJECT / JOIN / DIVISION)

- 구조 : 데이터베이스에 논리적으로 표현될 대상으로서의 개체 타입과 개체 타입 간의 관계. 데이터 구조 및 정적 성질을 표현하는 요소

- 제약 조건 : 데이터베이스에 저장될 수 있는 실제 데이터의 논리적인 제약 조건. 데이터 무결성 유지를 위한 DB의 보편적 방법. 릴레이션의 특정 칼럼에 설정하는 제약을 의미(개체 무결성, 참조 무결성 등)

데이터 모델 절차

요구사항 분석 -> 개념적 데이터 모델 -> 논리적 데이터 모델 -> 물리적 데이터 모델

2) 논리 데이터 모델 검증

논리 데이터 모델링이란?

업무의 모습을 모델링 표기법으로 형상화하여 사람이 이해하기 쉽게 표현하는 프로세스.

개념 모델로부터 업무 영역의 업무 데이터 및 규칙을 구체적으로 표현한 모델.

논리 데이터 모델링 종류

- 관계 데이터 모델 

논리적 구조가 2차원 테이블 형태로 구성된 모델.

기본 키와 기를 참조하는 외래 키로 관계를 표현.

1:1 / 1:N / N:M

- 계층 데이터 모델

논리적 구조가 트리 형태로 구성된 모델

상하관계 존재(부모-자식)

1:N

- 네트워크 데이터 모델

논리적 구조가 그래프 형태로 구성된 모델

CODASYL DBTG 모델

N:M

관계 데이터 모델이란?

데이터를 행과 열로 구성된 2차원 테이블 형태로 구성한 모델.

E.F.Codd 박사

관계 데이터 모델 구성

릴레이션 / 튜플 / 속성 / 카디널리티 / 차수 / 스키마 / 인스턴스

관계 대수란?

관계형 DB에서 원하는 정보와 그 정보를 어떻게 유도하는가를 기술하는 절차적 정형 언어.

관계 대수 연산자의 종류

- 일반 집합 연산자 : Union / Intersection / Difference / CARTESIAN Product

- 순수 관계 연산자 : Select / Project / Join / Division

관계 해석이란?

튜플 관계 해석과 도메인 관계 해석을 하는 비절차적 언어.

관계 해석 특징

프레디킷 해석에 기반한 언어이며 비절차적 언어(원하는 정보가 무엇이라는 것만 선언)이다.

논리 데이터 모델링 속성

- 개체 : 사물 또는 사건으로 정의

- 속성 : 개체가 가지고 있는 요소 또는 성질

- 관계 : 두 개체 간의 관계 정의

E-R 모델(개체-관계)이란?

현실 세계에 존재하는 데이터와 그들 간의 관계를 사람이 이해할 수 있는 형태로 명확하게 표현하기 위해 가장 널리 사용되고 있는 모델.

논리 데이터 모델링에서는 모든 이해당사자와 의사소통의 보조 자료로 E-R 모델을 활용.

요구사항으로부터 얻어낸 정보들을 개체, 속성, 관계로 기술한 모델.

정규화란?

관계형 데이터 모델에서 데이터의 중복성을 제거하여 이상 현상을 방지하고, 데이터의 일관성과 정확성을 유지하기 위해 무손실 분해하는 과정.

정규화 단계

1NF : 원자값으로 구성 (속성을 한개만 가지도록 저장.)

2NF : 부분 함수 종속 제거 (완전 함수적 종속 관계)

3NF : 이행함수 종속 제거

BCNF : 결정자 후보 키가 아닌 함수 종속 제거

4NF : 다치(다중 값) 종속 제거

5NF : 조인 종속 제거

반 정규화(= 비정규화, 역정규화)란?

정규화된 엔티티, 속성, 관계에 대해 성능 향상과 개발 운영의 단순화를 위해 중복, 통합, 분리 등을 수행하는 데이터 모델링의 기법.

반 정규화를 위해서는 데이터의 일관성과 무결성을 우선으로 할지, DB의 성능과 단순화에 우선순위를 둘 것인지 비교하여 조정하는 과정이 중요함.

반 정규화의 장점

반 정규화된 데이터 구조는 성능 향상과 관리의 효율성이 증가

반 정규화의 단점

데이터의 일관성 및 정합성 저하

유지를 위한 비용이 별도로 발생하여 성능에 나쁜 영향을 미칠 수 있음.

반 정규화 기법

테이블 병합 / 테이블 분할 / 중복 테이블 추가 / 컬럼 중복화 / 중복관계 추가

이상 현상(Anomaly)이란?

데이터의 중복성으로 인해 릴레이션을 조작할 때 발생하는 비합리적 현상.

- 삽입 이상 : 정보 저장 시 해당 정보의 불필요한 세부정보를 입력해야 하는 경우

- 삭제 이상 : 정보 삭제 시 원치 않는 다른 정보가 같이 삭제되는 경우

- 갱신 이상 : 중복 데이터 중에서 특정 부분만 수정되어 중복된 값이 모순을 일으키는 경우

1) UI 설계를 위한 UML

UML(Unified Modeling Language)이란?

UML은 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어.

UML 특징

- 가시화 / 구축 / 명세화 / 문서화

UML 구성

- 사물 / 관계 / 다이어그램

UML 확장 모델의 스테레오 타입

<<include>> 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계

<<extend>> 하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고, 그렇지 않을 수 도 있는 확장 관계

<<interface>> 모든 메서드가 추상 메서드. 추상 메서드와 상수만으로 구성된 클래스

<<entity>> 일반적으로 정보 또는 오래 지속되는 연관된 행의를 형상화하는 클래스. 유스케이스 처리 흐름이 수행되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스

<<boundary>> 시스템과 외부 액터와의 상호 작용을 담당하는 클래스

<<control>> 시스템이 제공하는 기능의 로직 및 제어 담당하는 클래스

UML 다이어그램

- 구조적 다이어그램

클래스 / 객체 / 컴포넌트 / 배치 / 복합체 구조 / 패키지

> 클래스 다이어그램 : 클래스 / 속성 / 연산 / 접근 제어자.       연관 / 의존 / 일반화 / 실체화 / 포함 / 집합 관계

> 컴포넌트 다이어그램 : 컴포넌트 / 인터페이스 / 의존관계

> 패키지 다이어그램 : 패키지 / 의존관계

- 행위적 다이어그램

유스케이스 / 시퀀스 / 커뮤니케이션 / 상태 / 활동 / 타이밍

> 유스케이스 다이어그램 : 유스케이스 / 액터 / 시스템 / 시나리오 / 이벤트의 흐름.        포함 / 확장 / 일반화 관계

> 시퀀스 다이어그램 : 객체 / 생명선 / 실행 / 메시지

> 활동 다이어그램 : 시작점 / 전이 / 액션 및 액티비티 / 종료점 / 조건 노드 / 병합 노드 / 포크 노드 / 조인 노드 / 구획면

> 상태 다이어그램 : 상태 / 시작 상태 / 종료 상태 / 전이 / 이벤트 / 전이 조건

> 커뮤니케이션 다이어그램 : 액터 / 객체 / 링크 / 메시지

UML 확장 모델의 스테레오 타입

UML의 기본적 요소 이외의 새로운 요소를 만들어 내기 위한 확장 매커니즘.

형태는 UML 요소 사용. 내부 의미는 다른 목적으로 사용하도록 확장.

<<>> 기호 사용.

클래스 다이어그램이란?
객체 지향 모델링 시 클래스의 속성 및 연산과 클래스 간 정적인 관계를 표현한 다이어그램.

클래스 다이어그램의 구성 요소

클래스 / 속성 / 연산 및 메서드 / 접근 제어자 (private - / public + / protected # / default ~)

클래스 간의 관계

연관(Association) / 의존(Dependency) / 일반화(Generalization) / 실체화(Realization) / 포함(Composition) / 집합(Aggregation)

유스케이스 다이어그램이란?

시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램.

유스케이스 다이어그램 구성요소

유스케이스 / 액터 / 시스템 / 시나리오 / 이벤트의 흐름

시퀀스 다이어그램이란?

객체 간 상호 작용을 메시지 흐름으로 표현한 다이어그램.

객체 간의 동적 상호 작용을 시간적 개념을 중심으로 모델링하는 과정.

객체의 오퍼레이션과 속성을 상세히 정의.

유스케이스 실현.

시퀀스 다이어그램 구성요소

액터 / 객체 / 생명선 / 활성화 / 메시지

패키지 다이어그램이란?

서로 다른 패키지들 사이의 의존 관계를 표현하기 위한 다이어그램.

패키지 다이어그램 구성요소

패키지 / 의존관계

활동 다이어그램이란?

시스템이 어떤 기능을 수행하는지를 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서대로 표현하는 다이어그램.

오퍼레이션이나 처리과정이 수행되는 동안 일어나는 일들을 단계적으로 표현.

하나의 유스케이스 안이나, 유스케이스 사이에서 발생하는 복잡한 처리의 흐름을 명확하게 표현.

활동 다이어그램 구성요소

시작점 / 전이 / 액션 및 액티비티 / 조건 노드 / 병합 노드 / 포크 노드 / 조인 노드 / 구획면

상태 다이어그램이란?

하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지 표현하는 다이어그램.

어떤 이벤트에 의해 객체 자신이 속한 클래스의 상태 변화나 객체 간 상호 작용하는 과정에서의 상태 변화를 표현.

객체는 파악된 상태들 이외의 상태는 가질 수 없고, 특정 순간에는 오직 한 상태로만 존재.

객체의 상태란 객체가 갖는 속성값의 변화.

상태 다이어그램 구성요소

상태 / 시작 상태 / 종료 상태 / 전이 / 이벤트 / 전이 조건

커뮤니케이션 다이어그램이란?

시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지를 표현하고, 메시지뿐만 아니라 객체 간의 연관까지 표현하는 다이어그램.

커뮤니케이션 다이어그램 구성요소

액터 / 객체 / 링크 / 메시지

컴포넌트 다이어그램이란?

시스템을 구성하는 물리적인 컴포넌트와 그 사이의 의존 관계를 나타내는 다이어그램.

코드 컴포넌트 기반의 물리적 구조로 표현.

실질적 프로그래밍 작업에 사용.

컴포넌트 다이어그램 구성요소

컴포넌트 / 인터페이스 / 의존 관계

2) UI 흐름 설계

UI 설계서 구성

UI 설계서 표지, UI 설계서 개정 이력, UI 요구사항 정의, 시스템 구조, 사이트 맵, 프로세스 정의, 화면 설계

UI 흐름 설계 수행 절차

UI 설계안의 적정성 확인 -> 화면과 폼의 흐름 설계

3) UI 상세 설계

UI 상세 설계 프로세스

UI 요구사항 최종 확인 -> UI 구조 설계 -> 사용자 기반 메뉴 구조 설계 -> 화면 설계 -> 하위 시스템 단위의 내외부 상세 화면과 폼 설계

UI 검토 및 보완

UI 시나리오 문서이 작성 요건

완전성 / 일관성 / 이해성 / 가독성 / 추적 용이성 / 수정 용이성

4) UI 설계 도구

UI 설계 도구란?

사용자와 시스템 사이에 의사소통할 수 있도록 일시적 또는 영구적인 접근을 목적으로 만들어진 물리적, 가상적 매개체인 UI의 설계를 지원하는 도구.

UI 개발 단계별 활용 가능한 설계 도구

- 분석단계 : UI 패턴, UI 모델링

- 설계단계 : UI 설계

- 구현단계 : 프로토타이핑 툴

UI 설계 도구의 유형

UI 설계 도구의 유형은 UI 구현 절차에 따라 기획단계에서 화면 UI 설계 및 인터랙션 적용에 적합한 도구와 설계 작업 이후 이미 설계된 이미지의 인터랙션 적용에 적합한 도구로 구분.

- 화면 설계 도구 : 파워 목업 / 발사믹 목업 / 카카오 오븐

- 프로토타이핑 도구 : UX핀 / 액슈어 / 네이버 프로토나우

- UI 디자인 도구 : 스케치 / 어도비 익스피리언스 디자인 CC (Adobe XD)

UI 디자인 산출물로 작업하는 프로토타이핑 도구

인비전 / 픽사에이트 / 프레이머

1) UI 요구사항 확인

UI란?

넓은 의미에서 사용자와 시스템 사이에서 의사소통할 수 있도록 고안된 물리적, 가상의 매개체.

좁은 의미로는 정보 기기나 소프트웨어의 화면 등에서 사람이 접하게 되는 화면.

UX란?

제품과 시스템, 서비스 등을 사용자가 직/간접적으로 경험하면서 느끼고 생각하는 총체적 경험을 의미.

UI 유형

- CLI (Command Line Interface) : 정적인 텍스트 기반 

- GUI (Graphical User Interface) : 그래픽 반응 기반 (마우스)

- NUI (Natural User Interface) : 직관적 사용자 반응 기반 (터치, 음성)

- OUI (Organic User Interface) : 유기적 상호 작용 기반

UI 분야

- 물리적 제어 분야 : 정보 제공과 기능 전달을 위한 하드웨어 기반

- 디자인적 분야 : 콘텐츠의 정확하고 상세한 표현과 전체적 구성

- 기능적 분야 : 사용자의 편의성에 맞춰 쉽고 가편하게 사용 가능

UI 설계 원칙

- 직관성 : 누구나 쉽게 이해하고 사용가능해야 함.

- 유효성 : 정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 제작해야 함.

- 학습성 : 초보와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작해야 함.

- 유연성 : 요구사항을 최대한 수용하고, 실수를 방지할 수 있도록 제작해야 함.

UI 설계 지침

사용자 중심 / 일관성 / 단순성 / 결과 예측 가능 / 가시성 / 표준화 / 접근성 / 명확성 / 오류 발생 해결

UI 요구사항이란?

사용자가 정보시스템을 구축하여 얻고자 하는 최종 목적의 기준.

요구사항은 시스템 개발과정 전체에 대한 기준이 되며, 시스템 개발 종료 및 검수의 기준이 됨.

[ 기능적 요구사항 : 시스템이 무엇을 해야하는지 설명 ]

시스템이 제공하는 기능, 서비스에 대한 요구사항.

시스템의 입출력, 데이터, 연산에 관한 요구사항.

[ 비기능적 요구사항 : 개발 과정에서 지켜져야 할 제약 조건 설명 ]

사용성, 효율성, 신뢰성, 유지보수성, 재사용성 등 품질에 관한 요구사항.

플랫폼, 사용 기술 등 시스템 환경에 관한 요구사항.

비용, 일정 등 프로젝트 계획에 관한 요구사항.

UI 품질 요구사항

- 기능성 : 실제 수행 결과와 품질 요구사항과의 차이를 분석하고, 실제 사용 시 정확하지 않은 결과가 발생할 확률과 관련하여 시스템의 동작을 관찰하기 위한 품질 기준.

적절성 / 정밀성 / 상호 운용성 / 보안성 / 호환성

- 신뢰성 : 시스템이 일정한 시간 또는 작동되는 시간 동안 의도하는 기능을 수행함을 보증하는 품질 기준.

성숙성 / 고장 허용성 / 회복성

- 사용성 : 사용자와 컴퓨터 사이에 발생하는 어떠한 행위를 정확하고 쉽게 인지할 수 있는 품질 기준.

이해성 / 학습성 / 운용성

- 효율성 : 할당된 시간에 한정된 자원으로 얼마나 빨리 처리할 수 있는가에 대한 품질 기준.

시간 효율성 / 자원 효율성

- 유지보수성 : 요구사항을 개선하고 확장하는데 있어 얼마나 용이한가에 대한 품질 기준.

분석성 / 변경성 / 안정성 / 시험성

- 이식성 : 다른 플랫폼에서도 많은 추가 작업 없이 얼마나 쉽게 적용이 가능한가에 대한 품질 기준.

적용성 / 설치성 / 대체성

2) UI 표준

UI 표준이란?

디자인 철학과 원칙 기반하에 전체 시스템에 공통으로 적용되는 화면 간 이동, 화면 구성 등에 관한 규약.

UI 표준 구성

전체적인 UX 원칙, 정책 및 철학, UI 스타일 가이드, UI 패턴 모델 정의, UI 표준 수립을 위한 조직 구성

UI 표준 수립 시 고려 사항

- 많은 업무 케이스 포함

- 다양한 사용상황에 대처

- 표준 적용이 쉽도록 충분한 가이드와 활용 수단 제공 필요

- 변화 상황에 맞게 빠르게 변경할 수 있는 관리 조적 수반 필요

- 사용자 편리

UI 스타일 가이드 구성

- UI 구동 환경의 정의 (OS / Web / 해상도 / 프레임 세트)

- 레이아웃 정의 (Top / Left / Contents / Footer Area)

- 메뉴 내비게이션 정의

- 공통 표준 화면 정의

- 기능 정의 : 요구사항에 대한 개념 모델을 논리적 모델로 상세화하여 기능 정의.

- 구성요소 정의 (그리드 / 버튼 및 컨트롤 타입 / Page 요소 / 팝업 요소 / Alert 요소)

UI 패턴 모델 정의

CRUD 방식을 기반으로 데이터의 입출력을 처리하는 화면 흐름을 포함하여 오퍼레이션 방식에 대한 표준 절차를 표시하고 UI 패턴 모델을 개발.

표준 프레임워크로 개발하고, 유스케이스를 이용해 패턴별 표준 개발 방법 7가지 영역을 정의.

- 패턴별 표준 개발 방법 7가지 영역 (업무 화면 클라이언트 / 서버 컨트롤러 / 서버 메시지 및 예외 처리 / 클라이언트 - 서버 간 데이터 변환 / 기업 포털 연계 / 보고서 / 외부 컴포넌트 연계)

UI 표준 수립을 위한 조직 구성

- 조직 구성 및 역할 정의 : 효과적인 프로젝트 추진을 위해 UI 팀 및 표준 개발 팀을 주축으로 한 추진 조직 구성 확정.

- 커뮤니케이션 방안 수립 : UI 개발이 원활히 수행되도록 정식 보고 및 정기적 회의와 이슈 회의 등 다양한 커뮤니케이션 방안 마련.

3) UI 지침

UI 지침이란?

UI 표준에 따라 사용자 인터페이스 설계, 개발 시 지켜야 할 세부 사항을 규정하는 가이드라인.

(목표 정의 / 프로젝트 계획 / 요구사항 정의 / 설계 및 구현 / 테스트 / 배포 및 관리)

UI 표준 적용을 위한 환경 분석

- 사용자 트렌드 분석

- 기능 및 설계 분석 : 기능 조작성 / 오류 방지 / 최소한 조작으로 업무 처리 가능 여부 / UI의 정보 전달력 확인

UI 개발 목표 및 범위

- UI 개발을 위한 주요 기법 (3C 분석 / SWOT 분석 / 시나리오 플래닝 / 사용성 테스트 / 워크숍)

사용자 분석 및 니즈 조사

- 리서치 대상 선정 및 내용 설계 -> 리서치 진행 -> 리서치 결과 정리

사용자 요구사항 도출

- 페르소나 : 잠재적 사용자의 다양한 목적과 관찰된 행동 패턴을 응집시켜 놓은 가상의 사용자

- 콘셉트 모델 : 여러 추상적인 컨셉들 사이의 관계를 보여주는 다이어그램. 브레인스토밍 활용

- 사용자 요구사항 : 결과물을 토대로 요구사항을 도출하고 우선순위 선정. 요구사항 매트릭스 작성 및 정황 시나리오 제작.

- UI 컨셉션 : 정리된 요구사항을 구체화. 대표 화면 설계.

4) 스토리보드

스토리보드란? 

UI 화면 설계를 위해 정책이나 프로세스 및 컨텐츠의 구성, 와이어 프레임, 기능에 대한 정의, DB 연동 등 구축하는 서비스를 위한 대부분 정보가 수록된 문서.

디자이너와 개발자가 최종적으로 참고하는 산출 문서.

UI 화면 설계

- 와이어 프레임 : 서비스의 간략한 흐름을 공유하기 위해 화면 단위의 레이아웃을 설계하는 작업. (PPT / 키노트 / 스케치 / 일러스트)

- 스토리보드 (PPT / 키노트 / 스케치)

- 프로토타입 : 정적인 화면으로 설계된 와이어프레임 또는 스토리보드에 동적 효과를 적용하여 실제 시뮬레이션할 수 있는 모형 (HTML / CSS)

스토리보드 작성 절차

전체 개요 작성 -> 서비스 흐름 작성 -> 스타일 확정 -> 메뉴별 화면 설계도 작성 및 상세 설명 -> 추가 관련 정보 작성

스토리보드 작성 시 유의사항

일관된 기호, 공통 영역 정의, 영역별 세부 설계, 버전 관리

5) UI 프로토타입 제작 및 검토

프로토타입이란?

컴퓨터 시스템이나 소프트웨어의 설계 또는 성능, 구현 가능성, 운용 가능성을 평가하거나 요구사항을 좀 더 잘 이해하고 결정하기 위해 전체적 기능을 간략하게 구현한 시제품.

사용자의 요구사항이 정확하게 반영될 때 까지 지속적으로 개선하고 보완해서 최종 설계함.

사전에 프로토타입을 제작하고, 이를 기반으로 UI 적정성을 평가, 수정 보완함으로써 추후 발생 가능한 오류들을 사전에 방지 가능.

시스템 설계 및 개발에 소요되는 총 비용과 노력 절감 가능.

장점

- 사용자 설득과 이해 쉬움.

- 개발 시간 감소

- 오류 사전 발견 가능

단점

- 수정 과정 증가 시 작업 시간 증가 위험

- 요구사항에 대한 적절한 타협 필요

- 자원 효율성 관점에서 필요 이상의 많은 자원 소모

아날로그 유형

- 종이와 펜을 활용한 화면 구조 스케치

- 화이트보드, 펜, 종이, 포스트잇 사용

- 제작 기간 짧고, 비용이 적고, 업무 협의가 빠른 상황에 적용

디지털 유형

- 프로토타이핑 도구(HTML / 디지털 편집기)를 사용해 화면의 구조를 만듦.

- 키노트, HTML, UX pin 사용

- 재사용이 필요하거나 산출물과 비슷한 효과를 필요로 할 경우, 숙력된 전문가가 있을 경우에 적용

요구사항

1) 요구공학이란?

사용자의 요구가 반영된 시스템을 개발하기 위해 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동.

2) 요구공학의 목적

이해 관계자 사이에 효과적인 의사소통 수단을 제공하고 시스템 개발의 요구사항에 대한 공통된 이해를 설정.

요구사항 누락 방지 및 이해 오류로 인한 불필요한 비용을 절감하고 요구사항 변경 추적을 가능하게 함.

초기 요구사항 관리로 개발 비용과 시간을 절약하고 효과적인 의사소통 수단 제공.

[ 기능적 요구사항 ]

시스템이 제공하는 기능 및 서비스에 대한 요구사항.

특정 입력 및 상황에 대해 시스템이 어떻게 반응 및 동작해야하는지에 대한 기술.

기능성 / 완전성 / 일관성

[ 비기능적 요구사항 ]

시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항.

품질 속성에 관련하여 시스템이 갖춰야 할 사항 및 시스템이 준수해야 할 제한 조건에 관한 기술.

신뢰성 / 사용성 / 효율성 / 유지보수성 / 이식성 / 보안성 / 품질 관련 요구사항 / 제약사항

3) 요구사항 개발 단계 구성 (CMM Level 3 프로세스 영역)

도출 -> 분석 -> 명세 -> 확인

1. 요구사항 도출

소프트웨어가 해결해야 할 문제를 이해하고, 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구 사항을 구체적으로 표현하는 단계

도출 단계에서 이해관계자가 식별되고, 개발팀과 고객 사이의 관계가 형성되며 다양한 이해관계자와 효율적인 의사소통이 중요.

고객 분석, 조직 환경 분석, 후보 요구사항 분류, 후보 요구사항 정제, 요구사항 소스 관리.

인터뷰 / 브레인스토밍 / 델파이 기법 / 롤 플레잉 / 워크숍 / 설문 조사

2. 요구사항 분석

도출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계.

요구 사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위를 파악하며 소프트웨어가 환경과 어떻게 상호 작용하는지 이해하는 단계

주요 활동으로는 시스템 요구사항을 정제하여 소프트웨어 요구사항 분류, 후보 요구사항 모델링, 요구사항의 우선순위 부여, 해당 릴리즈에 수행할 요구사항 선정, 요구사항 협의

비용과 일정에 대한 제약설정, 타당성 조사, 요구사항 정의 문서화 수행.

요구사항 분류 -> 개념 모델링 생성 및 분석 -> 요구사항 할당 -> 요구사항 협상 -> 정형 분석

[ 자료흐름 지향 분석 ]

데이터 흐름도 및 자료사전으로부터 소프트웨어 구조를 유도하는 방법

[ 객체 지향 분석 ]

시스템의 기능과 데이터를 함께 분석하여 UML로 표준화함

청취 / 인터뷰와 질문 / 분석 /중재 / 관찰 / 작성 / 조직 / 모델 작성

3. 요구사항 명세

체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계

동의한 요구사항을 하나 이상의 형태로 저장하여 정형화된 요구사항을 생성하는 활동 수행.

주요 활동으로는 요구사항 명세 기준 정의, 요구사항 명세서 작성, 요구사항 추적 관련 정보 저장.

요구사항 명세서 산출

검증 항목 : 명확성 / 완전성 / 검증 가능성 / 일관성 / 수정 용이성 / 추적 가능성 / 개발 후 이용성

[ 비정형 명세 기법 ]

사용자의 요구를 표현할 때 자연어를 기반으로 서술.

사용자와 개발자의 이해가 용이.

명확성 및 검증에 문제.

[ 정형 명세 기법 ]

사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술.

Z-스키마, Petri Nets, 상태차트 활용.

표현이 간결하고 명확성 및 검증이 용이.

기법의 이해가 어려움.

4. 요구사항 확인 및 검증

분석가가 요구사항을 이해했는지 확인하고 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고 완전한지 검증하는 단계.

요구사항 명세서 검토, 요구사항 용어 검증, 요구사항 베이스라인 수립.

이해관계자들이 요구사항 문서 검토 및 요구사항 관리 툴을 이용하여 요구사항 정의 문서들에 대한 형상 관리 수행.

리소스가 요구사항에 할당되기 전에 문제를 파악하기 위한 검증 수행.

요구사항 목록 확인 -> 요구사항 정의서 작성 여부 확인 -> 비기능적 요구사항의 확인 -> 타 시스템 연계 및 인터페이스 요구사항 확인

요구사항 검토 / 정형기술 검토 활용 / 프로토타이핑 활용 / 모델 검증 / 테스트 케이스 및 인수 테스트 / CASE 도구 활용 / 베이스라인 / 요구사항 추적표

[ 정형 기술 검토 ]

- 동료 검토 : 2-3명이 진행하는 리뷰 형태. 이해관계자들이 결함 발견. (= 인스펙션)

- 워크 스루 : 오류를 조기 검출하는 데 목적. 사전 검토 후 짧은 회의를 통해 리뷰하고 오류를 검출, 문서화함. 비형식적.

- 인스펙션 : 저작자 외의 다른 전문가 또는 팀이 검사하여 오류 발견하는 공식적 검토 방식. 형식적

- 감사 : 규제, 표준, 계획, 절차, 가이드라인을 준수하고 있는지 독립적으로 평가. 소프트웨어 제공자, 소비자, 제3기관 수행.

- 관리 리뷰 : 진행 상황에 대한 전반적인 검토를 바탕으로 범위, 일정, 인력 등에 대한 통제 및 의사결정을 지원하는 리뷰.

- 기술 리뷰 : 대표 엔지니어의 주재. 관리자 참가 가능. 정의된 계획 및 명세를 준수하고 있는지 검토 수행.

[ 상세 정형 기술 검토 ]

관리 리뷰 / 기술 리뷰 / 인스펙션 / 워크 스루 / 감사

[ 요구사항 정의서 ]

ID / 이름 / 유형 / 품질 속성 / 우선순위 / 중요도 / 출처 / 관련 부서 / 전제 조건 / 내용 / 관련 요구사항 / 버전 / 수용 여부

3) 요구사항 관리 단계 구성 (CMM Level 2 프로세스 영역)

프로젝트 진행 과정에서 발생하는 요구사항의 변경에 대해 일치성과 무결성을 제공하기 위해 변경제어와 추적 등 일련의 관리를 수행하는 활동.

요구사항 변경요청서 / 요구사항 변경 승인서 / 요구사항 추적표 산출

협상 -> 기준선 설정 -> 변경관리 -> 확인 및 검증

형상통제 위원회(Configuration Control Board)

형상 관리에 대한 주요 방침을 정하고 산출물을 검토하며, 단계별 의사결정을 수행하는 조직.

분석 모델 검증 방법

1) 유스케이스 모델 검증

시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성 검증을 위해 액터, 유스케이스, 유스케이스 명세서 점검.

* 액터 : 시스템의 외부에 있고, 시스템과 상호 작용을 하는 사람 또는 시스템.

* 유스케이스 : 시스템이 액터에게 제공해야 하는 기능으로 시스템 요구사항이자, 사용자 입장에서 바라본 시스템의 기능.

2) 개념 수준의 분석 클래스 검증

시스템의 주요 도메인 개념을 분석 클래스로 도출하여 유스케이스 분석에 활용하므로, 개념 수준의 주요 분석 클래스를 적절히 도출하였는지, 관련 정보가 명확한지 점검.

주요 클래스 도출 여부, 도출된 클래스 이름과 속성의 적절성, 올바른 클래스들 간의 관계 여부 점검.

3) 분석 클래스 검증

유스케이스 실현에 필요한 분석 클래스 도출 확인.

유스케이스 별로 도출된 분석 클래스들이 스테레오 타입으로 표시되었는지 확인.

경계와 제어 클래스의 도출 여부 및 상세화 정도 확인.

클래스 간의 관계, 클래스 정보의 상세화 정도 확인.

분석 모델 검증 프로세스

1) 검토의견 컬럼 추가

분석 모델까지 요구사항 추적표를 작성하고 검토의견 컬럼 추가

2) 검토의견 작성

요구사항 목록을 참조하여 요구사항 ID와 요구사항명 입력

유스케이스 모델에 대한 검토의견 작성

개념 수준의 분석 클래스 모델에 대한 검토의견 작성

분석 클래스 모델에 대한 검토의견 작성

3) 검토의견 정제

요구사항 추적표에서 요구사항에 대한 검토의견 정제

누락된 유스케이스 모델/개념 수준 분석 클래스/분석 클래스가 존재하는 경우, 검토의견 추가

요구사항의 시스템화 타당성 분석

1) 검토

- 성능 및 용량 산정의 적정성

요구사항을 만족시키기 위한 분석 모델에 따라 시스템을 구현할 때 요구되는 시스템의 자원 식별.

- 시스템 간 상호 운용성

분석 모델을 이용해 보다 구체적으로 시스템 간 상호 정보 및 서비스가 교환 가능한지 검토

- IT 시장 성숙도 및 트렌드 부합성

분석 모델이 과거의 문제를 해결하고 최근 많이 사용되는 트렌드에 부합되는지 확인

- 기술적 위험 분석

분석 모델이 시스템의 기술 구조, 프레임워크, 사용되는 HW/SW와 부합되는지 확인.

2) 프로세스

타탕성 분석 결과 기록 -> 타당성 분석 결과의 이해관계자 검증 -> 타당성 분석 결과 확인 및 배포/공유

1) 개발 기술 환경 현행 시스템 분석

운영체제 현행 시스템 분석

① 운영체제란?

컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있도록 해주고, 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램.

사용자가 컴퓨터를 좀 더 쉽게 사용하기 위해 지원하는 소프트웨어.

② 운영체제 현행 시스템 분석 시 품질 측면과 지원 측면 등을 고려.

- 품질 측면 : 신뢰도 / 성능

- 지원 측면 : 기술 지원 / 주변 기기 / 구축비용

③ 운영체제 종류 및 특징

- PC : Windows (중/소규모 서버, 일반 PC 등 유지 및 관리 비용의 장점) / UNIX (대용량 처리 및 안정성 높은 엔터프라이즈급 서버) / Linux (중/대규모 서버 대상으로 높은 보안성을 제공. 하드웨어 및 소프트웨어 소유 비용이 적게 소요)

- Mobile : Android (리눅스 위에서 구동. 자바 및 코틀린으로 작성 가능. 런타임 라이브러리 제공) / IOS (스마트폰 및 태블릿 PC의 높은 보안성과 고성능 제공)

네트워크 현행 시스템 분석

① 네트워크란?

컴퓨터 장치들의 노드 간 연결을 사용하여 서로에게 데이터를 교환할 수 있도록 하는 기술. 데이터 링크는 광케이블과 같은 유선 매체 또는 와이파이와 같은 무선 매체를 통해 확립.

② OSI 7계층

네트워크 통신에서 생긴 여러 가지 충돌 문제를 완화하기 위해 국제 표준화 기구에서 제시한 네트워크 기본 모델.

③ 네트워크 현행 시스템 분석

현행 시스템이 구성된 네트워크 구조를 네트워크 구성도를 통해 분석함.

네트워크 구성도를 통해 서버 위치, 서버 간 연결 방식을 파악함.

백본망, 라우터, 스위치, 게이트웨이, 방화벽 등을 대상으로 분석.

물리적인 위치 관계를 파악하여 조직 내 보안 취약성 분석 및 대응 가능.

네트워크 장애 발생 추적 및 대응 등의 다양한 용도로 활용.

DBMS 현행 시스템 분석

① DBMS란?

데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능을 제공하는 응용 프로그램.

② DBMS 기능

중복제어 / 접근 통제 / 인터페이스 제공 / 관계 표현 / 샤딩 및 파티셔닝 / 무결성 제약 조건 / 백업 및 회복

③ 고려사항

- 성능 측면 : 가용성 / 성능 / 상호 호환성

- 지원 측면 : 기술 지원 / 구축 비용

미들웨어의 현행 시스템 분석
① 미들웨어란?

분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어.

운영체제와 소프트웨어 애플리케이션 사이에 위치.

② 웹 어플리케이션 서버 (WAS : Web Application Server)란?

서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 기종 시스템과의 애플리케이션 연동을 지원하는 서버.

③ 미들웨어의 현행 시스템 분석

- 성능 측면 : 가용성 / 성능

- 지원 측면 : 기술 지원 / 구축 비용

오픈 소스 사용 시 고려 사항

오픈 소스를 사용하는 경우에는 라이선스의 종류, 사용자 수, 기술의지속 가능성 등을 고려.

오픈 소스 소프트웨어의 전제 조건인 자유 배포, 소스 코드 공개, 파생작업 허용, 소스 코드 일관성 확보, 차별 금지, 라이선스 배포, 포괄적 허용 고려.

2) 개발 기술 환경 요구사항 파악

기술 환경 정의를 위한 자료 수집

수집 자료 목록 및 조사 항목 설정.

현행 시스템 담당자가 제공하는 자료와 인터뷰 기록을 분석.

조사 자료 분석 및 개발 기술 환경 결정

조사한 자료를 이용하여 운영체제, 데이터베이스, 웹 애플리케이션 서버 등 결정.

조사 자료 분석 시 각 항목별 고려 사항을 반영하여 개발 기술 환경을 결정.

요구사항 정의서, 목표 시스템 구성도 반영 및 검토

운영체제, 데이터베이스, 웹 애플리케이션 서버 등 시스템 용량 산정 결과를 요구사항 정의서, 목표소프트웨어 구성도, 목표 하드웨어 구성도에 반영함.

각 팀별로 작성된 산출물을 상호 검토하여 의견을 제시함.

다른 팀의 검토 의견을 반영하여 산출물을 수정하고 최종 완료함.

1) 현행 시스템 파악 개념

현행 시스템 파악이란?

현행 시스템이 어떤 하위 시스템으로 구성되어 있고, 제공 기능 및 연계 정보는 무엇이며 어떤 기술 요소를 사용하는지를 파악하는 활동.

사용하고 있는 소프트웨어 및 하드웨어는 무엇인지, 네트워크의 구성은 어떻게 되어 있는지 파악하는 활동.

2) 현행 시스템 파악 절차

1단계: 현행 시스템 구성/기능 및 인터페이스 파악

2단계: 현행 시스템 아키텍처 및 소프트웨어 구성 파악

3단계: 하드웨어 및 네트워크 구성 파악

3) 소프트웨어 아키텍처

소프트웨어 아키텍처란?

여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체.

소프트웨어 아키텍처 프레임워크란?

소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준.

[구성]

소프트웨어 아키텍처 4+1 뷰란?

고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법.

4개의 분리된 구조로 구성되는 아키텍처 개념을 제시하고, 이들 4개 구조가 서로 충돌되지 않는지, 시스템의 요구사항을 충족시키는지를 증명하기 위해 체크 방법으로 유스케이스 사용.

[구성_유논프구배]

소프트웨어 아키텍처 패턴이란?

소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식.

주어진 상황에서의 소프트웨어 아키텍처에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션.

① 소프트웨어 개발 시 상황별 소프트웨어 아키텍처 패턴을 수립 적용하여 고객과 의사소통을 통해 고객의 요구사항을 만족시키고, 소프트웨어 개발 생산성과 품질 확보 가능

② 개발에 대한 시행착오를 줄여 개발 시간을 단축하고, 높은 품질의 소프트웨어 생산 가능

③ 검증된 구조로 개발하기 때문에 소프트웨어 개발을 안정적으로 수행 가능

④ 시스템의 특성을 개발 전에 예측 가능

[패턴 유형]

소프트웨어 아키텍처 비용 평가 모델이란?
아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델.

4) 디자인 패턴

디자인 패턴이란?

소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴.

디자인 패턴을 참고하여 개발하면 개발의 효율성과 유지보수성, 운용성이 높아지며 프로그램의 최적화에 도움.

디자인 패턴 구성요소

디자인 패턴 유형

목적과 범위에 따라 구분되며 생성, 구조, 행위, 클래스, 객체 다섯개의 유형이 존재함.

목적에 따른 디자인 패턴 유형 => 생성 / 구조 / 행위

범위에 따른 디자인 패턴 유형 => 클래스 / 객체

디자인 패턴 종류

1. 생성 패턴

 - Builder

복잡한 인스턴스를 조립하여 만드는 구조로, 복합 객체를 생성할 때 객체를 생성하는 방법(과정)과 객체를 구현(표현)하는 방법을 분리함으로써 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있는 패턴.

생성과 표기를 분리해서 복잡한 객체를 생성.

 - Prototype

처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용하는 패턴으로, 생성할 객체의 원형을 제공하는 인스턴스에서 생성할 객체들의 타입이 결정되도록 설정하며 객체를 생성할 때 갖추어야 할 기본 형태가 있을 때 사용되는 패턴.

기존 객체를 복제함으로써 객체를 생성.

 - Factory Method

상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식으로, 상위 클래스에서는 인스턴스를 만드는 방법만 결정하고, 하위 클래스에서 그 데이터의 생성을 책임지고 조작하는 함수들을 오버라이딩하여 인터페이스와 실제 객체를 생성하는 클래스를 분리할 수 있는 특성을 갖는 패턴.

생성할 객체의 클래스를 국한하지 않고 객체를 생성.

 - Abstract Factory

구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴으로 이 패턴을 통해 생성된 클래스에서는 사용자에게 인터페이스를 제공하고, 구체적인 구현은 Con-create Product 클래스에서 이루어지는 특징을 갖는 패턴.

동일한 주제의 다른 팩토리를 묶음.

 - Singleton

전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 패턴.

한 클래스에 한 객체만 존재하도록 제한.

2. 구조 패턴

 - Bridge

기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상 계층을 분리하여 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 패턴.

구현뿐만 아니라 추상화된 부분까지 변경해야 하는 경우 활용.

 - Decorator

기존에 구현되어 있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴으로 기능 확장이 필요할 때 객체 간의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 해주어 상속의 대안으로 사용하는 패턴.

구현뿐만 아니라, 추상화된 부분까지 변경해야 하는 경우 활용.

 - Facade

복잡한 시스템에 대하여 단순한 인터페이스를 제공함으로써 사용자와 시스템 간 또는 여타 시스템과의 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게 하는 패턴으로 오류에 대해서 단위별로 확인할 수 있게 하며, 사용자의 측면에서 단순한 인터페이스 제공을 통해 접근성을 높일 수 있는 패턴.

통합된 인터페이스를 제공함.

 - Flyweight

다수의 객체로 생성될 경우 모두가 갖는 본질적인 요소를 클래스화하여 공유함으로써 메모리를 절약하고, 클래스의 경량화를 목적으로 하는 패턴.

여러 개의 가상 인스턴스를 제공하여 메모리를 절감함.

 - Proxy

실제 객체에 대한 대리 객체로 실체 객체에 대한 접근 이전에 필요한 행동을 취할 수 있게 만들며, 이 점을 이용해서 미리 할당하지 않아도 상관없는 것들을 실제 이용할 때 할당하게 하여 메모리 용량을 아낄 수 있으며, 실제 객체를 드러나지 않게 하여 정보은닉의 역할도 수행하는 패턴.

특정 객체로의 접근을 제어하기 위한 용도로 사용.

 - Composite

객체들의 관계를 트리 구조로 구성하여 부분 - 전체 계층을 표현하는 패턴으로 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 하는 패턴.

복합 객체와 단일 객체를 동일하게 취급함.

 - Adapter

기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 하는 인터페이스를 만드는 패턴으로 상속을 이용하는 클래스 패턴과 위임을 이용하는 인스턴스 패턴의 두 가지 형태로 사용되는 패턴.

인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록 타 클래스의 인터페이스를 기존 인터페이스에 덧씌움.

3. 행위 패턴

 - Mediator

객체 지향 설계에서 객체의 수가 너무 많아지면 서로 간 통신을 위해 복잡해져서 객체 지향에서 가장 중요한 느슨한 결합의 특성을 해칠 수 있기 때문에 이를 해결하는 방법으로 중간에 이를 통제하고 지시할 수 있는 역할을 하는 중재자를 두고, 중재자에게 모든 것을 요구하여 통신의 빈도수를 줄여 객체 지향의 목표를 달성하게 해주는 디자인 패턴.

상호 작용의 유연한 변경을 지원함.

 - Interpreter

언어의 다양한 해석, 구체적으로 구문을 나누고 그 분리된 구문의 해석을 맡는 클래스를 각각 작성하여 여러 형태의 언어 구문을 해석할 수 있게 만드는 패턴.

문법 자체를 캡슐화하여 사용함.

 - Iterator

컬렉션 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 방법을 제공하는 패턴.

내부구조를 노출하지 않고, 복잡 객체의 원소를 순차적으로 접근 가능하게 해주는 행위 패턴.

 - Template Method

어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴으로 일반적으로 상위 클래스에는 추상 메서드를 통해 기능의 골격을 제공하고, 하위 클래스의 메서드에는 세부 처리를 구체화하는 방식으로 사용하며 코드 양을 줄이고 유지보수를 용이하게 만드는 특징을 갖는 패턴.

상위 작업의 구조를 바꾸지 않으면서 서브 클래스로 작업의 일부분을 수행함.

 - Observer

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락이 가고 자동으로 내용이 갱신되는 방법으로 일대 다의 의존성을 가지며 상호 작용하는 객체 사이에서는 가능하면 느슨하게 결합하는 패턴.

객체의 상태 변화에 따라 다른 객체의 상태도 연동, 일대다 의존.

 - State

객체 상태를 캡슐화하여 클래스화함으로써 그것을 참조하게 하는 방식으로 상태에 따라 다르게 처리할 수 있도록 행위 내용을 변경하여, 변경 시 원시 코드의 수정을 최소화할 수 있고, 유지보수의 편의성도 갖는 디자인 패턴.

객체의 상태에 따라 행위 내용을 변경함.

 - Visitor

각 클래스 데이터 구조로부터 처리 기능을 분리하여 별도의 클래스를 만들어 놓고 해당 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업을 수행하도록 만드는 패턴으로, 객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 때 사용하는 디자인 패턴.

특정 구조를 이루는 복합 객체의 원소 특성에 따라 동작을 수행할 수 있도록 지원하는 행위.

 - Command

실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴으로 하나의 추상 클래스에 메서드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행되는 특징을 갖는 패턴.

요구사항을 객체로 캡슐화.

 - Strategy

알고리즘 군을 정의하고 같은 알고리즘을 각각 하나의 클래스로 캡슐화한 다음, 필요할 때 서로 교환해서 사용할 수 있게 하는 패턴으로, 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 패턴.

행위 객체를 클래스로 캡슐화해 동적으로 행위를 자유롭게 변환.

 - Memento

클래스 설계 관점에서 객체의 정보를 저장할 필요가 있을 때 적용하는 디자인 패턴으로 Undo 기능을 개발할 때 사용하는 패턴.

객체를 이전 상태로 복구시켜야하는 경우, 작업취소(Undo) 요청이 가능함.

 - Chain of Responsibility

정적으로 어떤 기능에 대한 처리의 연결이 하드코딩 되어 있을 때 기능 처리의 연결 변경이 불가능한데 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 패턴.

한 요청을 2개 이상의 객체에서 처리함.

5) 현행 시스템 분석서 작성 및 검토

현행 시스템 관련 자료 수집

수집 자료의 특성에 따라 3개의 팀을 구성함.

1. 정보시스템 구성/기능 및 인터페이스 자료 수집팀

- 정보시스템 구성도 / 정보시스템 기능 구성도 / 정보시스템 인터페이스 현황 취득

2. 현행 시스템 아키텍처 및 소프트웨어 자료 수집팀

- 현행 시스템 아키텍처 구성도 / 소프트웨어 구성도 취득

3. 하드웨어 및 네트워크 자료 수집팀

- 하드웨어 구성도 / 네트워크 구성도 취득

수집 자료의 분석

수집된 정보들을 취합/정제하고, 중복되거나 유효하지 않은 정보들은 삭제함.

불명확한 부분은 체크한 후 분석 및 설계 단계를 통해 구체적으로 조사함.

현행 시스템의 이슈 및 문제점을 파악함.

분석한 결과를 기반으로 산출물 작성

각 취득 자료를 분석한 결과를 기반으로 산출물 작성함.

현행 시스템의 이슈나 문제점을 산출물에 상세하게 포함하여 작성함.

산출물에 대한 검토 수행

팀별로 작성된 산출물을 상호 검토하여 의견을 제시함.

다른 팀의 검토의견을 반영하여 산출물을 수정하고 최종 완료함.

(1) 소프트웨어 생명주기 모델

소프트웨어 생명주기란?

시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차.

시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화한 것.

소프트웨어 생명주기 모델 프로세스

요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수

소프트웨어 생명주기 모델 종류

(2) 소프트웨어 개발 방법론

소프트웨어 개발 방법론이란?

소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법.

소프트웨어를 하나의 생명체로 간주하고 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론.

소프트웨어 개발 방법론 종류

애자일 방법론의 개념

절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론.

개발 기간이 짧고 신속하며, 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 받아서 유동적으로 개발 가능.

애자일 방법론의 등장 배경

1) 소프트웨어 개발 환경의 변화 : 소프트웨어 개발 트렌드가 모바일 환경으로 변화하였고, 시장 적시성과 잦은 배포의 중요성이 부각.

2) 기존 개발 방법론의 한계 : 전통적 방법론은 문서 및 절차 위주로 변화에 신속 대응이 어려움. 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성이 증가.

애자일 방법론의 유형

1) XP

 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론.

 1~3주의 반복 개발 주기.

 5가지 가치 (용기 / 단순성 / 의사소통 / 피드백 / 존중)

 12가지 기본원리 (짝 프로그래밍 / 공동 코드 소유 / 지속적인 통합 / 계획 세우기 / 작은 릴리즈 / 메타포어 / 간단한 디자인   / 테스트 기반 개발 / 리팩토링 / 40시간 작업 / 고객 상주 / 코드 표준)

2) 스크럼

  매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론.

  (백로그 / 스프린트 / 스크럼 미팅 / 스크럼 마스터 / 스프린트 회고 / 번 다운 차트)

3) 린

  도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론.

  (JIT_Just In Time / Kanban보드)

  7가지 원칙 (낭비제거 / 품질 내재화 / 지식 창출 / 늦은 확정 / 빠른 인도 / 사람 존중 / 전체 최적화)

애자일 방법론과 전통적 방법론

(3) 객체 지향 분석 방법론

객체 지향 분석이란?

사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의하여 모델링하는 기법.

객체 지향 분석 방법론의 종류

1) OOSE (Object Oriented Software Engineering)

  야콥슨 (Jacobson)

  유스케이스에 의한 접근 방법.

  분석, 설계, 구현 단계.

  기능적 요구사항 중심의 시스템

2) OMT (Object Modeling Technology)

  럼바우 (Rumbaugh)

  그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론.

  객체 모델링 -> 동적 모델링 -> 기능 모델링

3) OOD (Object Oriented Design)

  부치 (Booch)

  설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론.

  분석과 설계의 분리가 불가능.

  분석하는 데 이용된 객체 모델의 설계 시 적용.