● 대표적인 형상관리도구 종류
| 구분 | CVS | SVN | GIT |
| 특징 | 파일 단위 커밋, Merge, Brench, Tag, Compare 지원 | CVS의 단점 보완 중앙 저장소 형태 Change Set 단위의 원자적 커밋 지원 |
분산저장소 타입 Github 호환 |
| 장점 | 오랜 기간 많은 유저가 사용하여 안정적임 백업용량을 적게 차지함 |
커밋 실패시 롤백 가능 파일 이름 변경 가능 상대적으로 빠른 처리속도 |
Offline 작업 가능 개발자별 History 관리 |
| 단점 | 커밋 실패시 롤백이 불가 느린 처리속도 파일이름 변경 불가 |
.svn 디렉토리로 지저분 이진파일은 머지 불가 개별 개발자 이력기록 불가 |
수많은 기능으로 사용이 복잡 사용 미숙시 Conflict 발생 잦음 |
● 형상관리의 특징
버전관리 - 소프트웨어 변경시 버전별로 관리하며, 소프트웨어 뿐 아니라 형상 대상의 항목을 모두 관리
전 단계 수행 - 형상관리는 프로젝트의 모든 단계에서 수행하며, 사업계획 단계부터 유지보수 단계에서도 수행되는 활동
추적성 확보 - 형상관리를 수행하여 소프트웨어 개발 과정에서 발생하는 여러가지 문제점 발생 시 해당 요인을 추적
● 형상관리의 baseline(기준선)
● 형상관리의 절차
● 대표적인 빌드도구 종류
| 구분 | ANT | Maven | Gradle |
| 특징 | XML 기반, 형식적 규칙이 없음 명확한 빌드 절차 정의가 필요함 빌드 프로세스만 정의 |
의존성과 표준화 된 프로젝트 관리 제공 POM.xml을 통해 라이브러리 관리 |
오픈소스 빌드 자동화 시스템 Groovy 기반 DSL 작성 |
| 장점 | 높은 유연성 ㅡ 개발자가 원하는 작업 상세 정의 가능 | XML, 원격 Repository를 선언만으로 가져올 수 있음 (jar, classpath) | ANT, Maven 단점 보완 스크립트가 작고 이해가 용이 Android IDE에서 기본으로 사용됨 |
| 단점 | 스크립트 재사용이 어려움 이해가 어려움 원격 Repository 사용 불가 |
라이브러리가 상호 의존시 XML이 복잡해짐 조건부 상황 표현이 어려움 맞춤화된 로직 실행이 어려움 |
● 대표적인 구현 도구 (IDE)
| Eclipse | Java, JSP, C, C++, PHP 등 | 자바 개발을 위한 대표적 무료 IDE Plug-in을 통해 다양한 기능 제공 |
Eclipse Public License |
| Visual Studio | Visual Basic, C#, C++, .net | MS 기반 웹 애플리케이션 및 PC 애플리케이션 개발 안정적, 다양한 기능 제공 |
상용(유료) |
| IntelliJ | Java, 코틀린, GO, Python | 대규모 프로젝트에서 Eclipse의 성능문제(느림) 대안으로 많이 활용 ADT(안드로이드)의 기반 IDE |
상용 무료-Apache2.0(기능 제약) |
| XCode | Objective-c, Swift | iOS 앱과 OSX 프로그램 개발을 위한 IDE | 무료(OSX 전용) |
● IDE의 기능
개발 환경 지원 - C++, Java 등의 언어를 이용하여 애플리케이션을 개발할 수 있는 환경을 제공
컴파일 및 디버깅 기능 제공 - 소스코드 코딩이 완료되면 이를 컴파일하여 문법에 어긋나지 않는지 확인하고, 오류가 발생하면 이를 추적하여 수정할 수 있는 디버깅 기능을 제공
외부 연계모듈과 통합 기능 제공 - EAI(Enterprise Application Integration), ESB(Enterprise Service Bus) 등 외부 인터페이스 모듈과 통합을 통하여 통합 개발 기능 제공 / JDBC(Java Database Connectivity), ODBC(Open Database Connectivity) 등을 통하여 데이터베이스 연동을 통한 통합 개발 기능 제공 / 외부 형상, 배포 관리 기능과 연계되어 소스 코드의 형상관리 및 자동 배포가능
● 개발언어 선정 기준
적정성 - 개발하고자 하는 시스템이나 응용프로그램의 목적에 적합한가
효율성 - 개발 대상을 효율적으로 구현이 가능한가
이식성 - 여러가지 운영체제와 디바이스에 적용 가능한가
친밀성 - 다수의 프로그래머가 사용 가능한 언어인가
범용성 - 다수의 시스템에서 사용 중이며, 많은 과거 사례가 존재하는가
● 협업 도구
협업도구의 필요성 - 구현 기간 동안 다양한 개발자들과 실시간 커뮤니케이션 필요. 개발 및 작업일정, 소스, 아키텍처가 수시로 변경되기 때문에 이에 대해서 개발자 간에 공유가 되어야 함. 여러 개발자들의 아이디어를 공유해야 품질이 높아짐.
| 문서 공유 | 구글 드라이브 | 팀원 간 또는 고객과 문서를 공유하거나 공동 작업을 할 수 있는 온라인 도구 |
| 슬라이드 | 온라인에서 PPT를 만들 수 있는 서비스 | |
| 소스 공유 | 깃허브 | 많은 프로그래머들이 애용하는 공동 작업 공간 수많은 오픈 소스 프로젝트가 여기서 진행 중임 |
| 아이디어 공유 | 에버노트 | 팀원들과 중요한 아이디어를 공유할 수도 있고, 업무와 관련있는 기사를 스크랩해서 공유하기도 함 |
| 인비전 | 프로그래머나 웹 디자인 전문가들이 많이 사용하는 온라인 프로토타이핑 도구 | |
| 디자인 공유 | 레드 펜 | 웹 디자인 전문가들이 사용하는 협업도구 자신의 디자인을 업로드하고 동료간 공동 작업 |
| 마인드 맵핑 | 마인드 마이스터 | 온라인 공동 마인드 맵핑 도구 공동으로 브레인스토밍을 하거나 정보간 관계망 그리기를 공동으로 수행함 |
| 프로젝트 관리 | 트렐로 | 온라인 공동 프로젝트 관리 도구 프로젝트의 각 과제들을 분류하고 구성원들을 배정함 |
| 레드마인 | 다수의 프로젝트 관리 도구 | |
| 지라(JIRA) | 프로젝트 이슈 트래킹 기반 협업 도구 | |
| 태스크월드 | 사용자가 자유롭게 프로젝트 일정, 팀원 설정 가능 | |
| 일정관리 | 구글캘린더 | 구글의 일정 관리 서비스 모바일과 PC연동이 가능 |
| 컨플루언스 | 개발자간 일정 공유 및 문서 공유 기능 |
● 애플리케이션 배포 도구의 지적 재산권(DRM) 보호를 위한 기술
| 암호화 (Encryption) |
컨텐츠 및 라이센스를 암호화하고, 전자 서명을 하는 기술 PKI, Symmetric/Asymmetric Encryption, Digital Signature |
| 키 관리 (Key Management) |
컨텐츠를 암호화한 키에 대한 저장 및 배포 기술 (Centralized, Enveloping) |
| 암호화 파일 생성 (Packager) |
컨텐츠를 암호화된 컨텐츠로 생성하기 위한 기술 Pre-Packaging, On-thefly Packaging |
| 식별 기술 (Identification) |
컨텐츠에 대한 식별 체계 표현 기술 DOI, URI |
| 저작권 표현 (Right Expression) |
라이센스의 내용 표현 기술 XrML/MPEG - 21 REL, ODRL |
| 정책 관리 (Policy management) |
라이센스 발급 및 사용에 대한 정책표현 및 관리기술 XML, Contents Management System |
| 크랙 방지 (Tamper Resistance) |
크랙에 의한 컨텐츠 사용 방지 기술 Code Obfuscation, Kernel Debugger Detection, Module Certification Secure DB, Secure Time Management, Encryption |
| 인증 (Authentication) |
라이센스 발급 및 사용의 기준이 되는 사용자 인증 기술 |
● DRM의 구성요소
| 컨텐츠 제공자 (DRM Server) |
컨텐츠 | 서비스 대상으로 암호화된 컨텐츠, 메타 데이터 |
| 패키저 | 클리어링 하우스에서 부여받은 컨텐츠 사용정보를 암호화한 컨텐츠로 변환하는 도구 | |
| 클리어링 하우스 (Clearing House) |
사용권한 정책 | 라이센스 발급여부를 결정하는 정책 적절한 사용권한을 부여하는 역할 수행 |
| 라이센스 | 사용자에게 전달되는 컨텐츠 권리 인증 정도 | |
| 컨텐츠 소비자 (DRM Client) |
DRM 컨트롤러 | 배포된 디지털 컨텐츠의 이용 권한을 통제 |
| 보안 컨트롤러 | 원본 컨텐츠를 안전하게 유통하기 위한 전자적 보안장치 |
● DRM의 기술 요소
| 콘텐츠 패키징 기술 | 콘텐츠 패키징 구조 | 패키징된 콘텐츠의 내부 구조를 표현하는 기술 |
| 콘텐츠 파일 포맷설계 | 패키징된 콘텐츠의 포맷에 대한 기술 규격 설계 | |
| 복합 콘텐츠 패키징 | 여러개의 콘텐츠를 묶어서 패키징하는 기술 | |
| 콘텐츠 암호화 | 콘텐츠의 기밀성, 무결성 보장을 위한 기술 | |
| 권리표현 기술 | 권리 데이터 사전 | 권리요소에 대한 정의 |
| XML기반 권리 표현언어 | 구문과 스키마 설계 | |
| 다이나믹 사용규칙 표현 | 다양한 비즈니스 모델을 지원하는 라이센스 생성기술 | |
| 저작권 권계표현 | 가치사슬 관계의 저작권 정보 표현기술 | |
| 워터마킹/핑거 프린팅 기술 | 워터마킹 | 다양한 공격에도 충분한 강인성을 유지하는 기술 |
| 핑거프린팅 | 불법 추적을 위한 핑거프린팅 정보 삽입 | |
| 공격 및 평가 | 기술의 강인성을 검증하기 위한 공격 및 평가기술 | |
| 복제 방지 기술 | 디바이스 인증 | 콘텐츠 전송단과 수신단 간의 상호 인증 처리 |
| 비밀키 교환 | 콘텐츠 전송 수단과 수신단 간의 안전한 비밀키 교환기술 | |
| 디바이스 폐기/회복 | 훼손된 디바이스의 폐기 및 회복기술 | |
| 암호화 | 콘텐츠 전송단과 수신단 간의 안전한 콘텐츠 전송을 위해 암호화 하는 기술 | |
| 콘텐츠 식별체계 | 식별자 구문 구조 | 식별자 구문 구조에 대한 기술규격 정의 |
| 식별자 변환 | 식별자의 실시간 변환기술 | |
| 식별 메타데이터 관리 | 공통으로 사용되는 기본 메타 데이터 구조 설계 | |
| DRM 도메인간 상호연동 | DRM간 상호인증 처리 | DRM 시스템간 상호인증 처리기술 |
| DRM adaptation | 상이한 DRM 기술간의 콘텐츠 및 권리정보 변환기술 | |
| 훼손된 DRM 모듈 폐기처리 | 훼손된 DRM 시스템의 인증폐기 처리기술 |
● 애플리케이션 모니터링 도구
| 애플리케이션 변경관리 | ChangeMiner | 애플리케이션간 종속관계를 모니터링함 애플리케이션 변경이 있을 경우 변경의 영향도 파악에 활용 |
| 애플리케이션 성능관리 | Jeniffer | 애플리케이션 서버로 유입되는 트랜잭션 수량, 처리시간, 응답 시간 등을 모니터링 |
| Nmon | 리눅스 서버 자원에 대한 모니터링 도구 nmonanalyser를 이용하여 자원 사용량을 그래프로 표현가능 |
|
| 애플리케이션 정적분석 | PMD | Java로 작성된 소스의 코드 잠재적인 문제 발견 Java 코딩 규칙 오류 발견 |
| CppCheck | C/C++ 소스코드에 대한 잠재적 문제 발견 | |
| 애플리케이션 동적분석 | Avalanche | valgrind 프레임워크와 STP(Simple Theorem Prover)를 기반으로 구현되었으며, 심각한 소프트웨어 에러 및 취약점 발견 |
| Valgrind | C/C++ 기반 프로그램에 대한 메모리 및 쓰레드 문제 발견 |
● 소프트웨어 품질 표준
| 제품 | ISO/IEC 9126 |
9126 - 1 (품질모델) 9126 - 2 (외부품질) 9126 - 3 (내부품질) 9126 - 4 (사용품질) |
품질 특성 및 측정 기준 제시 기능성, 신뢰성, 사용성, 효율성, 유지보수 용이성, 이식성 |
| ISO/IEC 14598 |
14598 - 1 (개요) 14598 - 2 (계획과 관리) 14598 - 3 (개발자용 프로세스) 14598 - 4 (구매자용 프로세스) 14598 - 5 (평가자용 프로세스) 14598 - 6 (평가모듈) |
소프트웨어 제품 평가 프로세스 및 평가 모듈을 제공 소프트웨어 획득자와 개발자 사이에서 소프트웨어 개발 과정 또는 개발된 제품의 품질에 대한 객관적인 평가 표준과 프로세스를 제공 패키지 소프트웨어와 SI 개발 소프트웨어에 있어서 개발 과정 또는 개발 완료된 제품의 품질에 대한 평가 표준과 프로세스를 제공 |
|
| ISO/IEC 12119 |
소프트웨어 패키지 - 제품 설명서 - 사용자 문서 - 프로그램과 데이터 |
패키지 SW 품질 요구사항 및 테스트 - 제품설명서 : 기본적인 요구사항과 적절한 문서화 체계인지 평가 - 사용자문서 : 설명되는 기능, 성능, 범위가 정확하고 이해하기 쉬운 구조인지 평가 - 실행프로그램 : 설치되는 프로그램이 정확하게 안정적으로 실행되는지 평가 |
|
| ISO/IEC 25000 |
2500n(9126 - 1) 2501n(9126 - 2) 2502n(9126 - 3) 2503n(9126 - 4) 2504n(9126 - 5) |
2500n -(SQuaRE) 2501n - (품질 모형(모델)) 2502n - (품질 메트릭) 2503n - (품질 요구사항) 2504n - (품질 평가) |
|
| 프로세스 | ISO/IEC 9000 |
9001(설계, 개발, 서비스) 9002(생산과 설치) 9003(최종검사 및 시험) 9004(지침 표준) |
품질 경영과 품질 보증에 관한 국제 규격 ISO/IEC 9000 family의 선택과 사용 지침 |
| ISO/IEC 12207 |
소프트웨어 life cycle Process S/W 기본, 지원, 조직 SDLC로 구분, 각각 수행 Process를 규정 | ||
| ISO/IEC 15504 |
프로세스 표준 모델(International Standard / 국제 표준) S/W Process 요소(개발/지원/조직 등)의 계획, 통제, 개선 capability와 process 규명 |
||
| ISO/IEC 15288 |
합의 프로세스 조직 프로세스 과제 프로세스 기술 프로세스 |
시스템 생명주기 프로세스 | |
| CMMi | 단계적 표현 연속적 표현 |
프로세스 표준 모델 |
● 컴파일 언어와 인터프리터 언어
| 컴파일 방식 | 고급 언어를 기계어로 번역한 후 실행 실행에 필요한 정보가 컴파일 시간에 계산되어 실행 후 속도가 빠름 |
FORTRAN PASCAL C |
| 인터프리터 방식 (스크립트 언어) | 고급 언어를 명령어 단위로 하나씩 번역하고 실행 프로그램 실행시 계산 |
JavaScript PROLOG LISP SNOBOL Basic Python PHP |
| 혼합방식 | 고급 언어를 컴파일 하여 중간 언어로 변환한 후 인터프리터에 의해 번역을 실행 | Java |
● AOP (Aspect Oriented Programming)
- 객체를 핵심과 횡단 관심사로 분리하고, 횡단 관심사를 관점(Aspect) 모듈로 정의하여 핵심과 엮어서 처리하도록 지원하는 프로그래밍 기법
핵심 관심사 = 프로그램을 작성하려는 핵심 가치와 목적이 드러난 관심 영역
횡단 관심사 = 로깅과 트랜잭션, 인증처리 등 시스템 공통 처리 영역
● 비트연산
7 & 5 : AND 연산 수행 (좌, 우측 값 모두 1이면 1, 하나라도 0이면 0)
7 = 0111
5 = 0101
& = 0101 = 5
7 | 5 : OR 연산 수행 (좌, 우측 값 중 하나라도 1이면 1, 둘 다 0인 경우만 0)
7 = 0111
5 = 0101
| = 0111 = 7
7 ^ 5 : XOR 연산 수행 (좌, 우측 값이 같으면 0, 다르면 1)
7 = 0111
5 = 0101
^ = 0010 = 2
● Stack, Queue의 활용
| Stack | Queue |
| 서브루틴 호출 인터럽트 처리 웹 브라우저 방문기록 (뒤로가기) 역순 문자열 만들기 실행 취소 (undo) 후위 표기법 계산 수식의 괄호 검사 깊이 우선 탐색 (DFS) |
라우터 패킷 처리 (QoS) 메시지 큐 우선순위가 같은 작업 예약 은행 업무 콜센터 고객 대기시간 프로세스 관리 너비 우선 탐색 (BFS) 캐시(Cache) 구현 |
● Circular Queue
| 구분 | Empty 상태 | Full 상태 |
| 개념도 |  |
 |
