[정보처리기사 필기] 2과목 키워드 정리

2. 소프트웨어 개발

2.1 데이터 입출력 구현

배열

- 동일한 자료형의 데이터들이 같은 크기로 나열되어 순서를 갖고 있는 집합.

- 정적인 자료구조로 기억 장소의 추가가 어렵고 데이터 삭제 시 빈 공간이 남아있어 메모리 낭비 발생.

- 반복적인 데이터 처리 작업에 적합.

 

선형 리스트

- 일정한 순서에 의해 나열된 자료 구조.

- 배열을 이용하는 연속 리스트, 포인터를 이용하는 연결 리스트.

- 연속 리스트: 기억장소 이용 효율은 밀도가 1로 가장 좋음. 데이터 삽입을 위해서 연속적인 빈 공간이 있어야 하며 삽입, 삭제 시 자료의 이동이 필요함.

 

연결 리스트

- 자료들을 반드시 연속적으로 배열시키지는 않고 임의의 기억 공간에 기억시키되, 자료 항목의 순서에 따라 노드의 포인터 부분을 이용하여 연결시킨 자료 구조.

- 노드의 삽입, 삭제 작업이 용이.

- 연결을 위한 포인터를 찾는 시간이 필요하기 때문에 접근 속도가 느림.

 

스택

- 한 쪽 끝으로만 자료 삽입, 삭제 작업이 이루어짐,. 후입 선출 방식.

- 스택의 모든 기억 공간이 꽉 채워져 있는 상태에서 데이터가 삽입되면 오버플로우 발생. 더이상 삭제할 데이터가 없는 상태에서 데이터를 삭제하면 언더 플로 발생

 

트리

- 정점과 선분을 이용하여 사이클을 이루지 않도록 구성한 그래프.

- 디그리(Degree): 각 노드에서 뻗어 나온 가지 수

- 트리의 디그리: 노드의 디그리 중에서 가장 많은 수

- Level 끝 = Depth

 

데이터베이스

- 통합된 데이터: 자료의 중복을 배제한 데이터의 모임.

- 저장된 데이터: 컴퓨터가 접근할 수 있는 저장 매체에 저장된 자료.

- 운영 데이터: 조직의 고유한 업무를 수행하는데 존재 가치가 확실하고 없어서는 안 될 반드시 필요한 자료.

- 공용 데이터: 여러 응용 시스템들이 공동으로 소유하거 유하는 자료.

 

DBMS

- 필수기능: 정의, 조작, 제어(무결성, 권한 검사, 병행 제어)

- 데이터의 독립성: 논리적 독립성(응용 프로그램과 데이터베이스 독립 시킴), 물리적 독립성(응용 프로그램과 보조기억장치 같은 물리적 장치와 독립 시킴)

 

SQL

- 관계 대수와 관계 해석에 기초한 혼합 데이터 언어

- 질의어이면서 정의, 조작, 제어 기능 갖춤. :

 

2.2 통합 구현

IPC(Inter Process Communication)

- 모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합. 복수의 프로세스 간 통신까지 구현이 가능.

- 대표 메소드: Shared Memory, Socket, Semaphores, Pips&named Pipes, Message Queueing

 

테스트 케이스

- 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서.

- 명세 기반 테스트의 설계 산출물에 해당.

- 단위 모둘을 테스트하기 전에 데스트에 필요한 입력 데이터, 테스트 조건, 예상 결과 등을 모아 테스트 케이스를 만든다.

- ISO / IEC / IEEE 29919-3 표준에 따른 구성요소

s 식별자: 항목 식별자, 일련 번호

s 테스트 항목: 테스트 대상(모듈 또는 기능)

s 입력 명세: 입력 데이터 또는 테스트 조건

s 출력 명세: 테스트 케이스 수행 시 예상되는 출력 결과

s 환경 설정: 필요한 하드웨어나 소프트웨어 환경

s 특수 절차 요구

