1
Q
SW공학 개념
A
⦿ 특징 (비복유 무장복) - 비가시성, 복잡성, 유연성, 무형, 장수, 복제가능 ⦿ 위기 (신고생 일품) - 신뢰도 저하, 고비용, 생산성 저하, 일정지연, 품질저하 ⦿ SW공학정의 - 품질확보, 생산성향상을 위한 학문 ⦿ 목표 (고사효프생) - 고품질 소프트웨어 : IEEE 730 - 사용자 만족 향상 : 요구공학 - 효율적 프로젝트 관리 : PMO - SW 프로세스 개선 : CMMi - 생산성 향상 : Case Tool ⦿ 구성요소 (언기원도) - 언어, 기법, 원리, 도구 ⦿ SW위기 해결방안 (공표자품) - 공학적 접근 - 표준화 - 자동화 도구 활용 - 품질보증체계
2
Q
소프트웨어 공학 언어
A
- DFD(Data Flow Diagram)
- ERD(Entity Relationship Diagram)
- UML(Unified Modeling Language)
3
Q
소프트웨어 공학 기법
A
(요설구데객)
- 요구분석방법
- 설계방법
- 구조적 분석기법
- 데이터 흐름 중심
- 객체지향 분석기법
4
Q
소프트웨어 공학 원리
A
(단추정모일분)
- 단계적 상세화
- 추상화
- 정보은닉
- 모듈화
- 일바화
- 분할과 정복
5
Q
소프트웨어 공학 도구
A
- 통합 Case Tool
- 요구사항 자동화
- 테스트 자동화
6
Q
소프트웨어 위기 해결방안
A
(공표자품)
- 공학적 접근 : 구조적, 정보공학, 객체지향, CBD, 프로젝트 관리
- 표준화 : 역공학, 재공학, 데이터표준화, 재사용성 체계화
- 자동화 도구 활용 : CASE, Repository, 형상관리 도구
- 품질보증체계 : ISO품질보증체계, CMMi/SPICE, 정보시스템 감리
7
Q
모듈화
A
⦿ 정의 - 기능 단위의 루틴으로 분해 및 추상화를 통한 설계 기법 ⦿ 원리(정자독분비) - 정보은닉 - 자료추상화 - 독립성 - 분할과 정복 - 비용과 모듈의 관계 ⦿ 특성 - 비즈니스 확장성 : 민첩한 대응 - 관리 효율성 : 유지보수 기간 단축 - 기술적 재사용 : 모듈의 컴포넌트화 ⦿ 장점 - 유지보수 편리 - 생산성 향상 - 가독성 향상 - 오류 최소화 ⦿ 기법의 종류 - 설계기법 : 모듈, 컴포넌트, 서비스 - 구현기법 : Macro, Function, inLine ⦿ 응집도 - 우연, 논리, 일시, 절차, 통신, 순차, 기능 ⦿ 결합도 - 내용, 공통, 외부, 제어, 스템프, 자료
8
Q
응집도 (기능)
A
- 하나의 모듈이 하나의 기능만 수행
9
Q
응집도 (순차)
A
- 모듈내의 동일한 요소에 값을 출력하고 다시 입력 값으로 사용
A = update();
Delete(A);
10
Q
응집도 (통신)
A
- 모듈 내 요소들이 동일한 자료를 이용하여 서로 다른 기능을 수행
DB에 저장된 name
print(name);
select(name);
11
Q
응집도 (절차)
A
- 모듈 내 요소간에 실행되어야 하는 순서 존재
Init();
Listen()
Request()
12
Q
응집도 (일시)
A
- 변수 초기화 처럼 1회 실행되는 요소. 요소들 동시 수행
Init();
Memset();
13
Q
응집도 (논리)
A
- 논리적으로 유사기능을 수행 하나 밀접한 관련은 없음 Switch(1); Case : 1 Case : 2 Case : 3
14
Q
응집도 (우연)
A
- 모듈내 요소들의 연관관계가 거의 없음
15
Q
결합도 (내용)
A
- 다른 모듈의 내부 데이터를 직접 수정하는 경우
void main() {
Go To LOCAL;
}
void local(int x, int y) {
LOCAL;
}
16
Q
결합도 (공통)
A
- 전역변수 등 모듈간 동일자료영역 공통조회
Static in A;
void main() {
A = i;
}
void local() {
A = 2;
}
17
Q
결합도 (외부)
A
- config 등 모듈간 공통적인 SW외부 환경과 정의 공유
void main() {
#include config.dat;
}
void local() {
#include config.dat;
}
18
Q
결합도 (제어)
A
- 제어문을 이용 타 모듈의 내부 제어
void main() {
local(1);
}
void local(int isExec) {
if(isExec) { }
else { }
}
19
Q
결합도 (스템프)
A
- 모듈 간 매개변수로 구조체를 지정
Struct 좌표 (int x, int y);
void main() {
local(좌표 xy);
}
20
Q
결합도 (자료)
A
- 모듈간 매개변수로 통신
void main() {
Local(int x, int y);
}
21
Q
객체지향 설계 원리
A
⦿ 객체의 구성요소 : 객체, 클래스, 메소드, 메시지
⦿ 객체지향 설계 원리 : 캡슐화, 추상화, 다형성, 정보은닉, 상속성
22
Q
객체지향 설계 5원칙
A
- SRP(Single Responsiliity Principle) : 단일 책임의 원칙
- OCP(Open-Closed Principle) : 개방-폐쇄 원칙
- LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
- ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
- DIP(Dependency Inversion Principle) : 의존관계 역전 원칙
23
Q
SRP (Single Responsibility Principle)
A
⦿ 정의 - 클래스는 하나의 기능만 가짐 ⦿ 특징 - 클래스 변경 이유는 오직 하나, 변경 연쇄작용에서 자유, 가독성/유지보수성 향상 ⦿ SRP원칙 적용 기법 - Extract Class, Move Method, Move Field ⦿ 사례 - 비즈니스 로직과 DB처리 메소드 분리
24
Q
OCP (Open Close Principle)
A
⦿ 정의 - 확장에는 열려있고, 변경에는 닫혀 있어야 함 ⦿ 메커니즘 - 추상화(공통), 캡슐화 ⦿ 적용절차 - 1단계(Class구분) - 2단계(I/F정의) - 3단계(코드작성) ⦿ 사례 - 인터페이스 추가
25
LSP (Liskov Substitution Principle)
```
⦿ 정의
- 자식 타입들은 부모 들이 사용되는 곳에 대체 가능
⦿ 메커니즘
- OCP, 다형성, 상속성
⦿ 사례
- Storage 인터페이스를 구현한 하위 클래스 FileStorage와 DBStorage 클래스는 Client의 write()인자인 Storage를 대체 가능
```
26
ISP (Interface Segregation Principle)
⦿ 정의 : 자신과 관련 없는 interface의 변화로 인해 영향받지 않는 원칙
⦿ 특징 : 여러개의 구체적 인터페이스 구현, 인터페이스 단일 책임
⦿ 적용방법 : 클래스 인터페이스를 통한 분리(상속), 객체 인터페이스를 통한 분리(위임)
⦿ 사례
- Animal interface를 bird interface와 reptile interface, fish interface로 나누어서 각각의 움직임을 나타내도록 분리
- frog class는 자신에게 맞는 reptile 과 fish를 implements하여 run()과 swim()만 구현
27
DIP (Dependency Inversion Principle)
⦿ 정의 : 구상 클래스에 의존하지 않도록 하는 원칙
| ⦿ 원리 : 구성(레이어), 의존(추상레벨), 추상화(공통부분)
28
추상 클래스
```
⦿ 개념 : 하나 이상의 추상 메소드와 일반 필드 및 일반 메소드를 포함하는 클래스
⦿ 키워드 : abstract class
⦿ 템플릿 : 일부 구현된 내용을 포함하는 미완성 템플릿
⦿ 목적 : 추상 메소드 기능 구현 및 재사용
⦿ 하위클래스 : Extends, 다중상속 불가
⦿ 추상화수준 : 클래스에 비해 높고, 인터페이스에 비해 낮음
⦿ 디자인패턴 : Template Method
⦿ 공통 : New 연산자를 사용한 인스턴스 생성 불가(하위 클래스에 위임)
```
29
인터페이스
```
⦿ 개념 : 추상 메소드와 상수(static final 필드)만을 포함하는 추상 클래스
⦿ 키워드 : interface
⦿ 템플릿 : 구현된 내용이 없이 밑그림만 그려지는 기본 템플릿
⦿ 목적 : 기능을 공통 타입으로 그룹핑
⦿ 하위클래스 : implements 후 추상 매소드 재정의, 다중상속 가능
⦿ 추상화수준 : 가장높은수준
⦿ 디자인패턴 : Strategy
⦿ 공통 : 유연한 설계
```
30
묵시적 형변환
```
⦿ 변환시점 : 하위타입을 상위타입으로 대체시
⦿ 목적 : 범용성, 확장성 보장
⦿ 연산자 : 불필요
⦿ 용도 : 높은 추상화, 프레임워크 개발시
⦿ 공통 : 상위, 하위 타입 관계가 아닌경우 Casting Exception 발생
```
31
명시적 형변환
```
⦿ 변환시점 : 상위타입을 하위타입으로 대체시
⦿ 목적 : 기능성 측면 확장
⦿ 연산자 : 필요
⦿ 용도 : 구체적 기능 클래스 사용시
⦿ 공통 : instanceof로 변환 가능 타입인지 확인 필요
```
32
SDLC
⦿ 필요성 : 체계적 접근, SW위기 극복
⦿ 정의 : SW개발 전 과정을 하나의 생명주기로 보고, 단계별로 체계화한 모델
⦿ 등장배경 : SW위기 극복, 고품질, 생산성 향상, 비 가시성 보완
⦿ 구성 : 타당성 검토, 분석, 설계, 개발, 테스트, 유지보수, 폐기
⦿ 종류 : 폭포수, Prototyping, 나선형, 반복/점증적, RAD/RUP, Clean Room
33
폭포수 모델
⦿ 개념도 : 개발계획, 요구분석, 기본설계, 상세설계, 코딩, 단위시험, 통합시험, 인수시험, 운영 및 유지보수
⦿ 장점 : 사례 풍부, 이해 용이, 관리 용이, 다양한 산출물
⦿ 단점 : 초기 요구 정의 어려움, 전 단계 종결 필수, 반복 불가능, 요구 변경 어려움
34
프로토타이핑 모델
⦿ 개념도 : 요구분석, Prototype개발/개선, Prototype 검토/평가, 상세개발, 설치
⦿ 장점 : 요구 도출 용이, 시스템 이해 및 품질 향상, 의사소통 원활, 타당성 검증
⦿ 단점 : 완제품 오인, 기대 심리 유발, 시제품 포기 시 비경제적, 중간 단계 산출물 문서화 어려움
35
나선형 모델
⦿ 개념도 : 계획 및 정의, 위험분석, 개발, 고객의 평가
⦿ 장점 : 정확한 사용자 요구 파악, 위험 최소화, 대규모 시스템에 적합, 완전성 부여, 단계적 평가 및 문서화 충실, 품질향상 및 유지보수성 향상
⦿ 단점 : 장기화, 관리 복잡, 원래 내용 왜곡 우려, 위험관리 해결책이 없으면 더 위험
36
반복적 모델
⦿ 증분형(incremental) : 제품 일부분 반복적 개발 대상 범위 확대(폭포수)
| ⦿ 진화형(Evolutional) : 핵심 부분 개발 후 개선 발전(프로토타이핑)
37
RAD 모델
⦿ 개념도 : JRP(비즈니스/데이터/프로세스 모델링), JAD(Prototype 개발/수정/보완 반복), Cutover
⦿ RAD기반 Agile 방법론 : XP, SCRUM, RUP, Crystal, DSDM, Lean
38
Clean Room 모델
```
⦿ 정의 : 통계적 품질관리 기법을 이용한 이론 및 팀 기반 SDLC
⦿ 특징 : 명세화, 증분, 제어, 정적점검, 통계
⦿ 프로세스
1) 요구분석
2) 기능명세, 시나리오 기술
3) 순차적 기능 추가 (incremental) 계획서 작성
4) 점진적 개발 (기능, 설계 점증)
5) 테스트 케이스 작성 진행
⦿ 점증방법
- 박스구조분석 : 설계명세 검증
- 함수등가성 : 상세화 검증
- 통계적테스트 : 입/출력 과정
⦿ 박스구조 분석
- 블랙박스 : 추상적 블랙박스
- 상태박스 : 블랙박스에 내부상태 추가
- 클리어박스 : 상태박스에 제어흐름 추가
⦿ 함수 등가성
- 원래의 명세와 등가임을 판정하는 기준
- 순차, 분기, 선택, 반복에 대한 함수적 등가성 설계자가 검토 및 검증
```
39
글로벌 소프트웨어 개발주기/테스트
- G11n(Globalization) : 제품 현지화 기반 구축 절차
- I18n(Internationalization) : 언어/문화권 구현 기술적 절차
- L10n(Localication) : 언어/문화권에 적합하도록 변형
- TVT(Translation Verification Test) : 번역 검증 테스트
- GVT(Globalization Verification Test) : 글로벌화 검증 테스트
40
반복수행평가서 목차
```
⦿ 반복 수행 계획서의 목차
1. 목적 및 범위
2. 반복 회차의 일정
3. 구축 범위 및 개발 계획
4. 테스트 및 평가 방안
5. 전개 방안
⦿ 반복 수행 평가서의 목차
1. 평가 일정
2. 평가 대상
3. 평가 항목
4. 평가 기준
5. 평가 방법
6. 평가 결과
```
41
정보공학개발 방법론
```
⦿ 정의 : 데이터 중심 전사적 관점의 절차적 개발방법론
⦿ 단계
- ISP(Information Strategy Planning)
- BAA(Business Area Analysis)
- BSD(Business System Design)
- BSC(Business System Construction)
```
42
ISP 산출물
(경업벤핵시)
- 경영/정보 환경 분석
- 업무 프로세스/시스템 분석
- 벤치마킹/GAP 분석
- 핵심 비즈니스/아키텍처 개발
- 시스템 구축 계획 및 실행
43
BAA 산출물
(데분의매)
- 데이터 모델 다이어그램(ERD)
- 프로세스 분할 다이어그램(트리)
- 프로세스 의존 다이어그램(의존)
- 프로세스/데이터 매트릭스(CRUD)
44
BSD 산출물
(엔분액의데결대자)
- 엔티티-관계 다이어그램(함수적관계)
- 분할 다이어그램(기능, 프로세스, 프로시저 분할)
- 액션 다이어그램(CASE Tool)
- 의존 다이어그램(분할 다이어그램 약점 보완)
- 데이터 흐름도(프로시저 입출력)
- 결정 트리(로직 분기조건)
- 대화 구조(계층적, 수평적)
- 자료 구조(특정 DBMS)
45
BSC 산출물
(데물분)
- 데이터 사용 분석 (부하)
- 물리적 DB 설계 (성능)
- 분산 분석 (데이터 매트릭스)
46
객체지향 개발방법론
⦿ 정의 : 실세계의 개체(Entity)를 속성(Attribute)과 메소드(Method)가 결합된 형태의 객체(Object)로 표현하는 개념
⦿ 특성 : 재사용성, 이해성, 일관성, 추적성, 적합성, 유지보수성
⦿ 구성 : 상위 클래스, 클래스, 객체, 속성, 메소드
⦿ 원리 : 캡슐화(관련함수), 추상화(공통성질), 다형성(Overloading/Overriding), 정보은닉(private/protected), 상속성(단일/다중/반복)
⦿ 절차 (요 객동기 시객구 테패프)
- 요건정의(업무요건정의)
- 객체지향분석(객체모델링, 동적모델링, 기능모델링)
- 객체지향설계/구현(시스템설계, 객체설계, 구현)
- 테스트/배포(테스트, 패키지, 프로젝트 평가)
⦿ 종류 : OOSE(Usecase기반), OMT(객체, 시스템, 오브젝트, 구현의 4단계), OOD(설계 문서화 강조)
47
화이트박스 재사용, 블랙박스 재사용, 위임
```
⦿ 화이트박스 재사용
○ 개념 : 클래스 상속에 의한 재사용
○ 특징 : 컴파일 시점에 정의, 언어에서 직접 지원
○ 패턴 : Factory Method, Adapter(Class), Interpreter, Template Method
⦿ 블랙박스 재사용
○ 개념 : 객체 합성에 의한 재사용
○ 특징 : 런타임에 동적 정의
○ 패턴 : Abstract Factory, Builder, Prototype, Singleton, Adapter(Object), Composite, Decorator
⦿ 위임
○ 개념 : 연산의 처리를 위임자에게 보냄
○ 특징 : 런타임 행동 복합, 복합 방식 변경
○ 패턴 : State, Strategy, Visitor, Mediator, Chain of Responsibility, Bridge
```
48
오버라이딩(Overriding)
```
⦿ 개념 : 하위 클래스에서 상위 클래스의 메소드 재정의
⦿ 메소드 이름 : 같아야 함
⦿ 파라미터 개수 자료형 : 같아야 함
⦿ 리턴타임 : 같아야 함
⦿ 상속 : 상위 클래스에 메소드 존재
```
49
오버로딩(Overloading)
```
⦿ 개념 : 같은 이름의 메소드 여러개 정의
⦿ 메소드 이름 : 같아야함
⦿ 파라미터 개수 자료형 : 달라야함, 같을 경우 자료형이 달라야함
⦿ 리턴타임 : 상관없음
⦿ 상속 : 상위 클래스에 같은 이름의 메소드 없어야 함
```
50
CBD(Component Based Development)
⦿ 정의 : 컴포넌트를 생성 후 조립하여 SW를 개발하는 개발방법론
⦿ 특징 : 유용성, 확장성, 유지보수성, 재사용성
⦿ 개발 프로세스(분설추설구인형검, 요영기조응)
- CD : 도메인 분석, 도메인 설계, 컴포넌트 추출, 컴포넌트 설계, 컴포넌트 구현, 컴포넌트 인증, 형상관리, 컴포넌트 검색
- CBD : 요구사항 정의, 영역 분석, 컴포넌트 기반설계, 컴포넌트 조립, 응용시스템
⦿ 종류 : RUP, 마르미3/4
51
CBD 단계별 산출물
```
⦿ 요구파악
- 요구사항 이해 : 요구사항 기술서, 용어사전, 개념모델
- 요구사항 정의 : 유스케이스 모델
⦿ 분석 및 설계
- 요구사항 분석 : 객체모델, UI설계서
- 아키텍처 정의 : 아키텍처 기술서
- 컴포넌트 설계 : 인터페이스 명세서, 컴포넌트 명세서/설계서
- 데이터베이스 설계 : 데이터베이스 설계서
⦿ 구현
- 개발표준 정의 : 명명규칙, 코딩지침
- 코드 구현 : 플랫폼 종속적 코드
⦿ 테스트
- 테스트 계획 : 테스트 계획서
- 테스트 수행 및 보고 : 컴포넌트/통합/인수 테스트 보고서
```
52
CBD 컴포넌트 추출 방법
○ UseCase 시나리오 : include(반복), extend(조건)
○ 설계단계 UI : 공통 UI, 공통 UI컨트롤
○ 전문가 판단 : 전문가 경험
53
RUP (Rational Unified Process)
```
⦿ 정의
- 작업과 책임을 할당하기 위한 규칙이 제시된 객체지향 개발 방법론
⦿ 특징
- Use-Case Driven
- Architecture Centric
- 반복/점증적 프로세스
⦿ 공정구조
- 수평축 : 도입, 정련, 구축, 전이
- 수직축 : Business Modeling, Requirements, Analysis/Design, Implementation, Testing, Deployment, Change Management, Project Management, Environment, Iterations
⦿ RUP모델 (공작활산)
- 공정, 작업자, 활동, 산출물
⦿ 산출물
- 비즈니스 모델
- 도메인 모델
- 유즈케이스 모델
- 분석 모델
- 설계 모델
- 프로세스 모델
- 구현 모델
- 테스팅 모델
⦿ 6 Best Practice (반요컴 소지변)
- 반복적 개발
- 요구사항 관리
- 컴포넌트 기반 구조
- 소프트웨어 시각화
- 지속적 품질 확인
- 변화 통제
```
54
마르미III
⦿ 정의 : 작업과 작업 수행에 필요한 기법 및 작업별 산출물을 정의하고, 작업에 따른 상세한 개발 절차와 지침을 제공하는 한국형 CBD 방법론
⦿ 발전단계
- 마르미 ('94.10 ~' 97.09) : 구조적/정보공학 (ISO12207 수용)
- 마르미2 ('95.11 ~ '98.10) : 객체지향 (UML/반복적,점진적/위험관리)
- 마르미3 ('99.07 ~ '01.06) : 컴포넌트 (EJB기반, 아키텍처 중심)
- 마르미4 ('01.07 ~ '03.06) : 컴포넌트 (COM+/CORBA, 품질관리)
⦿ 개발단계 (요아점인)
- 요구분석/계획단계
- 아키텍처단계
- 점진적개발단계
- 인도단계
55
Agile 방법론
```
⦿ 정의
- 절차 보다는 사람 중심, 변화에 유연하고 신속하게 적응, 시스템 개발 방법론
⦿ 애자일 선언 (개변동고)
- 개인과의 상호작원
- 변화에 대응
- 동작하는 소프트웨어
- 고객중심
⦿ 등장배경
- SW개발 환경 변화, 기존 개발 방법론의 한계
⦿ 특징
- 가변적 요구 대응
- 고객만족
- 개발자 동기 부여
- PM의 역할 변화
- Sweet Spots
- 중소형 아키텍처
⦿ 주요 테크닉
- Unit Test
- Coding Standard
- Continuous Integration
- Refactoring
- TDD
- Pair Programming
```
56
XP (eXtreme Programming)
```
⦿ 정의
- 의사소통 개선, 즉각적인 피드백, 단순하게 코딩, SW품질을 높이기 위한 방법론
⦿ 특징
- 신속한 피드백, 점진적 수정, 변화의 인정, 고품질 작업
⦿ 핵심가치
- 용기, 단순성, 의사소통, 피드백, 존중
⦿ 프로세스
- User Stories
- Architectural Spike
- Release Planning(Spike)
- Iteration
- Acceptance Tests
- Small Release
⦿ 12가지 Practice (개관구환)
- 개발원리(짝프로그래밍, 공동책임, 지속적 통합)
- 관리원리(Planning Game, Small Release, Metaphor)
- 구현원리(간략한 디자인, TDD, 리팩토링)
- 환경요소(주40시간 작업, 고객상주, 코드표준)
```
57
SCRUM
```
⦿ 정의
- 작은 개발팀, 짧은 개발주기, 팀의 집중력과 생산성을 유지시켜 점진적으로 소프트웨어를 산출하는 Agile 개발 방법론
⦿ 가치
- 확약, 전념, 숨기지 않음, 존중, 용기
⦿ 구성요소
- 기간 : 스프린트(30일)
- 미팅 : 일일 스크럼(15분), 스프린트 계획, 스프린트 리뷰, 스프린트 완료 회고
- 산출물 : 제품 백로그, 스프린트 백로그, 소멸 차트
```
58
TDD (Test Driven Development)
```
⦿ 정의
- 작동하는 깔끔한 코드를 목표로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 소프트웨어를 구현하는 방법
⦿ 특징
- 독립적 테스트 가능 구조 설계
- 테스트 커버리지 확보
- 견고성 보장
- 기능에 집중
- Clean code that works
⦿ 사이클 (니테리코)
- Need, Test, Refactoring, Code
⦿ 패턴 : 빨간막대, 초록막대, xUnit, 디자인 패턴
⦿ 장애요소 제거방안
- 요구변경 : 요구공학, 형상관리
- 테스트케이스 : 테스트전문가 활용
- Unit 테스트 : 자동화툴 활용
- 리팩토링 : Unit 테스트
⦿ 고려요소
- TDD개발방법 숙지, 자동화된 프로세스, 방법론적 접근
⦿ 활용방안
- PoC, Prototyping, Pair Programming
```
59
KANBAN
```
⦿ 정의 : 적시개발을 지원하는 매우 적은 규칙을 가지고 있는 Agile 방법론
⦿ 규칙
- 워크플로우 가시화
- WIP 제한
- 플로우 최적화
⦿ 구성 (백선진완배서)
- 백로그, 선택됨, 개발(진행중, 완료), 배포, 서비스 중
```
60
CI (Continuous Integration)
```
⦿ 정의
- 여러명으로 구성된 팀이 작업한 것을 자주 통합하는 것을 가리키는 SW개발 프렉티스
⦿ 효과
- 에러 조기 발견
- 배포 용이성 확보
- 가시적 관리
- 자동화
⦿ 특징
- 소스코드 일관성 유지
- 소스코드 자동 빌드, 빌드 시 자동 테스트, 코드 무결성 유지
⦿ 구성요소
- 버전관리 저장소
- CI 통합서버
- 빌드 스크립트
- Project Management Tool
- 테스트 자동화
⦿ 프로세스
1) 개발자
- Checkout or Update
- 개발, 빌드, 테스트
- 코드 인스펙션, 코드 저장
2) 지속적 통합
- 체크아웃, 컴파일, 배포
- 테스트 수행, 커버리지 분석
- 코드 인스펙션, 소스 태깅
- 결과 분석
⦿ 실천사항
- 단일소스 래파지토리 유지
- 빌드/배포 자동화
- 셀프 테스팅 빌드
- 매일 커밋
- 모든 커밋은 메인에서 라인 빌드
- 빠른 빌드 유지
- 운영환경과 동일한 환경
- 쉬운 최신 실행 본 접근
- 모든 사람에게 알림
⦿ Tools
- Ant, Maven, JUnit, TestNG
- Selenium, Hudson
- CruiseControl, CheckStyle
- PMD, JDepent, FindBugs
⦿ 고려사항
- 능력신뢰, 자생력, 최초목표 유지
```
61
DevOps
```
⦿ 정의
- 개발조직과 운영조직의 프로세스 통합으로 빠른 개발과 배포를 수행하여 사용자 환경에 민첩하게 대응하는 방법론 또는 문화
⦿ 효과
- 빠른 출시, 빠른 장애대응, 생산성 향상, 인프라 효율화
⦿ 구성요소
- 품질 : 품질기준, 테스트자동화
- 프로세스 : 사이클타임 축소, 완료시점 범위 확장, 지속적 출시, 릴리즈와 배포의 분리
- 도구 : 지속적 통합, 어플리케이션 릴리즈, 프로비저닝
```
62
AOP
```
⦿ 정의
- 핵심 관심사에 대한 관점과 횡단 관심사에 대한 관점들로 프로그램을 분해하여 Weaving을 통해 프로그램을 구현하는 기법
⦿ 특징
- 모듈화, 캡슐화, 단순화
⦿ 구성효소
- 핵심관심
- 횡단관심
- Joint Point(횡단 관심 실행 위치)
- Point Cut(Joint Point 선택)
- Advice(Joint Point에 삽입되는 동작)
- Aspect(Point cut과 Advice를 합쳐 놓은 코드)
- Weaving(Joint Point에 Advice삽입)
⦿ Advice : Around, Before, After, Throws, Advisor
```
63
도메인 공학
```
⦿ 정의
- 도메인 분석, 재사용 가능 컴포넌트 식별, 아키텍처 개발, 재사용 가능 Asset 보급하는 공학
⦿ 목적
- Core Asset개발, 재사용 SW관리
⦿ 특징
- CBD기반, Product Line, 해당 도메인(특정분야) 재사용
⦿ 구분
- Domain Engineering, Application Engineering
⦿ 절차
- 도메인정의(명세서)
- 도메인모델링(모델)
- 도메인설계(아키텍처)
- 도메인구현(컴포넌트)
⦿ 기법
- SCV(Scope, Commonality, Variability)
- FODA(Feature Oriented Domain Analysis)
- ODM(Organization Domain Modeling)
- FAST
```
64
Product Line
```
⦿ 정의
- 도메인의 공통요구사항을 추출, 추상화하여 Core Asset 컴포넌트로 개발, 이를 Plug & Play 형태로 조립하여 Product를 만드는 개발 방법론
⦿ 등장배경
- Time to Market
- 체계적 재사용
- 품질향상
- Mass customization
⦿ 특징
- CBD사용
- 개발방법융합
- 도메인공학(SCV)
- 조립 프레임워크 제공
⦿ 구성
- Core Asset Development
- Plug & Play
- Product Development
- Management(조직적, 기술적)
⦿ 단계별 활동
- 도메인공학 : 제품계열 계획, 제품 패밀리 분석, Core Asset 개발
- 어플리케이션 공학 : 요구정의, 어플리케이션 개발, 테스트
⦿ 방법
1) Proactive 방법
- Core Asset을 먼저 개발, 초기 투자와 선행 지식 필요
- 범위 선정을 제일 먼저 (Develop the scope first)
- 새로운 제품 개발 시 코드의 개발 최소화
2) Reactive 방법
- 하나 혹은 여러 개의 Product로부터 Core Asset 및 다른 제품을 도출 (비용저렴, Reengineering 기법 사용)
- Product Line 기술을 처음 도입하는 경우
3) Extract 방법
- 기개발된 시스템 또는 Product에서 공통점과 차이점을 분석/추출하여 하나의 SW를 개발하는 방식
4) Incremental 방법
- Proactive나 Reactive를 사용하지만, 초기부터 제품개발과정중에 계속해서 Core Asset을 개발하는 방식
- Core Asset Base로부터 제품과 추가 Core Asset 반복 개발
⦿ 접근전략
- 타당성조사
- PLE적용가능 개발방법론 선정
- PLE 프로토타이핑 실시
- PLE 접근방법 결정(Forward, Reverse)
- 프로젝트 관리 및 품질 보증 활동 강화
```
65
SSPL
```
⦿ 정의
- 제조/서비스 제품 개발 프로세스와 소프트웨어 개발 프로세스를 융 복합시킨 혁신적인 패러다임
⦿ 4대 역량(대통스프)
- 대량 맞춤 생산 역량
- 통합 플랫폼 역량
- SW와 System의 융합 역량
- 프로세스 역량
⦿ 기술 (전기개자)
- 전략 및 통합(표준화, 맞춤화)
- 기획(스코핑, 기술예측)
- 개발(도메인 요구 공학, 아키텍처 기술, 구현 기술, 검증/시험기술, 어플리케이션 공학기술, 자산 마이닝 기술, 개발 관리 기술)
- 자산(플랫폼구축기술, 평가기술)
⦿ 프로세스
- 제품군 정의
- 플랫폼 개발
- 자산 구축
- 개별 제품 생산
- 제품 개량
⦿ 추진전략 : SSPL확산을 위한 생태계조성, 원천기술 R&D, SSPL 맞춤형 인력 육성, 소프트웨어 및 시스템 공학 성숙도 향상, SSPL 국제표준 선도 전략
```
66
FORM (Feature-Oriented Reuse Method)
⦿ 정의 : 요구공학 중심의 Feature 모델 사용에 초점을 둔 FODA를 확장하여 적용한 재사용 기법
⦿ 구성요소 : 핵심원리(휘처, 휘처모델, 휘처모델링), 휘처유형(필수, 선택, 택일), 휘처범주(능력계층, 운영환경, 도메인기술, 구현기술)
⦿ 절차 : Domain Engineering, Application Engineering
67
테일러링
```
⦿ 정의
- 기 정의 된 개발방법론의 절차/기법/산출물 등을 수정하여 적용하는 활동
⦿ 절차 (특생베 전실 딕교)
1) 관리/응용/아키텍처 측면의 프로젝트 특성 파악
2) SW 생명주기 모형 선정
3) Baseline 방법론 선정
4) Tailoring 전략 수립
5) Tailoring 실시 : 추가/삭제/수정 활동
6) Process Dictionary 작성 (Tailoring 근거 기록)
7) Tailored Process 교육
⦿ Tailoring 기법 (스프멤메)
- Scale Tailoring : 기간, 범위, 인원
- Process Tailoring : 프로세스
- Members Tailoring : 구성원 성숙도
- Methodology Tailoring : 방법론 병합
⦿ 주요산출물 (절방산기도 방관용)
- 절차 정의서
- 방법 기술서
- 산출물 정의서
- 기법 기술서
- 도구 기술서
- 방법론 설명서
- 관리 기술서
- 용어 정의서
```
68
SW요구공학
```
⦿ 정의
- 요구관리의 제반 활동에 대한 체계적인 검증 및 관리를 위한 공학적 활동
⦿ 목적
- 의사소통, 비용절감, 프로세스 개선, PM에 필수
⦿ 프로세스(추분명검변)
- 추출(후보)
- 분석(협의)
- 명세(정형)
- 검증(베이스라인)
- 변경관리(일관성)
⦿ 주요기법
1) 추출(롤인 설질 브워프 유)
- 인터뷰, 롤플레잉
- 설문, 질문
- 브레인스토밍, 워크샵, 프로토타이핑
- 유스케이스
2) 분석
- Use Case Modeling
- Prototyping
- Data Modeling
3) 명세
- 정형 명세, 비정형 명세
4) 검증
- Review
- Inspection
- Walk-Through
- Model Checking
5) 변경관리
- 협상, 베이스라인, 변경관리, 추적
```
69
페르소나
```
⦿ 정의
- 목표 인구 집단안에 있는 다양한 사용자 유형들을 대표하는 가상의 인물
⦿ 구성
- 행동예측
- 개성부여
- 인물묘사
- 배경환경설명
- 이름
- 목표
- 불안감
- 니즈
⦿ 절차 (가리실 다재)
- 가상화(메타포)
- 리서치(정성, 정량)
- 실체화(신뢰성)
- 다양한 요구사항(요구고려)
- 재구성(오염제거)
⦿ 활용
- 의사소통, 관점유지, 요구분석, 개발
```
70
ALM (Application Life Cycle Management)
```
⦿ 정의
- 소프트웨어 개발 전과정을 체계적으로 통합하고 시각화해 관리하기 위한 접근방법
⦿ 특징
- 유기적 통합
- 이슈기반통제
- 개발 방법론과 통합
- 프로세스 자동화
⦿ 기능구성 (이개소빌)
1) 이슈관리
- 일정관리, 우선순위 관리, 위험도 관리, 작업추적
2) 개발환경
- 표준 개발 환경, 표준 빌드 환경, 테스트 환경, 코딩 규칙 검사, 테스트 커러리지 검사
3) 소스 관리 시스템
- 소스 공유, 변경내역 관리 및 추적, 브랜치별 버전관리
4) 빌드 테스트 자동화
- 통합 빌드, 자동 테스트, 오류 검사, 테스트 커버리지 분석, 코드 복잡도 분석
⦿ 구축시 고려사항
- 전략적 : 프로세스 개선, 효율성/효과성, 조직문화, Step By Step
- 기술적 : 간단하고 쉽게, 유기적 통합, 자연스러운 프로세스, 정량적 측정 및 통제, 시스템 통합
⦿ 발전방향
- 어플리케이션 프레임워크화
- SOA기반 아키텍처 지원
- 대규모 시스템 지원
- 협업환경 지원
- 오픈소스화
```
71
SW 아키텍처
```
⦿ 정의
- 시스템의 정형화된 명세서.
- 시스템 설계로 발전 시키기 위한 지침과 원리
⦿ 중요성
- 비즈니스 측면 : 변화 민첩성, 비용 절감, 표준화
- 기술 측면 : 의사소통, 복잡성, 기준 제시
⦿ 특징
- 추상화, 간결성, 가시성
⦿ 구성
- Mission, Environment, System, Architecture, Stakeholder, Architecture Description, Rationale, Concern, Viewpoint, View, Library Viewpoint, Model
⦿ 뷰 모델종류
- Parry & Wolf's Model(REF)
- Sha & Garlan's Model(컴패커)
- Siemens Four View(개모코실)
- 4+1 View(유로프컴디)
- EA프레임워크(도모토작페테)
```
72
Perry & Wolf's Model
- Rationale : 근거, 기능성/성능/신뢰성, 경제성
- Elements : 프로세싱, 데이터, 연결
- Form : 표현법
73
Shaw & Garlan's Model
- 컴포넌트 : 임무제공, 실행
- 커넥터 : 상호작용
- 패턴 : 조합, 제약사항
74
Siemens Four View
- 개념적 아키텍처 뷰 : 관계식별
- 모듈 뷰 : 시스템 분할
- 코드 아키텍처 뷰 : 소스 구조화
- 실행 뷰 : 개체 속성 정의
75
4+1 View
- Use Case View : 사용자 관점, 요구사항 단계 (Usecase-diagram, User-Story)
- Logical View : 설계자 관점, 시스템 기능적 요구 (Class, Object, Structure Diagram)
- Process View : 통합자 관점, 프로세스 흐름 (Sequence, Communication Diagram)
- Component View : 개발자 관점, 컴포넌트 구성 (Component, Package Diagram)
- Deployment View : SE관점 (Deployment, Network Topoloty Diagram)
76
아키텍처 문서
(개배요참 아시적기)
1. 개요
1. 1 목적 및 필요성
1. 2 적용 범위
1. 3 이해관계자
1. 4 View 정의
2. 배경
2. 1 시스템 환경
2. 2 제약 사항
3. 요구사항
3. 1 품질모델 적용 기준
3. 2 아키텍처 요구사항
3. 3 아키텍처 영향 요소 분석
4. 참조 모델(아키텍처)
4. 1 참조 View Point
4. 2 참조 아키텍처 스타일
5. 아키텍처
5. 1 아키텍처 목표
5. 2 아키텍처 구성
5. 3 고려사항/제약사항
6. 시스템 뷰
6. 1 시스템 전체 뷰 요약
6. 1 각 종 View
7. 적합성
8. 기타
77
SW 아키텍처 작성 절차 및 원칙
```
⦿ 작성 절차
1. 기술서 정보작성
2. 이해관계자/관심사
3. 관점선택
4. 관점별 설명
5. 뷰 작성
6. 전체 뷰 작성&취합
⦿ 작성 원칙
- 핵심 집중
- 명학한 표현
- 표준 준수
- 내용 충실
- 리뷰 활동
```
78
SW 아키텍처 구축방안
```
⦿ 수립절차
- 업무영역 표현
- 아키텍처 컴포넌트 타입/패턴 표현
- 컴포넌트 타입/패턴 결합
- 구현 아키텍처
- 시스템 아키텍처
- 개발표준
⦿ 설계절차
- 요구분석 : 비즈니스, 시스템
- 아키텍처 분석 : 품질, 시나리오, 우선순위화
- 아키텍처 설계 : 관점 & 뷰 설계
- 아키텍처 평가 : 검증, 승인
- 아키텍처 상세화 : 스타일, 표준
```
79
IEEE1471
```
⦿ 정의 : 소프트웨어 중심 시스템의 아키텍처를 기술하기 위한 개념적 프레임워크
⦿ 특징 : 표준화, 독립성, 범용성, 의사소통, 가이드라인
⦿ 프레임워크 : Mission, Environment, System, Architecture, Stakeholder, Architecture Description, Rationale, Concern, Viewpoint, View, Library Viewpoint, Model
⦿ 작성절차
1) 아키텍처 기술서 정보 작성
2) 이해관계자 관심 식별
3) 관점 선택
4) 관점 설명 작성
5) 뷰 작성
6) 전체 뷰 작성
```
80
SW 아키텍처 정방향, 역방향 분석
- 정방향 분석 기법 : ATAM, CBAM
| - 역방향 분석 기법 : 도메인 분석 활용, 지표를 이용한 분석, 시각화를 활용한 분석
81
SW 아키텍처 뷰
```
⦿ 정의 : 다양한 Stakeholder들이 소프트웨어 아키텍처를 바라보는 측면
⦿ 구성요소
- 뷰문서 : 도식화, 요소목록, 요소명세, 가변성지침, 근거
- 뷰개괄문서 : 개요, 뷰관계, 제약사항, 관리정보
⦿ 뷰 모델종류
- Parry & Wolf's Model(REF)
- Sha & Garlan's Model(컴패커)
- Siemens Four View(개모코실)
- 4+1 View(유로프컴디)
- EA프레임워크(도모토작페테)
```
82
SW 아키텍처 스타일
```
⦿ 정의 : SW 설계 시 반복적으로 발생하는 특정 설계문제에 대해 구조적/조직적 관점에서의 해결방안
⦿ 필요성
- 최적의 아키텍처 제시
- 시스템 이슈사항 사전인지
- 대외적 신뢰성
- 설계지식 재사용
⦿ 유형 (흐중가호) (일파 칠저 번규 주원레)
1) 데이터 흐름(Data Flow)
- 일괄순차형(Batch Sequence)
- 파이프 필터형(Pipes & Filters)
2) 데이터 중심(Data-Centered)
- 칠판형(Blackboard)
- 저장소형(Repository)
3) 가상 머신(Virtual Machine)
- 번역기형(Interpreter)
- 규칙기반 시스템형(Rule-Based Sysem)
4) 호출과 리턴(Call & Return)
- 주 프로그램과 서브루틴(Main Program & Subroutine)
- 원격 프로시저 호출(Remote Procedure Call)
- Layered
⦿ 사례
- MVC(Model-View-Controller)
- Client-Server
- OSI 7 Layer
- Pipes and Filter
- Repository
- Publish-SubScribe
```
83
관점별 SW아키텍처 스타일
1) Runtime view
- Data Flow
- Call & Return
- Interacting Process
- Data Sharing
2) Module view
- Decomposition
- Generalization, Uses
3) Allocation view
- Decomposition
- Implementation
- Work assigment
84
모듈 뷰 타입(Module View-types)
```
⦿ 정의 : 시스템의 주요한 구현 단위 이며, 각 모듈들은 기능적 책임 소유
⦿ 요소의 속성 : 이름, 책임, 구현정보
⦿ 관계의 속성
- is-part-of : 가시성
- depends-on : 제약조건
- is-a : 구현속성
⦿ 스타일유형
- 분할 (Decomposition) 스타일
- 사용 (Uses) 스타일
- 일반화 (Generalization) 스타일
- 레이어 (Layered) 스타일
```
85
컴포넌트와 커넥터 뷰 타입(Component and Connector View-types)
```
⦿ 정의 : 런타임 컴포넌트와 컨넥터로 시스템의 실행단위를 기술
⦿ 요소 : 컴포넌트 타입(처리유닛), 커넥터 타입(상호작용)
⦿ 요소의 속성 : Attachment(role 연결)
⦿ 스타일유형
- 파이프-필터(Pipe-and-Filter) 스타일
- 공유데이터(Shared Data) 스타일
- 출판-구독(Publish-Subscribe) 스타일
- 클라이언트-서버(Client-Server) 스타일
- 피어-투-피어(Peer-to-Peer) 스타일
- 커뮤니케이스-프로세스( Communicating-Processes) 스타일
```
86
할당 뷰 타입(Allocation View-types)
```
⦿ 정의 : 시스템의 소프트웨어 구성요소화 소프트웨어가 생성되고 실행되는 외부 환경 사이의 관계를 기술
⦿ 요소 : 소프트웨어 요소와 환경적 요소
⦿ 요소의 속성 : Allocated-to(환경적 요소)
⦿ 관계의 속성 : SW 요소는 required, 환경적 요소는 provided
⦿ 스타일유형
- 배포(Deployment) 스타일
- 구현(Implementation) 스타일
- 작업할당(Work Assignment) 스타일
```
87
SW 아키텍처 평가
⦿ 정의 : SW Architecture가 개발될 SW에 대해 요구되는 품질특성을 충족시킬 수 있는지를 Architecture 수준에서 평가하는 작업, 절차
⦿ 필요성 : 위험조기 식별 제거, 품질속성 SW 반영에 대한 영향도 평가, 아키텍처는 프로젝트의 성패를 좌우하는 핵심요소
⦿ 관점별 평가유형
- 가시적 : Inspection, Review, Validation/Verification
- 비가시적 : SAAM, ATAM, CBAM, ARID, ADR
⦿ 방법론별 평가유형
- 시나리오 기반 : SAAM, ATAM, CBAM, ARID, ADR
- 시뮬레이션 기반 : BMT
- 수학적 모델 기반 : 수치화 평가
- 경험기반 : 정량적 분석 어려운 경우
⦿ 유형 : SAAM, CBAM, ATAM, ARID, ADR
88
SAAM (Software Architecture Analysis Method)
```
⦿ 정의 : SW 아키텍처를 쉽게 평가할 수 있는 접근법을 명세화한 최초의 아키텍처 평가 방법론
⦿ 평가단계 (시아시우간상종)
1. 시나리오 개발
2. 아키텍처 설명
3. 시나리오 분류와 우선순위 결정
4. 간접 시나리오 평가
5. 시나리오 상호작용 평가
6. 종합 평가
```
89
ARID (Active Reviews for Intermediate Designs)
```
⦿ 정의 : 모듈 형태인 SUB 관점에서 아키텍처 평가
⦿ 평가단계(검설기검 아설브시요)
1. 검토자 구성
2. 설계 요약 자료 작성
3. 기초 시나리오 작성
4. 검토 준비 완료
5. ARID 소개
6. 설계 설명
7. 브레인스토밍 및 우선순위 결정
8. 시나리오 적용 설계 검토
9. 요약 정리
```
90
CBAM (Cost Benefit Analysis Method)
⦿ 정의 : 비용 중심의 의사결정 평가 방법
⦿ 평가단계 (시효아접)
1. 시나리오 결정 (수집, 정제, 우선순위)
2. 효용-반응값 곡선 작성
3. 아키텍처 접근법 전체 이익 계산(예상 반응값 결정, 예상 효용 계산, 전체 이익 계산)
4. 아키텍처 접근법 선정과 점증 (접근법의 ROI 계산 순위결정, 비용 일정 고려한 결과 검증)
91
ATAM (Architecture Tradeoff Analysis Method)
```
⦿ 정의 : 아키텍처가 품질 속성을 얼마나 ㅁ나족시키는지를 속성들을 상호절출(Trade-offs)하면서 우선순위를 산출하고 평가하는 방법
⦿ 평가단계 (아비아 접유접 브시 아결)
가. 소개
1. ATAM 소개
2. 비즈니스 동인 소개
3. 아키텍처 소개
나. 조사와 분석
4. 아키텍처 접근법 식별
5. 품질속성 유틸리티트리 작성
6. 아키텍처 접근법 분석
다. 테스트
7. 브레인스토밍과 시나리오 우선순위 결정
8. 아키텍처 접근법 분석 반복
라. 보고
9. 결과 보고
```
92
아키텍처 시각화 기법
- DSM (Dependency Structure Matrix) : 의존성 분석 도구
- Instability/Abstractness Graph
- STAN4J
93
DSM (Dependency Structure Matrix)
```
⦿ 개념 : Task별 의존관계를 시각화 하여 볼 수 있는 도구
⦿ 작성방법
- 각각의 Task를 가로축과 새로축에 배치
- 의존관계에 따라 Task간 교차 칸에 "x" 표시
⦿ 지표 : 순환 참조
⦿ 시사점 : 순환 참조 발견, 변화와 전파 여부 확인, 꼬리물기 확인
⦿ 대응방안 : 의존성 파괴 (AOP, IoC)
⦿ 의존관계 관리방법 : 계층화(전파를 국지적으로 한정)
```
94
Instability/Abstractness Graph
⦿ 개념 : 패키지나 Code Element의 변경 여력과 추상화 정도를 통해 해당 패키지나 Code Element의 균형여부를 판단하는 분석 도구
⦿ 작성방법
- 평가 대상 패키지나 Code Element의 Instability, Abstractness 계산
- Main Sequence와 Distance 계산
- 지표 : Instability, Abstractness
95
STAN4J
⦿ 개념 : SW 품질 지표와 이에 맞는 뷰 제공(자바)
⦿ 사용방법 : 이클립스 플러그인
⦿ 지표 : Composition(클래스간 관계, Tangle 발견), Pollution(전반적 문제 확인)
96
MDA (Model Driven Architecture)
```
⦿ 정의 : 시스템의 설계와 명세를 메타모델 기반으로 기술 플랫폼과 분리하여 개발하고, 실제구현과 관련된 모델은 매핑을 통해서 기술플랫폼에 독립적으로 개발된 모델을 변환하여 얻는 방법
⦿ 기존 미들웨어 플렛폼의 한계
- 다양한 미들웨어 플렛폼 등장
- 다양한 컴포넌트 아키텍처의 등장
- 개발 패러다임의 변화
- 기업의 시스템 구성 어려움
- 서로 다른 컴포넌트 프랫폼 간의 연동 문제
⦿ 장점 : 구현 자동화, 재사용성, 이식성, 상호운영성
⦿ 표준모델
- MOF(Meta Object Facility) Model : 저장소
- UML Metamodel : 표준 언어
- CWMs(Common Warehouse Model) : DW아키텍처 메타모델
- XMI(XML Metadata Interchange) : XML 데이터 관리
⦿ 모델분류
- Business 모델 (금융, 제조)
- PIM 모델 (기본)
- PSM 모델 (상세)
```
97
MDD (Model Driven Development)
```
⦿ 절차
1) MDA 개발
- 타겟 플랫폼 식별
- 메타 모델 식별 정의
- 매핑 기법 정의 구현
2) MDA 기반 Application 개발
- PIM 모델 작성
- PSM 모델 생성
- Appl 완성
⦿ 단계별 모델
- PIM : 업무모델, 분석모델
- PSM : 종속모델, 플랫폼 선택
- APP생성
⦿ 모델 변환 방법
- PIM to PIM : 개발단계 상세화
- PIM to PSM : 기술 종속 정보 추가
- PSM to PSM : 실제 구현정보 추가
- PSM to PIM : Re-Engineering
```
98
MDA 통합 개발도구 및 아키텍처
⦿ MDA기반 컴포넌트 통합 개발도구
- 관리 : 프로세스 관리기, 모델 매핑 관리기, 메타모델 정의기, 설계 패턴 관리기
- 생성 : 비즈니스 모델 생성기, PIM생성기, PSM 생성기, 코드 생성기
- 컴포넌트/웹서비스 전개기
- 시험기
- 통합 개발 환경
- 모델 정보 저장소, 컴포넌트/웹서비스 저장소
⦿ 아키텍처
- 재무, 생산, 보험, 의료
- 어플리케이션 개발용 컴포넌트, 포탈 서비스용 컴포넌트, 어플리케이션 통합용 컴포넌트
- 플랫폼 종속 컴포넌트 모델(UML, MOF, XML, XMI)
- 컴포넌트 플랫폼 매핑(UML4EJB, UML4CORBA, UML4.NET, UML4SOAP)
- 컴포넌트 플랫폼 독립 모델(UML, MOF, XML, XMI)
- 컴포넌트/웹 서비스 플랫폼(J2EE, CORBA, .NET, SUN ONE, SOAP)
99
SOA (Service Oriented Architecture)
```
⦿ 정의
- 기존 어플리케이션 서비스를 조합함으로써 새로운 어플리케이션을 구현할 수 있도록 하는 통합 기술 및 아키텍처 모델
⦿ 특징 (프플느 메협)
- 프로세스 중심
- 플랫폼 독립적 어플리케이션 통합
- 느슨한 결합
- 메시지 및 프로세스 상태관리
- 협업과 재사용
⦿ 구성요소 (중제소)
- 중개자(Service Broker)
- 제공자(Service Provider)
- 소비자(Service Consumer)
⦿ 핵심기술 (교미 호기등)
- 데이터 교환(XML)
- 미들웨어(ESB)
- 서비스 호출(SOAP)
- 서비스 기록(WSDL)
- 서비스 등록(UDDI)
⦿ 기술 아키텍처 Layer (프비서아퍼)
- Presentation Layer : X-Internet, Portal
- Biz-Process Layer : BPM
- Service Intermediary Layer : ESB(BPEL)
- Application Layer : Web Service, EAI
- Persistency Layer : RDBMS, BRE
⦿ 어플리케이션 구성 유형
- Primitive SOA : 초기 Web Service
- Networked SOA : ESB/EAI 개념도입
- Process-Enabled SOA : BPM 기반 SOA
⦿ 구축전략
- 전체 아키텍처 관점에서 고민
- 크게 생각하되 작게 시작
- 적용 성숙도 모델 참조
⦿ 구축절차
- SOA전략수립
- 서비스 인지
- 서비스 컴포넌트 설계
- 인프라 통합 및 구현
- SOA 유지보수
```
100
Web Service
⦿ 정의
- SOAP, WSDL, UDDI 등의 표준 기술을 이용하여 네트워크에 연결된 다른 컴퓨터 간의 개방형 분산 컴퓨팅을 지원하는 기술 및 소프트웨어
⦿ 특징
- 단순성, 상호운영성, 유연성, 편리성, 통합환경, 비용효율
⦿ 구성요소
- Service Provider
- Service Broker(Registry)
- Service Consumer(Requester)
⦿ 주요기술
- UDDI (Universal Discription, Discover and Integration : 서비스 등록, 검색, 발행, 검색
- WSDL (Web Services Description Language) : XLM 문법
- SOAP (Simple Object Access Protocol) : 데이터 통신
101
SOAP (Simple Object Access Protocol)
```
⦿ 정의
- HTTP, HTTPS, SMTP 등을 사용하여 XML기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 형태의 프로토콜
⦿ 특징
- HTTP프로토콜 사용, XML 구조, 호환성 우수
⦿ 구성요소
- HTTP Header : SOAP 규정
- SOAP Envelop : 내용, F/W 설명
- SOAP Header : 인증, 트랜잭션
- SOAP Body : 데이터
```
102
WSDL (Web Service Description Language)
```
⦿ 정의 : 웹 서비스의 서식과 프로토콜을 표준 방식으로 기술하고 게시하기 위한 언어
⦿ 구성도
- definitions
- types
- message
- portType
- binding
- service
⦿ 구성요소
- 데이터 타입
- 메시지
- 오퍼레이션
- 포트타입
- 바인딩
- 포스
- 서비스
```
103
UDDI (Universal Description Discovery & Integration)
```
⦿ 정의
- 공급자는 자신의 웹 서비스를 등록/공개하고, 소비자는 이를 검색하여 원하는 정보를 찾아 이용할 수 있는 공유 서비스 저장소
⦿ 구성요소
- Business Entity (Yellow Pages
- Business Service (Green Pages)
- Binding Template(White Pages)
- Tmodel : 거래 기술정보, 분류 정보
```
104
소프트웨어 플랫폼
```
⦿ 정의
- 소프트웨어 모듈의 표준화, 개발, 다른 서비스의 연계를 지원하는 컴포넌트의 집합
⦿ 특징
- 재사용, Time To Market, 네트워크 효과
⦿ 유형
- 개발 플랫폼 : Eclipse, J2EE, .NET
- 실행 플랫폼 : .Net F/W, JVM
- 기반 통합 플랫폼 : Google Play, AppStore
- Cloud/분산처리 플랫폼 : Hadoop
- 기반통합 플랫폼 : Android, iOS, 타이젠
- 미디어/컨텐츠 플랫폼 : Youtube, Flickr
- SNS/Web기반 플랫폼 : kakaotalk, Face Book
⦿ 기술 :
- Interface(Open API, Mashup, JSON, REST)
- Application(HTML5, JavaScript)
- Streaming(HLS, RTSP/RTMP)
- Infra(Cloud, NoSQL, Hadoop, IaaS, PaaS, SaaS, Virtualizatioin, Web Cache, CDN, ADN)
- Authentication(OAuth)
- Metadata(정보 검색 기술, 저작권 보호 기술, 데이터 표준화 기술)
```
105
Spring Framework
```
⦿ 정의
- 경량화된 오픈 소스 웹 어플리케이션 프레임워크
⦿ 특징
- 객체관리
- 제어반전
- 의존성주입
- 관점지향 프로그래밍
- 영속성
⦿ 구성요소
- Sprint Core(IoC)
- AOP
- ORM(Hiberate, iBatis)
- DAO(JTA)
- Web
- Context
- MVC
```
106
전자정부 프레임워크
```
⦿ 정의
- 기본적인 아키텍처와 공통 모듈 등의 특정한 틀을 미리 만들어 놓고 SW개발 작업
⦿ 구성
- 실행환경
- 개발환경
- 운영환경
- 관리환경
- 공통 컴포넌트
- 모바일 디바이스 (개발/실행 환경) API
```
107
Node.js
⦿ 정의
- Event 기반의 비동기 I/O Framework 로 확장성 있는 네트워크 어플리케이션 개발에 사용되는 SW플랫폼
⦿ 특징
- 자바스크립트 활용
- 내장 HTTP 서버 라이브러리 포함
⦿ 구성
- JavaScript
- C/C++
- node standard library
- node bindings(socket, http, etc)
- V8
- thread pool(libeio)
- event loop(libev)
- DNS(C-areas)
- crypto(OpenSSL)
⦿ 동작절차
1) Node는 최초 시작시 event loop 시작, 최초 aa.js 실행시 aa.js는 compile 되어 process.nextTickle의 callback으로 선언
2) Event Loop 안에 참가한 callback들이 V8에 의 해 compile
3) libeio 관련 eio_req 구조체에 여러 정보 선언되어 request queue에 입력, 이때 thread pool을 사용한 비동기 IO발생 (node 장점)
4) thread pool을 이루고 request queue에서 작업을 가져가 처리하고 완료되면 response queue에 입력
5) Response queue에 입력되면 호출되는 프로세스가 진행되며 ego_poll과 연관되어 event_loop에 통지
6) notifier 관련 생략된 프로세스가 있으나 대략 V8에서 callback 실행됨
108
Angular JS
```
⦿ 정의 : 복잡한 클라이언트 사이드 애플리케이션 개발을 위한 자바스크립트 프레임워크
⦿ 특징
- SPA(Single Page Application)
- MV* (Model-View-Whatever)
⦿ 철학
- 데이터 중심
- 테스트 용이
- HTML 선언
⦿ 기본구조
- 정적/동적 DOM, ng-app, injector, compile
⦿ 기본개념 (스모뷰 컨다)
- Scope : 모델표현 책임
- Model : 화면 템플릿 객체
- View : 표현
- Controller : call back method
- Directives : 행위 주체
```
109
J2EE 디자인패턴
```
⦿ 개념 : J2EE에 특화된 디자인 패턴
⦿ 계층별 패턴(프비인 인프컴서디 비벨세 어벨서 데서)
1) Presentation
- Intercepting Filter : 요청 타입에 따라 다른 처리
- Front Controller : 요청 전/후 처리
- Composite View : 화면 구성
- Service To Work : FC와 VH사이의 디스패처
- Dispatcher View : FC와 VH사이의 디스패처 컴포넌트
2) Business
- Business Delegate : 비즈니스 캡슐화
- Value Object : 데이터 교환
- Session Facade : 원격 클라이언트 접근
- Aggregate Entity : Coarse-grained entity bean 설계
- Value object Assembler : 조회, 저장, 결과, 집합검색
- Service Locator : 서비스, 컴포넌트 검색
3) Integration
- Data Access Object : DB 접근 전담 클래스 추상화
- Service Activator : 비동기적 호출 처리
```
110
UML Profile
```
⦿ 정의
- 모델을 정확히 표현할 수 있게 한 UML의 확장 매커니즘
⦿ 확장 메커니즘 (스태태컨)
- Stereotypes : 속성, 제약 추가
- Tag Definitions : 속성 정의
- Tagged Values : 속성에 대한 값
- Constraints : 제약 추가
⦿ MDM에서 UML Profile 활용
- PIM : UML Profile for EDOC, UML Profile for EAI, UML Profile for Schedulability, Performance and Time
- PSM : UML Profile for CORBA, UML Profile for EJB, UML Profile for .NET
```
111
OCL(Object constraint Language)
```
⦿ 정의
- 객체지향 모델요소에 대한 제약조건을 기술하기 위한 언어
⦿ 제약조건
- 불변조건 (invariant)
- 선행조건 (precondition)
- 후행조건 (post-condition)
```
112
OCL 불변조건
```
⦿ 정의 : 실행 동안 항상 만족해야 하는 성질
⦿ 표현방법
context Context_선택한_타입_이름
inv : 조건식
context 클래스명
(inv[제약명]: 조건식)+
⦿ 작성예
context Company inv;
self.numberOfEmployee > 50
: Company의 instance가 존재하는 동안 numberOfEmployee 값은 항상 50 이상 이여야 함
```
113
OCL 선행조건
| OCL 후행조건
⦿ 정의
- 실행 전에 만족해야 하는 성질
⦿ 표현방법
context
타입이름::오퍼레이션이름(인자:인자타입);리턴타입
pre : 선행조건식
post : 후행조건식
Context 클래스명::조작명(인수리스트)[: 반치형]({pre|post[제약명]; 조건식}+
⦿ 작성예
connect Typename::op(param1:Type1,..);Return
Type
pre paramOK: param1 > param2
post paramOK: result=param1+param2
Pre:인출자=self.명의인 and self.잔고 + self.대출한도액 >= 금액
Post:self.잔고 = self.잔고 @ pre* 금액 and result = 금액
114
UML Stereotype
```
⦿ 정의
- UML의 기본적 요소 이외의 새로운 요소를 만들어 내기 위한 확장 매커니즘
⦿ 종류
- include : 포함(반드시) 관계
- extend : 확장(조건) 관계
- interface : 추상메소드, 상수
- entity : 데이터 클래스
- boundary : 경계 클래스
- control : 트랜잭션
```
115
Activity diagram
```
⦿ 정의
- 처리 로직이나 조건에 따른 처리흐름을 순서에 따라 정의한 다이어그램
⦿ 구성요소 (활시종 선전구)
- 활동 (Activity) : 타원
- 시작 (Initial) : 검은점
- 종료 (Final) : 희색점 속 검은점
- 선택 (Decision) : 흰색 다이아
- 전이 (Transition) : 화살표
- 구획 (Swim lane) : 구분
```
116
State diagram
```
⦿ 정의
- 클래스의 객체가 가질 수 있는 모든 가능한 상태를 보여주며, 특정 객체에 대하여 사건 발생에 따른 상태 전이과정을 묘사한 다이어그램
⦿ 구성요소 (상시종전)
- 상태 : 네모
- 시작 : 검은점
- 종료 : 흰색점 속 검은점
- 전이 : 화살표
```
117
Use Case Diagram
```
⦿ 정의
- 시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 다이어그램
⦿ 구성요소
- Use Case : 시스템의 서비스(타원)
- Actor : 수행역할(사람)
- System : 시스템 영역(사각형)
⦿ 관계 표현법 (연확포일그)
- 연관(Association) : 실선
- 확장(Extend) : 선택, 점선 화살표
- 포함(Include) : 필수, 점선 화살표
- 일반화(Generalization) : 상속
- 그룹화(Grouping) : 단순화
⦿ 작성절차
- Actor 식별
- Use Case 식별
- Relationship 정의
- Use Case 구조화
```
118
Sequence diagram
```
⦿ 정의
- 문제 해결에 필요한 객체를 정의하고 객체간 주고받는 메시지의 순서를 시간의 흐름에 따라 보여주는 다이어그램
⦿ 특징
- 도식화, 상호작용, 구체화, 제약 사항 표현
⦿ 구성요소 (활메제)
- 활성객체 : 행위자, 생명선
- 메시지 : 의사소통
- 제어사각형 : 정보 처리중
⦿ 메시지 사용법 (동반비평)
- 동기 : 채워진 실선 화살표
- 반환 : 점선 화살표
- 비동기 : 반 열린 굵은 실선 화살표
- 평판 : 열린 실선 화살표
```
119
Class Diagram
```
⦿ 정의 : 시스템에서 사용되는 객체 타입을 정의하고, 그들 간의 존재하는 정적인 관계를 표현한 다이어그램
⦿ 클래스 간 관계(연집복의상구)
- 연관관계
- 집합연관관계
- 복합연관관계
- 의존관계
- 상속관계
- 구현관계
```
120
UML 2.0
```
⦿ 등장배경
- MDD 지원, 웹 어플리케이션, SOA의 등장
⦿ 특징
- 정확한 언어구조
- 규모가 큰 시스템의 모델링 향상
- 도메인 스펙의 특성화 지원 향상
- 다양한 모델링 개념들의 정리, 개념화, 정의
⦿ OMG 4계층 메타모델
- M3 (Meta-Meta Model)
- M2 (Meta Model)
- M1 (User Model)
- M0 (Run-Time Instance)
```
121
UX (User Experience)
```
⦿ 정의
- 사용자가 어떤 시스템, 제품, 서비스를 직/간접적으로 이용하면서 느끼고 생각하게 되는 총체적 경험
⦿ 구성요소(니모비어)
- Needs
- Motives
- Behavior
- Attitudes
⦿ 세대별 패러다임
- 제1세대 : CLI
- 제2세대 : GUI
- 제3세대 : NUI
- 제4세대 : OUI
⦿ 원리, 분석, 디자인(PDA)
- UX Principle : 유용성, 사용성, 감성
- UX Analysis : 사용자, 과업, 맥락, 기술
- UX Design : 컨셉, 정보구조, 인터렉션, 인터페이스
⦿ 디자인 프로세스 (사정인사)
- 사용자조사 : 사용자/환경/과업 분석
- 정보구조 설계 : 객체구조 설계
- 인터렉션/인터페이스 디자인 : 상호작용 정의
- 사용성 테스트 : 정량적/정성적 분석
```
122
멘탈모델
```
⦿ 개념
- 사용자의 머릿속을 들여다 보는 행위
⦿ 3가지 형태
- 구조모형 : 구체적 세부요소
- 기능모형 : 제품/서비스 이용 형태
- 가치모형 : 가치 제공
```
123
페르소나
```
⦿ 개념
- 사용자 유형을 가공의 캐릭터로 표현하는 기법
⦿ 특징
- 사용자 집중 분석
- 사용자 감성 이해
⦿ 구성요소
- 사용자 정보 및 프로파일
- 사용자의 구체적 정보
- 사용자의 기대
- 공급자의 기대
```
124
Journey Map
⦿ 개념
- 사용자들이 시간의 흐름에 따라서 서비스를 이용하는 흐름을 분석하여 문제를 발견하는 기법
⦿ 구성 : Pre-Service, Service, Post-Service
125
Affinity Modeling
```
⦿ 개념
- 방대한 데이터에서 의미 있는 결론을 이끌어 내는데 효과적인 기법
⦿ 절차
1) Affinity화
2) 포스트잇에 적힌 요구사항을 Affinity Wall에 부착
3) 브레인스토밍 또는 명목집단 기법 통해 포스트잇 분류 하고 그룹핑
4) 분류된 포스트잇 그룹에서 해당 그룹의 Header도출, Header를 중심으로 재 그룹핑
5) 완성된 Affinity Model을 두고 주요 시사점 토론
```
126
UX모델 평가기법 Kano모델
```
⦿ 개념
- 사용자 만족도와 Needs간의 관계를 명시하여 개별 Needs들의 가치를 판단하게 해주는 모델
⦿ 4가지 Factor (익퍼배인)
1) Exitement : 만족도 지수적, 불만족 없음
2) Performance : 만족도 변화, 불만 증가
3) Basic : 만족도 증가 없고, 불만 크게 증가
4) Indifference : 무관심
⦿ 4가지 축
1) Customer Satisfied
2) Customer Dissatisfied
3) Needs Unfullfilled
4) Needs Fullfilled
```
127
정보시스템감리
⦿ 정의 (전자정부법 2조 14호)
- 감리발주자 및 피감리인의 이해관계로부터 독립된 자가 정보시스템의 효율성을 향상시키고 안전성을 확보하기 위하여 제3자적 관점에서 정보시스템의 구축 및 운영 등에 관한 사항을 종합적으로 점검하고 문제점을 개선하도록 하는 제도
⦿ 주요목적 : 효과성, 효율성, 안전성, 경제성, 준거성, 객관성, 품질보증
128
정보시스템감리 프레임워크
⦿ 사업유형/감리시점 (아전시데운유)
⦿ 감리영역
1. 기반 정립 및 현행아키텍처 수립
2. 미래아키텍처 수립 및 이행계획 수립
- 기반설립, 현행아키텍처구축
- 이행계획, 목표아키텍처구축
- 관리체계
- 품질보증활동
1. 현황 분석 및 전략수립
2. 개선 모델 및 실행계획 수립
- 업무, 기술, 정보화계획, 품질보증활동
1. 요구정의/분석
2. 설계
3. 구현
4. 시험
5. 전개
6. 종료
- 시스템아키텍처, 응용시스템, 데이터베이스, 시험활동, 운영준비, 종료
- 품질보증활동
1. 준비
2. 구축
- 데이타수집 및 시범구축, 데이타구축, 품질검사
1. 운영
- 서비스제공, 서비스지원
1. 유지보수
- 유지보수이행
- 절차, 산출물, 서비스(성과)
1. 감리계약의 체결
2. 예비조사 실시 및 감리계회 수립
3. 감리 착수회의 실시
4. 감리 시행 및 감리보고서의 작성
5. 감리 종료회의 실시
6. 감리보고서의 통보
7. 감리에 따른 시정조치 결과의 확인 및 통보
129
SW 분리발주
```
⦿ 정의
- 시스템 구축 발주에 있어 HW, SW 시스템 통합 등을 일괄하여 계약하지 않고 각각 구분하여 발주 및 계약하는 형태
⦿ 필요성
- 품질향상, 우수SW선택, 사업의 투명성, 기술적 여건 성숙
⦿ 분리발주 대상
- 총 사업규모가 10억원 이상인 사업에서 단일 SW가격이 5천만원 이상
- 5천만원 미만이라도 GS인증 받은 SW는 분리발주 검토 노력
⦿ 유형
- HW/SW 분리 : 서버, 네트워크, SW패키지, SW개별구축
- SW별 분리 : 패키지, 개별구축
⦿ 예외조항
- 통합불가/현저한 비용상승
- 현저한 일정지연
- 현저하게 비효율적
```
130
SW 분할발주
```
⦿ 정의
- SW사업을 PMO, 요구사업, 개발사업으로 분할하여 발주함으로써 명확한 요구사항과 사업관리의 가시성을 확보하는 발주방식
⦿ 2단계 분할
- 1단계 : 요건정의(ISMP), 기본설계(논리적 설계)
- 2단계 : 상세설계(물리적설계), 개발(시스템개발, 테스트)
⦿ 3단계 분할
- 1단계 : 요건정의(ISMP)
- 2단계 : 설계(기본설계, 상세설계)
- 3단계 : 개발(시스템개발, 테스트)
```
131
아키텍처 드라이버
⦿ 정의
- 소프트웨어 요구사항을 수행하는 기능적, 품질적, 성능에 영향을 주는 속성, 서비스 요구사항 중에서, 아키텍처 구성에 영향을 주는 항목 또는 요구사항
⦿ 목록 (기제품)
- Functional Requirements : 시스템이 수행해야 하는 기능(기능/비기능)
- Constraints : 제약사항
- Quality Attributes : 품질속성
PE
flashcards
Decks in class (15)
# Cards