| 코드 | rear == front | (rear + 1) % MAX == front |
final int MAX = 10;
boolean isEmpty() {
return (rear == front);
}
boolean isFull() {
return (rear + 1) % MAX == front;
}(Circular queue는 Empty, Full 상태 구분을 위해 한칸을 비워둔다)
● 트리
| 루트 노드 (root node) | 부모가 없는 노드, 트리는 하나의 루트 노드만을 가짐 |
| 단말 노드 (leaf node) | 자식이 없는 노드 |
| 내부 노드 (internal node) | 루트나 단말 노드가 아닌 노드 |
| 링크 (link) | 노드를 연결하는 선 (= edge, branch) |
| 형제 노드 (sibling node) | 같은 부모를 가지는 노드 |
| 노드의 크기 (size) | 자신을 포함한 모든 자손 노드의 개수 |
| 노드의 깊이 (depth) | 루트에서 어떤 노드에 도달하기 위해 거쳐야 하는 간선의 수 |
| 노드의 레벨 (level) | 트리의 특정 깊이를 가지는 노드의 집합 |
| 노드의 차수 (degree) | 하위 트리 개수 혹은 간선의 수. 즉, 각 노드가 가진 가지의 수 |
| 트리의 차수 (degree of tree) | 트리의 최대 차수 |
| 트리의 높이 (height) | 루트 노드에서 가장 깊숙히 있는 노드의 깊이 |
● 트리 순회 방식
Root를 언제 순회하느냐에 따라 명칭이 달라짐
| 예시 |  |
||
| 순회방법 | Pre-Order (전위순회) | In-Order (중위순회) | Post-Order (후위순회) |
| 설명 | Root > Left > Right 순서로 순회 | Left > Root > Right 순서로 순회 | Left > Right > Root 순서로 순회 |
| 결과 | A B D C E F | D B A E C F | D B E F C A |
● 이진트리 (Binary Tree)
포화 이진트리 (Full binary tree) : 모든 레벨에서 노드들이 모두 채워져 있는 트리,
완전 이진트리 (Complete binary tree) : 마지막 레벨을 제외하고 노드가 모두 채워져있는 트리, 높이는 Log2N (N은 노드의 수)
편향 이진트리 (Skewed binary tree) : 트리의 노드가 왼쪽이나 오른쪽으로 한쪽으로만 있는 트리, N-1의 높이를 가짐
● 방향 그래프와 무방향 그래프
| 구분 | 무방향 그래프 (Undirected Graph) | 방향 그래프 (Directed Graph) |
| 개념도 |  |
 |