s 의존성 기술: 테스트 케이스 간의 의존성

 

단위 모듈 테스트

- 프로그램의 단위 기능을 구현하는 모듈이 정해진 기능을 정확히 수행하는 검증하는 것.

- 단위 테스트라고도 하며, 화이트박스 테스트와 블랙박스 테스트 기법을 사용.

- 시스템 수준의 오류는 잡아낼 수 없음.

 

테스트 프로세스

- 계획 및 제어 단계: 테스트 목표를 달성하기 위한 계획을 수립 및 제어하는 단계.

- 분석 및 설계 단계: 테스트 목표를 구체화 하여 테스트 시나리오(테스트 케이스를 묶은 집합)와 테스트 프로시저를 작성하는 단계

- 구현 및 실현 단계: 테스트 케이스들을 조합하여 테스트 프로시저(테스트 케이스의 실행 순서)를 명세하는 단계. 테스트 수행

- 평가 단계: 평가하고 기록

- 완료 단계: 수행 과정과 산출물을 기록 및 저장

 

IDE

- 통합 개발 환경은 개발에 필요한 환경(편집기, 컴파일러, 디버거)등의 다양한 툴을 하나의 인터페이스로 통합하여 제공하는 것.

- 이클립스, 비주얼 스튜디오, 엑스 코드, 안드로이드 스튜디오, IDEA

 

빌드 도구

- 빌드: 소스코드 파일들을 컴퓨터에서 실행할 수 있는 제품 소프트웨어로 변환하는 과정 또는 결과물.

- 빌드 도구: 소스코드를 소프트웨어로 변환하는 과정에 필요한 전처리, 컴파일 등의 작업들을 수행하는 소프트웨어.

- 대표적으로 Ant, Maven, Gradle

 

Ant

- 아파치 소프트웨어 재단에서 개발한 소프트웨어로 자바 프로젝트의 공식적인 빌드 도구로 사용되고 있음.

- XML 기반의 빌드 스크립트를 제공. 자유도와 유연성이 높아 복잡한 빌드 환경에서도 대처 가능.

- 정해진 규칙이나 표준이 없이 개발자가 모든 것을 정의하며 스크립트의 재사용이 어려움.

 

Maven

- Ant와 동일한 아파치 소프트웨어 재단에서 대안으로 개발.

- 규칙이나 표준이 존재하여 예외 사항만 기록하면 됨.

- 컴파일과 빌드를 동시에 수행할 수 있음.

- 의존성을 설정하여 라이브러리를 관리.

 

Gradle

- 안드로이드 스튜디오의 공식 빌드 도구

- 한스 도커 외 6인의 개발자가 공동 개발.

- 의존성 활용하여 그루비 기반의 빌드 스크립트를 사용.

 

2.3 제품 소프트웨어 패키징

소프트웨어 패키징

- 모듈별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것.

- 개발자가 아닌 사용자 중심으로 진행.

- 소스코드는 향후 관리를 고려하여 모듈화하여 패키징.

- 작업 순서

s 기능 식별: 코드의 기능 확인

s 모듈화: 확인된 기능 단위로 코드 분류

s 빌드 진행: 모듈 단위별 실행 파일 생성

s 사용자 환경 분석: 최소 운영 환경 정의

s 패키징 및 적용 시험: 배포용 파일 형식으로 패키징.

s 패키징 변경 개선: 불편사항 개선

s 배포: 오류 발생시 개발자에게 전달하여 수정 요청

 

릴리즈 노트

- 개발 과정에서 정리된 릴리즈 정보를 소프트웨어의 최종 사용자에게 공유하기 위한 문서.

- 소프트웨어 전체 기능, 서비스 내용, 개선 사항, 버전 관리.

- 작성 순서

s 모듈 식별: 모듈별 빌드 수행 후 작성될 내용 확인

s 릴리즈 정보 확인: 이름, 버전, 날짜 등 확인

s 릴리즈 노트 개요 작성: 변경사항 전체의 간략한 내용 작성.

s 영향도 체크: 버그나 이슈 관련 내용 등 기능 변화가 미칠 수 있는 영향에 대해 기술

s 정식 릴리즈 노트 작성

s 추가 개선 항목 식별

 

DRM

- 디지털 저작권 관리는 저작권자가 배포한 디지털 콘텐츠가 저작권자가 의도한 용도로만 사용되도록 디지털 콘텐츠의 생성, 유통, 이용까지의 전 과정에 걸쳐 사용되는 디지털 콘텐트 관리 및 보호 기술.

- 디지털 저작권 관리의 흐름도

s 클리어링 하우스: 저작권에 대한 사용 권한, 라이선스 발급, 사용량에 따른 결제 관리 등을 수행하는 곳.

s 콘텐츠 제공자: 콘텐츠를 제공하는 저작권자.

s 패키저: 콘텐츠를 메타 데이터와 함께 배포 가능한 형태로 묶어 암호화 하는 프로그램

s 콘텐츠 분배자: 암호화 하는 콘텐츠를 유통하는 곳이나 사람.

s 콘텐츠 소비자: 콘텐츠를 구매해서 사용하는 주체

s DRM 컨트롤러: 배포된 콘텐츠의 이용 권한을 통제하는 프로그램

s 보안 컨테이너: 콘텐츠의 원본을 안전하게 유통하기 위한 전자적 보안 장치

- 디지털 저작권 관리의 기술 요소: 암호화, 키 관리, 암호화 파일 생성, 식별 기술, 저작권 표현, 정책 관리, 그랙 방지, 인증

 

형상 관리(SCM; Software Configuration Management)

- 소프트웨어 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동.

- 기능: 형상 식별, 버전 제어, 형상 통제, 형상 검사, 형상 기록

- 소프트웨어 버전 등록 주요 용어

s Repository: 변경 내역에 대한 정보들이 저장되있는 곳

s Import: 빈 저장소에 처음으로 파일 복사

s Check-out: 저장소에서 파일 받아오기.

s Check-in: 저장소의 파일을 새로운 버전으로 갱신

s Commit: 갱신. 겹치면 충돌을 알리고 diff 도구로 수정해서 갱신 완료시킴.

s Update: 최신 버전으로 작업 공간 동기화

- 소프트웨어 버전 등록 과정

s Import: 신규 파일 추가

s Check-out: 저장소에 추가된 파일 인출

s Commit: 인출한 파일 수정 후 저장소에 예치

s Update: 작업 공간 동기호화

s Diff: 변경된 파일의 차이 확인

 

Subversion(SVN)

- 클라이언트/서버 방식의 버전 관리 도구로 서버에는 최신 버전의 파일들과 변경 내역이 관리됨. 아파치 소프트웨어 재단에서 발표.

- 서버의 자료를 클라이언트로 복사해와 작업한 후, 변경 대용을 서버에 반영(Commit).

- 모든 개발 작업은 trunk 디렉토리에서 수행, 추가 작업은 branches 디렉터리 안에 만들어서 merge. 커밋 할 때마다 리비전이 1씩 증가함.

- 주요 명령어

s Commit: 클라이언트 소스 파일을 서버 소스 파일에 적용.

s Checkout: 버전관리 정보 + 소스코드를 서버에서 클라이언트로 받아옴.

s Export: 버전 관리에 대한 정보 제외한 순수한 소스 파일만 서버에서 받아옴.

s Diff: 지정된 파일이나 경로에 대해 차이 표시

 

Git

- 분산 버전 관리 시스템으로 로컬 저장소(실제 개발을 진행하는 장소)와 원격 저장소(버전을 공동 관리하는 곳)가 존재.

- 파일의 변화를 스냅샷으로 저장해서 버전의 흐름 파악할 수 있음.

- 주요 명령어