| 개념 | 정점과 정점을 연결하는 간선에 방향성이 없는 그래프 | 정점과 정점을 연결하는 선에 방향이 있는 그래프 |
| 최대 Edge 수 | 정점(V)이 n개 있다면, 최대 간선(E) = n(n-1)/2 | 두 정점에 대하여 방향이 다른 두 개의 간선을 연결할 수 있음 최대 간선(E) = n(n-1) → 무방향 그래프보다 2배 많음 |
● 전위/중위/후위 표기법 (prefix/infix/postfix)
(A + B) * C + (D + E) 가 있을때,
중위 표기법 → 전위 표기법 (연산 순서가 빠른 순으로 연산자를 그 연산을 수행하는 변수 앞으로 옮긴다)
① + A B * C + (D + E)
② * + A B C + (D + E)
③ * + A B C + + D E
④ + * + A B C + D E
중위 표기법 → 후위 표기법 (연산 순서가 빠른 순으로 연산자를 그 연산을 수행하는 변수 뒤로 옮긴다)
① A B + * C + (D + E)
② A B + C * + (D + E)
③ A B + C * + D E +
④ A B + C * D E + +
● 소스코드 커버리지 유형
| 구문 커버리지 (Statement Coverage) |
소스코드 구문에 대한 단순한 실행 여부 측정 조건문의 결과와 관계없이 구문이 실행된 개수로서 계산 |
| 결정 커버리지 (Decision Coverage) |
결정 조건 내의 전체 조건식이 최소한 참/거짓 한번의 값을 가지도록 측정 |
| 조건 커버리지 (Condition Coverage) |
전체 조건식의 결과와 관계없이 각 개별 조건식이 참/거짓 한번 모두 갖도록 개별 조건식을 조합 |
| 조건/결정 커버리지 (Condition/Decision Coverage) |
전체 조건식이 참/거짓 한번씩 가지면서, 개별 조건식이 참/거짓 모두 한번씩 갖도록 조합 |
| 변경조건/결정 커버리지 (Modified Condition/Decision Coverage) |
각 개별 조건식이 다른 개별 조건식에 무관하게 전체 조건식의 결과에 영향 |
| 다중조건 커버리지 (Multiple Condition Coverage) |
결정 조건 내의 모든 개별 조건식의 모든 가능한 논리적 조합 100% 보장 |
● 젠킨스 (Jenkins)
젠킨스 = 빌드 자동화 도구로서 가장 많이 활용되는 도구. Java 기반의 오픈 소스로 지속적 통합관리(CI)를 가능하게 함. Apache-tomcat과 같은 서블릿 컨테이너 서버 기반으로 구동되는 시스템이며, CVS, SVN, Git 등 다양한 버전관리 도구를 지원함.
젠킨스의 특징
- 쉬운 설치 : Jenkins.war 파일로 제공하며 "java -jar jenkins.war" 명령어로 설치 끝
- 친숙한 GUI : 웹 기반 GUI를 통해 쉽게 전체적인 설정 변경 가능. 잘못된 내용은 바로 체크하여 inline help를 제공.
- 저장소 부하 감소 : 버전관리 도구에서 빌드에 사용될 목록만 따로 추출하여 변경 생성할 수 있는 기능을 제공. 전체 빌드로 인한 저장소 부하 감소 가능
- 실시간 피드백 : RSS 또는 e-mail을 통해 실시간으로 빌드 실패 내역에 대해 담당자에게 통지 가능
- 분산 빌드 : 여러대의 컴퓨터를 통해 분산 빌드나 테스트가 가능함
- 3rd-party 플러그인 : 젠킨스는 타 도구의 통합을 지원함. 데이터베이스, 개발도구(eclipse)와의 통합. 테스트 도구(JUnit)와의 통합
● 소프트웨어 테스트의 기본 원칙
| 테스팅은 결합이 존재함을 밝히는 활동이다 | 테스팅은 소프트웨어의 잠재적인 결함을 줄일 수 있지만, 결함이 발견되지 않아도 결함이 없다고 증명할 수 없음을 나타냄 |
| 완벽한 테스팅은 불가능하다 | 무한 경로, 무한 입력 값, 무한 시간이 소요되어 완벽하게 테스트할 수 없으므로 리스크 분석과 우선순위를 토대로 테스트에 집중할 것을 의미함 |
| 테스팅은 개발 초기에 시작해야 한다 | 애플리케이션의 개발 단계에 테스트를 계획하고 SDLC(Software Development Life Cycle)의 각 단계에 맞춰 전략적으로 접근하는 것을 고려하라는 뜻 요르돈 법칙(or Snow Ball 효과)은 문제를 관리하지 않고 방치하여 시간이 지날수록 상황이 더욱 악화되는것을 의미 하인리히 법칙(= 1:29:300의 법칙)은 어떤 대형 사고가 발생하기 전에는 그와 관련된 수십 차례의 경미한 사고와 수백번의 징후들이 반드시 나타난다는 것을 뜻하는 통계적 법칙 |
| 결함 집중 (Defect Clustering) | 애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재한다는 의미 (파레토 법칙) |
| 살충제 패러독스 (Pesticide Paradox) | 동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고 개선해야 함 |
| 테스팅은 정황(Context)에 의존한다 | 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행하여야 함 |
| 오류 - 부재의 궤변 (Absence of Errors Fallacy) | 이 세상에 어떠한 소프트웨어도 오류가 완벽하게 해소된 제품을 만들어 낼 수 없음을 의미함. 테스트는 오류를 100% 없애는 것이 목적이 아닌 일정 수준이하로 줄이는 것이 목적 |
● V-모델
● V-모델의 V & V
검증 (Verification) : 개발자 관점에서의 시스템 검증 활동. 개발하고 있는 시스템이 미리 정의한 사양에 부합하고 있는지를 검증. 제품을 제대로 만들고 있느냐 검증 (화이트박스 테스트)
확인 (Validation) : 사용자 관점에서의 시스템 검증 활동. 개발 완료된 시스템이 사용자의 요구 사항을 충족하는지 확인. 제품이 제대로 만들어 졌느냐 확인 (블랙박스 테스트)
● 테스트 레벨에 따른 테스트의 유형
단위 테스트 - 구현된 단위 모듈(함수, 서브루틴, 컴포넌트 등)의 기능 수행 여부를 판정하고 내부에 존재하는 논리적 오류를 검출함
통합 테스트 - 모듈간의 인터페이스 연계를 검증하고 오류를 확인, 모듈간의 상호작용 및 연계동작이 제대로 기능하는지 점검
시스템 테스트 - 단위, 통합 테스트 후 전체 시스템이 정상적으로 작동하는지 판정하는 기능을 점검
인수 테스트 - 사용자 요구분석 명세서에 명시된 사항을 모두 충족하는지 판정하고 시스템이 예상대로 동작하고 있는지 점검
인수테스트
- 알파 테스트 : 개발자의 장소에서 사용자가 개발자 앞에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 검사하는 기법 (즉, 개발자 환경에서 테스트하는 기법)
- 베타 테스트 : 다수의 사용자를 제한되지 않은 환경에서 프로그램을 사용하게 하고 오류가 발견되면 개발자에게 통보하는 방식 (즉, 사용자 환경에서 테스트하는 기법)
● 단위 모듈 테스트 방법
① 화이트박스 테스트
- 단위 모듈 테스트의 가장 기본적인 방법은 모듈 내부의 소스를 보면서 수행하는 화이트박스 테스트
- 소스 코드를 보면서 테스트 케이스를 다양하게 만들어서 테스트 가능
② 메서드 기반 테스트
- 단위 모듈의 외부에 공개된 메서드 기반 테스트
- 메서드의 파라미터 값을 다르게 호출하면서 다양한 테스트 수행
③ 화면 기반 테스트
- 사용자용 화면이 있는 경우 각각의 화면 단위로 단위 모듈 개발 후 화면에 직접 데이터를 입력하여 테스트 수행
- 화면 기반 테스트는 화면과 연계된 서비스 컴포넌트, 비즈니스 컴포넌트 및 공통 컴포넌트를 한꺼번에 단위 테스트에 참여시킬 수 있음
- 사용자 시나리오에 기반한 단위 모듈 테스트를 할 수 있는 것이 장점
④ Stub과 Driver 활용
- 사용자용 화면, 하위 모듈(서비스 컴포넌트, 비즈니스 컴포넌트) 등과 같이 테스트 수행에 필요한 다른 모듈 개발이 안 된 경우 스텁과 드라이버를 활용하여 단위 테스트
● 화이트박스 검사 기법 유형
| 기본 경로 | Tom McCabe가 제안한 대표적인 화이트박스 테스트 기법 수행 가능한 모든 경로 검사 |
| 반복경로 검사 (루프 검사) |
프로그램의 반복 구조에 초점을 맞추어 검사 |
| 조건 검사 (Condition Testing) |
프로그램의 조건문에 초점을 맞추어 검사 |
| 제어 구조 검사 | ① Condition Testing : 프로그램 모듈 내 논리적 조건 검사 ② Loop Testing : 반복구조에 초점, 검사사례기법 (단순, 중첩, 연결, 비구조적 루프) ③ Data Flow Testing : 프로그램 변수의 정의와 사용 위치 초점 |
| 데이터 흐름 검사 | 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞추어 검사 |
● McCabe's cyclomatic
McCabe's cyclomatic = 프로그램의 복잡도를 나타내는데 사용되는 척도. 회전복잡도나 순환복잡도 등으로 불림
프로그램에 분기(반복문, 조건문)가 많다면 node에 비해 edge가 많아지고, 이에 따라 프로그램이 얼마나 복잡한지를 판단할 수 있는 방법
회전복잡도 계산 방법 :
1) edge수 - node수 + 2P
2) 분기 수 + 1
3) 폐구간 수 + 1
● 블랙박스 검사 기법 유형
| 동등분할 기법 (Equivalent Analysis), 동치 분할 검사 | 입력값의 범위를 유사한 특징을 갖는 동등 그룹으로 나누고, 각 그룹마다 대표값을 선정하여 테스트케이스를 선정하는 기법 |
| 경계값 분석 기법 (Boundary Value Analysis) |
경계값 분석은 등가 분할된 경계의 유효한 값과 경계에서 가장 가까운 유효하지 않는 값을 테스트 데이터로 선택하여 컴포넌트나 시스템을 테스트하는 기법 |
| 원인 효과 그래프 기법 (Cause Effect Graph) |
입력값을 원인으로, 효과를 출력 값으로 정하고 이에 따른 원인 결과 그래프를 만들어서 테스트 케이스를 작성하는 기법 |
| 결정 트리 (Decision Tree) | 입력값과 출력값을 트리형태로 만들어서 특정 입력값에 따라서 결정되는 출력값이 정해지도록 만든 테스트 케이스 작성 기법 |
| 비교 검사 (Comparison Testing) | 동일 입력이 다른 버전에서도 동일한 결과를 출력하는지 검사 |
● Selection sort (선택정렬)
Selection sort = 루프를 돌면서 최소값을 앞쪽으로 보내는 정렬방식
ex) 37, 14, 17, 40, 35 정렬 시
① 14, 37, 17, 40, 35 → ② 14, 17, 37, 40, 35 → ③ 14, 17, 35, 40, 37 → ④ 14, 17, 35, 37, 40
● Quick sort (퀵 정렬)
Quick sort = Pivot을 중심으로 데이터를 분할하고, 왼쪽은 작은 값, 오른쪽은 큰 값으로 위치시키는 행위를 반복하는 분할 정복 방식의 정렬
● Merge sort (병합 정렬)
Merge sort = 데이터를 싸그리 분할 한 후, 병합하면서 정렬을 수행
● Bubble sort (버블 정렬)
Bubble sort = 여러 개의 자료 중 서로 이웃하는 값을 두개씩 비교 및 교환하는 정렬 기법
● Insertion sort (삽입 정렬)
Insertion sort = 첫 번째 key는 정렬된 것으로 간주하고, 두 번째 key부터 순서에 맞는 위치에 삽입시켜 정렬
ex) 5, 4, 3, 2, 1 정렬 시
① 4, 5, 3, 2, 1 → ② 3, 4, 5, 2, 1 → ③ 2, 3, 4, 5, 1 → ④ 1, 2, 3, 4, 5
● 이진 탐색 (Binary search)
이진 탐색 = 비교횟수를 거듭할 때마다 검색 대상이 되는 데이터의 수가 절반으로 줄어듦
장점 - 시간복잡도가 O(log2N)으로 빠르게 탐색 가능
단점 - 검색할 데이터가 정렬되어 있어야 함
● 상향식 통합 (Bottom up)
- 애플리케이션 구조에서 최하위 레벨의 컴포넌트로부터 위쪽 방향으로 제어 경로를 따라 이동하면서 테스트를 시작.
- 최하위 레벨의 컴포넌트들이 하위 컴포넌트의 기능을 수행하는 클러스터로 결합됨
- 상위 컴포넌트 개발이 수행하지 못한 경우 더미 컴포넌트들인 드라이버(Driver)를 작성해 각 통합된 클러스터 단위를 테스트 수행. 이후 테스트가 완료되면 각 클러스터들은 프로그램의 위쪽으로 결합되며, 드라이버는 실제 컴포넌트로 대체됨
● 하향식 통합 (Bottom down)
- 메인 제어 컴포넌트로부터 아래 방향으로 제어의 경로를 따라 이동하면서 하향식으로 통합하며 테스트 진행
- 메인 제어 컴포넌트는 작성된 프로그램을 사용하고, 아직 작성되지 않은 하위 제어 컴포넌트 및 모든 하위 컴포넌트를 대신하여 더미 컴포넌트인 스터브(Stub)를 개발함
- 깊이 우선 방식 또는 너비 우선 방식에 따라, 하위 컴포넌트인 스텁이 한번에 하나씩 실제 컴포넌트로 대체됨
- 하향식 통합 검사 기법도 검사 초기에는 시스템의 구조를 사용자에게 보여줄 수 있음
● 회귀 테스트 (Regression Testing)
회귀 테스트 = 테스트를 완료한 컴포넌트가 어떠한 변화로 인해 의도하지 않은 오류가 생기지 않았음을 보증하기 위해 기존의 테스트 케이스로 다시 테스트하는 것
회귀 테스트 케이스 선정 기준 : 실제 수정이 발생한 컴포넌트와 관련된 테스트 케이스를 도출. 이를 위하여 변경 관리 도구를 사용하여 애플리케이션 변경 영향도 분석을 함. / 변경 영향도가 가장 높은 컴포넌트 기능에 집중한 회귀 테스트 케이스를 도출.
● 테스트 오라클
테스트 오라클 = 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여 비교하는 기법 및 활동
테스트 오라클의 유형 :
① 참(True) 오라클 = 모든 입력 값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클
② 샘플링(Sampling) 오라클 = 특정한 몇 개의 입력 값에 대해서만 기대하는 결과를 제공해 주는 오라클
③ 휴리스틱(Heuristic) 오라클 = 샘플링 오라클을 개선한 오라클로, 특정 입력 값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클
④ 일관성 검사(Consistent) 오라클 = 애플리케이션 변경이 있을 때, 수행 전과 후의 결과 값이 동일한지 확인하는 오라클
● Plan - driven 소프트웨어 프로세스
계획 기반 개발(Plan-driven development)은 소프트웨어를 개발하는 과정에서 계획을 세우고 그 계획을 실천하는데 많은 시간과 노력을 할애하는 개발 방법
1. Requirements specification → 2. Acceptance test plan → 3. System specification → 4. System integration test plan → 5. System design → 6. Sub system integration test plan → 7. Detailed design → 8. Module and unit code and test → 9. Sub system integration test → 10. System integration test → 11. Acceptance test → 12. Service
● 자동화 도구 유형
| 설계 단계 | 명세 기반 테스트 설계 도구 | 소프트웨어 명세로부터 테스트 절차, 데이터, 드라이버 등 생성 |
| 코드 기반 테스트 설계 도구 | 소스 코드로부터 테스트 절차, 데이터, 드라이버 등 생성 | |
| 테스트 관리 도구 | 테스트 계획 수립, 프로세스 관리, 요구사항 및 결함 추적 관리 | |
| 구현/테스트 단계 | 정적 분석 도구 | 프로그램을 수행하지 않고 분석하는 도구, 복잡도 측정 등 |
| 리뷰 및 인스펙션 도구 | 소스 코드/설계 문서를 분석하여 가이드라인 및 규칙 준수 검사 | |
| 커버리지 측정 도구 | 주어진 테스트케이스에 의해 얼마나 테스트 되었는가를 측정 | |
| 동적 분석 도구 | 프로그램이 수행되는 동안 이벤트의 상태를 파악하기 위하여 특정한 변수나 조건의 스냅샷(snapshot)을 생성 및 활용 | |
| 성능/부하/시뮬레이션 도구 | 시스템 부하를 생성하고, 반응시간 및 메모리 사용량 평가 | |
| 기능 테스트 수행 도구 | 주어진 테스트 케이스 자동 수행, 예상 결과와 비교 단위, 통합, 시스템, 인수의 모든 단계에서 수행 |
● 정적 분석 도구 유형
프로그램을 수행하지 않고 분석하는 도구로서 복잡도 측정 및 호출 관계를 분석할 수 있는 도구
- 구조 검사 도구 : 소프트웨어의 내부 구조를 검사할 수 있는 도구
- 데이터 분석 도구 : 소프트웨어의 내부 데이터 흐름을 분석할 수 있는 도구
- 순서 검사 도구 : 소프트웨어의 실행 순서를 분석할 수 있는 도구
● 알고리즘 기법
| 분할과 정복 (Divide and conquer) |
문제를 해결 가능한 부분 문제로 분할하고, 부분 문제의 답을 기반으로 전체 문제 답을 해결 (부분 문제들은 서로 독립적인 관계) |
| 동적 계획법 (Dynamic programming) |
입력 크기가 작은 부분 문제들을 모두 해결한 후에 그 해들을 이용하여 보다 큰 크기의 부분 문제들을 해결하여, 최종적으로 원래 주어진 입력의 문제를 해결하는 알고리즘 어떤 문제를 풀기 위해 그 문제를 더 작은 문제의 연장선으로 생각하고 과거에 구한 해를 활용하는 방식 (부분 문제들은 서로 의존적인 관계) |
| 탐욕법 (Greedy) |
빠른 문제 해결을 위해 근사해 계산 기법 (최적해는 아님) |
| 백트래킹 (Backtracking) |
어떤 노드의 유망성을 점검하고 유망하지 않으면 그 노드의 부모 노드로 돌아간 후 다른 자손의 노드를 검색하는 알고리즘 |
● ESB(Enterprise Service Bus) 구축 방식
ESB = 웹 서비스 중심으로 표준화된 데이터, 버스를 통해 이기종 애플리케이션을 유연하게(loosely coupled) 통합하는 핵심 플랫폼 기술. 애플리케이션 간 통합 측면에서 EAI(Enterprise Application Integration)와 유사하지만, 어플리케이션보다 서비스 중심의 통합을 지향하는 아키텍처
| 구분 | EAI | ESB |
| 통합 | 비즈니스 로직을 중심으로 Application 통합 | 프로세스 관점으로 서비스를 통합 |
| 표준 | 벤더 종속적 기술 | 표준 기술(Web service, XML) |
| 아키텍처 | 중앙 집중 | 버스구조의 느슨한 연결 구조 |
| 통합범위 | 기업 내부 | 기업 내/외부 |
| 로직연동 | 개별 app에서 수행 | ESB에서 수행 |
● AJAX (Asynchronous JavaScript and XML)
AJAX = JavaScript를 이용하여 비동기적으로 서버와 브라우저가 데이터를 주고받는 방식
서버와 클라이언트 간 XML 또는 JSON을 주고받으며, XMLHttpRequest 객체를 이용
페이지의 일부만 갱신하기 때문에 기존의 방식보다 속도가 빨라 사용자에게 즉각적인 응답을 제공
기존 웹과 AJAX 비교 :
| 구분 | 예전 방식의 웹 서비스 | AJAX를 이용한 웹 서비스 |
| 개념도 |  |
 |