s Add: 작업 내역을 스테이징 영역에 추가

s Commit: 작업 내역을 지역 저장소에 저장

s Branch: 새로운 브랜치 생성

s Checkout: 지정한 브랜치로 이동

s Merge: 두 브랜치 병합

s Init: 지역 저장소 생성

s Remote add: 원격 저장소에 연결

s Push: 변경 내역 원격 저장소에 반영

s Fetch: 변경 이력만 지역 저장소로 가져와 반영

s Fork: 지정한 원격 저장소의 내용을 복제

 

Jenkins

- JAVA 기반의 빌드 자동화 도구. 서블릿 컨테이너에서 실행되는 서버 기반 도구.

- SVN, Git등 대부분의 형상 관리 도구와 연동 가능.

- 친숙한 Web GUI 제공.

- 여러 대의 컴퓨터를 이용한 분산 빌드나 테스트 가능.

 

Gradle

- Groovy 기반으로 한 오픈 소스 형태의 자동화 도구로 안드로이드 앱 개발 환경에서 사용.

- Java, C/C++, Python 등의 언어에서도 빌드 가능.

- DSL(Domain Specific Language)을 스크립트 언어로 사용.

- 실행 처리할 명령들을 모아 테스크로 만든 후 테스크 단위로 실행.

- 이전에 사용했던 태스크를 재사용하거나 다른 시스템의 테스크를 공유할 수 있는 빌드 캐시 기능을 지원하므로 빌드의 속도를 향상시킬 수 있음.

 

​2.4 애플리케이션 테스트 관리

시각에 따른 테스트

- 검증 테스트(Verification): 개발자의 시각에서 제품의 생산 과정을 테스트 하는 것으로, 제품이 명세서대로 완성됐는지 테스트.

- 확인 테스트(Validation): 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것으로, 사용자가 요구한 대로 제품이 완성 됐는지를 테스트.

 

화이트박스 테스트

- 모듈의 원시코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법.

- 설계된 절차에 조점을 둔 구조적 테스트로 프로시저 설계의 제어 구조를 사용하여 테스트 케이스를 설계하며 테스트 과정의 초기에 적용된다.

- 모든 문장을 한 번 이상 실행함으로 수행된다.

- 프로그램의 제어 구조에 따라 선택, 반복 등의 분기점 부분들을 수행함으로써 논리적 경로를 제어한다.

- 종류

s 기초 경로 검사: 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 기법으로, 측정 결과는 실행 경로의 기초를 정의하는데 지침으로 사용됨.

s 제어 구조 검사: 조건 검사(논리적 조건을 테스트), 루프 검사(반복 구조에 초점을 맞춰 테스트), 데이터 흐름 검사(변수의 정의와 변수 사용의 위치에 초점)

- 검증 기준: 테스트 케이스가 얼마나 적정한지 판단 기준

s 문장 검증 기준: 모든 문장이 한번 이상 수행되도록

s 분기 검증 기준: 모든 조건문이 한 번 이상 수행되도록

s 조건 검증 기준: 모든 조건문에 대해 조건이 참인 경우과 거짓인 경우가 한번 이상 수행 되도록.

s 분기/조건 검증 기준: 모든 조건문과 그 안의 개별 조건문의 결과가 참인 경우와 거짓인 경우 한 번 이상 수행되도록.

 

블랙박스 테스트

- 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트. 기능 테스트.

- 요구사항 명세를 보면서 테스트, 인터페이스에서 실시되는 테스트. 테스트 과정의 후반부에 적용.

- 종류

s 동치 분할 검사: 입력 자료에 초점을 맞춰 테스트케이스를 만들고 검사. 입력 조건에 타당한 입력 자료와 그렇지 않은 자료의 개수를 균등하게 함.

s 경계값 분석: 중간값보다 경계값에서 오류가 발생할 확률이 높다는 점을 이용한 테스트.