| 요청 객체 | HttpRequest | XMLHttpRequest |
| 수신 데이터 | HTML + Resource (이미지 등) | XML (최근에는 JSON을 많이 사용) |
| 특징 | 페이지 전체 새로고침 → 느림 | 페이지 일부만 갱신 → 빠름 |
● 해싱
해싱 = 데이터의 신속한 검색을 위해 Key 값에 해시 함수를 적용하여 주소값을 빠르게 계산하고 레코드가 저장된 위치를 직접 접근하는 방법
| 버킷 (Bucket) |
동일한 해시 주소를 갖는 레코드(키와 주소쌍)들이 저장될 메모리 블록을 의미하며, 버킷의 크기에 따라 같은 해시 주소에 저장될 수 있는 레코드의 수가 결정 |
| 슬롯 (Slot) |
1개의 해시 레코드를 저장할 수 있는 공간을 의미하며 n개의 슬롯이 모여 하나의 버킷을 이룸 |
| 충돌 (Collision) |
해시 레코드를 삽입할 때 서로 다른 2개 이상의 데이터가 같은 해시 주소를 갖는 현상 |
| 동거자 (Synonyms) |
해시 함수가 같은 주소로 변환시키는 모든 레코드를 동가자라고 하며 충돌이 일어난 레코드들의 집합 |
| 오버플로우 (Overflow) |
계산된 해시 주소의 버킷 내에 저장할 공간이 없는 상태 |
● 해싱함수의 유형
| 계수 분석 | 키 값을 구성하는 숫자의 분포를 파악하여 분포가 비교적 고른 자리부터 필요한 자리만큼 선택하여 레코드 주소를 결정하는 방법 |
| 제산법 | 키를 임의의 양의 정수로 나눈 나머지를 그 키의 레코드 저장하는 주소로 결정하는 방법 |
| 중간 제곱법 | 키 값을 제곱한 값의 중간 부분 값을 선택하여 레코드 주소로 결정하는 방법 |
| 폴딩법 (중첩법) |
키를 여러 부분으로 나누고, 나누어진 각 부분의 값을 모두 더하거나 보수를 취해 더하여 레코드 주소를 결정하는 방법 길이를 동일하게 여러 부분으로 나누고, 더하거나 XOR하여 주소 이동 |
| 기수 변환 | 주어진 키 값을 어떤 특정한 진법의 수로 간주하여 다른 진법으로 변환한 후 레코드 주소를 구하는 방법 |
| 숫자 분석 | 각 숫자의 분포를 이용해서 균등한 숫자를 선택해서 사용 |
| 무작위 방법 | 난수를 발생, 탐색을 위한 해시의 경우 충돌이 발생하면 다음 난수를 이용 |
● 해싱 오버플로우 해결 방법
| 선형 개방 주소법 | 충돌이 발생한 다음 위치에서 차례로 검색하여 첫 번째 빈 공간에 저장 레코드 전체 개수를 미리 예측 가능할 경우 적용 가능 |
 |