s 원인-효과 그래프 검사: 입력-출력 관계에 영향 미치는 상황을 체계적으로 분석.

s 오류 예측 검사: 과거의 경험이나 확인자의 감각으로 테스트.

s 비교 검사: 여러 버전의 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트.

 

 

어플리케이션 개발 단계

- 소프트웨어 개발 단계: 요구사항 > 분석 > 설계 > 구현

- 테스트 단계: 단위 테스트 > 통합 테스트 > 시스템 테스트 > 인수 테스트

 

단위 테스트

- 소프트웨어의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트.

- 인터페이스, 외부적 I/O, 자료구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건 등을 검사.

- 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선으로 수행.

- 종류

s 구조 기반 테스트: 프로그램 내부 구조 및 복잡도를 검증하는 화이트박스 테스트 시행. 제어 흐름/조건 결정

s 명세 기반 테스트: 목적 및 실행 코드 기반의 블랙박스 테스트 진행. 동등 분할/경계값 분석

 

통합 테스트

- 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법.

- 비점진적 통합 방식: 한번에 통합, 규모가 작은 소프트웨어에 유리하고, 오류 위치 파악이 어려움.

- 점진적 통합 방식: 모듈 단위로 단계별 통합. 하향식, 상향식, 혼합식 통합 방법이 있다.

 

하향식 통합 테스트

- 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법.

- 깊이 우선 통합법, 넓이 우선 통합법.

- 테스트 초기부터 사용자에게 시스템 구조를 보여줄 수 있음.

- 스텁: 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로 일시적으로 필요한 조건만 가지고 있는 시험용 모듈.

 

상향식 통합 테스트

- 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법.

- 클러스터: 하위 모듈들을 결합한 것.

- 드라이버: 상위 모듈에서 입 출력을 확인하기 위해 더미 모듈.

 

어플리케이션 테스트 프로세스

- 테스트 계획 > 테스트 분석 및 디자인 > 테스트 케이스 및 시나리오 작성 > 테스트 수행 > 테스트 결과 평과 > 결함 추적 및 관리

 

테스트 케이스

- 구현된 소프트웨어가 사용자의 요구사항 정확하게 준수했는 지를 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서.

- 명세 기반 테스트의 설계 산출물

 

테스트 시나리오

- 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스들을 묶은 집합으로 테스트 케이스를 적용하는 구체적 절차를 명세한 문서.

- 테스트 순서에 대한 구체적 절차, 사전 조건, 입력 데이터 등이 설정되어 있음.

 

테스트 오라클

- 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법 및 활동.

- 결과를 판단하기 위해 테스트 케이스에 대한 예상 결과를 계산하거나 확인.

- 특징

s 제한된 검증: 모든 테스트 케이스에 적용할 수 없다.

s 수학적 기법: 수학적 기법을 이용해 구할 수 있다.

s 자동화 기능: 테스트 대상 프로그램의 실행, 결과 비교, 커버리지 측정 등을 자동화 할 수 있다.

- 종류

s 참 오라클: 모든 테스트 케이스 입력 값에 기대하는 결과를 제공하는 오라클로, 발생된 모든 오류를 검출 할 수 있음. 주로 항공기, 은행, 발전소 소프트웨어 등 미션 크리티컬한 업무에 사용.

s 샘플링 오라클: 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공.

s 추정 오라클: 특정 케이스의 입력 값에 대해 기대하는 결과를 제공하고, 나머지 입력값들에 대해서는 추정으로 처리하는 오라클.

s 일관성 검사 오라클: 애플리케이션의 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과값이 동일한지 확인하는 오라클.

 

 

2.5 인터페이스 구현

인터페이스 설계서

- 시스템 사이의 데이터 교환 및 처리를 위한 교환 데이터 및 관련 업무, 송, 수신 시스템에 대한 내용을 정의한 문서.

- 정적, 동적 모형(다이어그램)을 통한 인터페이스 설계서: 각 시스템의 구성 요소를 표현한 다이어그램을 통해 만든 설계서. 구성 요소간의 트랜잭션을 보여줌.

 

EAI

- Enterprise Application Integration

- 모듈 간 데이터의 교환을 위해 관계를 설정하는 모듈 연계 방법 중 하나로 기업 내의 각종 애플리케이션 및 플랫폼 간의 정보 전달, 연계 통합 등 상호 연동이 가능하게 해주는 솔루션.

- 비즈니스 간 통합 및 연계성을 증대시켜 효율성 및 각 시스템 간의 확정성을 높여줌.

- 구축 유형

s Point to Point: 1:1로 연결. 변경 및 재사용이 어려움.

s Hab & Spoke: 단일 접점인 허브 시스템을 통해 데이터를 전송하는 중앙 집중형 방식. 확장 및 유지 보수 용이.

s Message bus: 어플리케이션 사이에 미들웨어를 두어 처리하는 방식. 확장성이 뛰어나며 대용량 처리가 가능.

s Hybrid: Hub & Spoke + Message Bus. 데이터 병목화 현상을 최소화할 수 있다.

 

ESB

- Enterprise Service Bus

- 애플리케이션 간 연계, 데이터 변환, 웹 서비스 지원등 표준 기반의 인터페이스를 제공하는 솔루션.

- EAI 보다는 서비스 중심의 통합을 지향.

- 범용적으로 사용하기 위해서 결합도를 약하게 유지.

- 관리 및 보안 유지가 쉽고 높은 수준의 품질 지원이 가능.

 

모듈 세부 설계서

- 모듈의 구성 요소와 세부적인 동작 등을 정의한 설계서

- 컴포넌트 명세서: 컴포넌트의 개요, 내부 클래스의 동작. 인터페이스를 통해 외부와 통신하는 명세를 정의한 것.

- 인터페이스 명세서: 컴포넌트의 명세서 항목 중 인터페이스 클래스의 세부 조건 및 기능을 정의한 것.

 

JSON

- JavaScript Object Notation

- 속성-값 쌍으로 이루어진 데이터 객체를 전달하기 위해 사람이 읽을 수 있는 텍스트를 사용하는 개방형 표준 포맷

- 비동기 처리에 사용되는 AJAX에서 XML을 대체하여 사용.

 

XML

- 특수한 목적을 갖는 마크업 언어를 만드는데 사용되는 다목적 마크업 언어.

 

인터페이스 보안 기능

- 네트워크 영역: 인터페이스 송, 수신 간 스니핑 등을 이용한 데이터 탈취 등을 방지하기 위해 네트워크 트래픽에 암호화를 절정한다.

- 애플리케이션 영역: 소프트웨어 개발 보안 가이드를 참조하여 애플리케이션 코드 상의 보안 취약점을 보완하는 방향.

- 데이터베이스 영역: 데이터베이스, 스키마, 엔티티의 접근 권한과 프로시저, 트리거 등 데이터베이스 동작 객체의 보안 취약점에 보안 기능을 적용. 암호화나 익명화 등을 고려.

 

xUnit

- 인터페이스 구현 검증 도구 중 하나.

- Java, C++, .Net 등 다양한 언어를 지원하는 단위 테스트 프레임 워크

 

NTAF

- 인터페이스 구현 검증 도구 중 하나.

- FitNesse의 장점인 협업 기능과 STAF의 장점인 재사용 및 확장성을 통합한 NHN의 테스트 자동화 프레임 워크.

 

APM

- 애플리케이션의 성능 관리를 위해 접속자, 자원 현황, 트랜잭션 수행 내역, 장애 진단 등 다양한 모니터링 기능 제공하는 도구.

- 인터페이스 구현 감시 도구

- Application Performance Management/Monitoring

- 리소스 방식(Nagios, Zabbix, Cacti), 앤드투앤드 방식(VisualVM, 재니퍼, 스카우터)