| 체인(Chain) 법 | 오버플로가 발생한 레코드를 별도의 버킷으로 연결하여 저장 링크를 위한 오버헤드(Overhead)가 발생하며, 레코드 개수를 예측하기 어려울 경우 적용 |
 |
| 다중 해싱법 (확장 해싱) |
Key의 처음 bit를 이용하여 디렉토리를 통해 버킷에 접근가능 버킷에 오버플로가 발생할 경우 새로운 버킷을 생성하고 디렉토리의 포인터를 변경하거나 디렉토리를 확장 |
 |
● 소프트웨어 공학의 3R
3R은 역공학(Reverse-Engineering), 재공학(Re-Engineering), 재사용(Re-Use)을 통해 소프트웨어 생산성을 극대화하는 기법
| 역공학 (Reverse-Engineering) |
기존에 개발된 시스템을 CASE(자동화 도구)를 이용하여 사양서, 설계서 등의 문서로 추출하는 작업. 개발단계를 역으로 올라가 기존 개발된 시스템의 코드, 데이터로부터 설계명세서나 요구분석서를 도출하는 작업 |
| 재공학 (Re-Engineering) |
기존 시스템을 널리 사용되는 프로그램 표준에 맞추거나 고수준의 언어로 재구성하여 타 하드웨어에서 사용할 수 있도록 변환하는 작업 |
| 재사용 (Re-Use) |
이미 개발되어 기능, 성능, 품질을 인정받았던 소프트웨어 전체 또는 일부분을 다시 사용하는 기법 |
● 소프트웨어 제공학
| 개념 | 기존 소프트웨어를 버리지않고 기능을 개선시키거나 기능을 새로운 소프트웨어로 재활용하는 공법 | |
| 장점 | 소프트웨어의 유지보수성과 품질을 향상시킬 수 있음 부작용을 미연에 발견하여 위험부담 제거 및 복구비용 절감 예방 유지보수 측면에서 소프트웨어 위기 해결 |
|
| 유지보수측면 | 예방적 유지보수에 해당 유지보수의 유형 : - 완전적 유지보수 = 기능추가 및 품질/성능의 개선 - 적응적 유지보수 = 환경변화에 적응(데이터 환경, 인프라 환경 등) - 예방적 유지보수 = 신뢰성 및 장래의 유지보수 용이성 향상 (재공학) - 수정적 유지보수 = 잠재적 오류 및 하자의 원인을 찾아 해결 |
|
| 주요 활동 | 분석 (Analysis) |
기존 소프트웨어 명세를 확인하여 동작을 이해하고 재공학 대상을 선정 재공학 가치판단 및 재공학 여부 판단 |
| 재구성 (Restructuring) |
소프트웨어 구조를 향상시키기 위해 코드를 재구성 소프트웨어의 기능과 외적인 동작은 변경되지 않음 |
|
| 역공학 (Reverse Engineering) |
소프트웨어 동작 과정 및 설계 정보를 재발견 혹은 재생성 소프트웨어를 구성하는 원시 코드를 복구하는 작업 원시 코드로부터 설계정보 추출 및 절차 설계표현, 프로그램과 데이터 구조 정보 추출 역공학의 가장 오래된 형태는 재문서화 |
|
| 이관 (Migration) |
기존 소프트웨어를 다른 운영체제, 하드웨어, 프레임워크 등에서 사용할 수 있도록 변환 재구성 또는 재개발을 통한 새로운 소프트웨어에 기존 데이터를 옮겨담는 작업 |
|
● 소프트웨어 패키징 도구 활용 시 고려사항
1. 반드시 암호화/보안을 고려
2. 다양한 이기종 연동을 고려 - 이기종 컨텐츠 및 단말기 간 DRM 연동을 고려
3. 사용자 편의성을 위한 복잡성 및 비효율성 문제를 고려
4. 애플리케이션의 종류에 적합한 암호화 알고리즘 적용
5. 지속적 배포 (CD, Continuous Deployment)를 고려 - CI(Continuous Integration)와 연계한 지속적 배포를 고려 / 짧은 주기의 배포를 여러번 함으로써 빠른 제품 출시 효과를 볼 수 있음.
● 네트워크 영역에 적용되는 보안 프로토콜
| IPSec | IPSec(Internet Protocol Security)은 통신 세션의 각 IP패킷을 암호화하고 인증하는 안전한 인터넷 프로토콜(IP) 통신을 위한 인터넷 프로토콜 스위트 이 보안은 통신 세션의 개별 IP패킷을 인증하고 암호화함으로써 처리됨 |
| TLS (SSL) |
3.0 버전부터 SSL은 TLS(Transport Layer Security)로 표준화됨 전송 계층 보안(Secure Sockets Layer, SSL)은 컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 규약 인터넷 같은 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층 종단간 보안과 데이터 무결성을 확보해줌 현재 TLS 1.3 버전 |
| S-HTTP | S-HTTP(Secure Hypertext Transfer Protocol)는 웹 상에서 네트워크 트래픽을 암호화하는 주요 방법 중 하나 |
● 데이터 모델링
- 현실 세계의 사용자 요구사항을 컴퓨터 세계의 정보구조로 변환하기 위하여 실체(Entity)와 관계(Relation)를 중심으로 분석/설계하여 점차 자료구조를 만들어가는 과정
데이터 모델링 절차 : ① 요구사항 분석 > ② 개념적 모델링 > ③ 논리적 모델링 > ④ 물리적 모델링
댓글