2과목 -2 (필기 개념 정리)

 

1. 절차형 SQL의 테스트와 디버깅

(1) 절차형 SQL은 디버깅을 통해 기능의 적합성 여부를 검증 하고, 실행을 통해 결과를 확인하는 테스트 과정을 수행 한다.

(2) 테스트(Test)를 통해 오류를 발견한 후 디버깅(Debugging)을 통해 오류가 발생한 소스 코드를 추적하며 수정함

 

 

 

 

2. 단위 모듈(Unit Module)

(1) 소프트웨어 구현에 필요한 여러 동작 중 한 가지 동작을 수행하는 기능을 모듈로 구현한 것이다

(2) 단위 모듈로 구현되는 하나의 기능을 단위 기능이라고 부른다.
(3) 단위 모듈은 사용자나 다른 모듈로부터 값을 전달받아 시작되는 작은 프로그램을 의미하기도 한다.
(4) 두 개의 단위 모듈이 합쳐질 경우 두 개의 기능을 구현 할 수 있다.

(5) 단위 모듈의 구성 요소에는 처리문, 명령문, 데이터 구 조 등이 있다.
(6) 단위 모듈은 독립적인 컴파일이 가능하며, 다른 모듈에 호출되거나 삽입되기도 한다.
(7) 단위 모듈을 구현하기 위해서는 단위 기능 명세서를 작 성한 후 입·출력 기능과 알고리즘을 구현해야 한다.

 

 

 

 

3. IPC(Inter-Process Communication)

(1) 모듈 간 통신 방식을 구현하기 위해 사용되는 대표 적인 프로그래밍 인터페이스 집합으로, 복수의 프로세스 를 수행하며 이뤄지는 프로세스 간 통신까지 구현이 가능 하다.

(2) Shared Memory : 다수의 프로세스가 공유 가능한 메모리를 구성하 여 프로세스 간 통신을 수행

(3) Socket : 네트워크 소켓을 이용하여 네트워크를 경유하는 프로세스들 간 통신을 수행

(4) Semaphores : 공유 자원에 대한 접근 제어를 통해 프로세스 간 통신을 수행

(5) Pipes&named Pipes : Pipe’라고 불리는 선입선출 형태로 구성된 메모 리를 여러 프로세스가 공유하여 통신을 수행

(6) Message Queueing : 메시지가 발생하면 이를 전달하는 형태로 프로세 스 간 통신을 수행

 

 

 

 

4. 단위 모듈 테스트의 개요

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

(2) 단위 테스트(Unit Test)라고도 하 며, 화이트박스 테스트와 블랙박스 테스트 기법을 사용 한다. 

(3) 단위 모듈 테스트를 수행하기 위해서는 모듈을 단독적 으로 실행할 수 있는 환경과 테스트에 필요한 데이터가 모두 준비되어야 한다.
(4) 모듈의 통합 이후에는 오랜 시간 추적해야 발견할 수 있는 에러들도 단위 모듈 테스트를 수행하면 쉽게 발견 하고 수정할 수 있다. 
(5) 단위 모듈 테스트의 기준은 단위 모듈에 대한 코드이므 로 시스템 수준의 오류는 잡아낼 수 없다.

 

 

---

 

1. 테스트 케이스(Test Case)

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

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

(3) 테스트 케이스를 이용하지 않고 수행하는 직관적인 테 스트는 특정 요소에 대한 검증이 누락되거나 불필요한 검증의 반복으로 인해 인력과 시간을 낭비할 수 있다.

(4)ISO/IEC/IEEE 29119-3 표준에 따른 테스트 케이스의 구성 요소는 다음과 같다.
-  식별자(Identifier) : 항목 식별자, 일련번호
-  테스트 항목(Test Item) : 테스트 대상(모듈 또는 기능) - 입력 명세(Input Specification) : 입력 데이터 또는 테스
트 조건
-  출력 명세(Output Specification) : 테스트 케이스 수행 시 예상되는 출력 결과
-  환경 설정(Environmental Needs) : 필요한 하드웨어나 소프트웨어의 환경
-  특수 절차 요구(Special Procedure Requirement) : 테스 트 케이스 수행 시 특별히 요구되는 절차
-  의존성 기술(Inter-case Dependencies) : 테스트 케이스 간의 의존성

 

 

 

 

2. 통합 개발 환경(IDE; Integrated Development Environment)

(1) 코딩, 디버그, 컴파일, 배포 등 프로그 램 개발과 관련된 모든 작업을 하나의 프로그램에서 처 리할 수 있도록 제공하는 소프트웨어적인 개발 환경을 말 한다.

(2) 기존 소프트웨어 개발에서는 편집기(Editor), 컴파일러 (Compiler), 디버거(Debugger) 등의 다양한 툴을 별도 로 사용했으나 현재는 하나의 인터페이스로 통합하여 제공한다.

(3) 통합 개발 환경 도구는 통합 개발 환경을 제공하는 소 프트웨어를 의미한다.

(4) 대표적인 기능

- 코딩

- 컴파일

- 디버깅

- 배포

 

 

 

 

 

3. 빌드 도구

(1) 소스 코드 파일들을 컴퓨터에서 실행할 수 있 는 제품 소프트웨어로 변환하는 과정 또는 결과물을 말 한다.

(2) 소스 코드를 소프트웨어로 변환하는 과정 에 필요한 전처리(Preprocessing), 컴파일(Compile) 등 의 작업들을 수행하는 소프트웨어를 말한다.

(3) 대표적인 도구로는 Ant, Maven, Gradle 등이 있다.

 

 

 

---

 

1. 소프트웨어 패키징의 개요

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

(2) 개발자가 아니라 사용자를 중심으로 진행한다.
(3) 소스 코드는 향후 관리를 고려하여 모듈화하여 패키징 한다.
(4) 사용자가 소프트웨어를 사용하게 될 환경을 이해하여, 다양한 환경에서 소프트웨어를 손쉽게 사용할 수 있도 록 일반적인 배포 형태로 패키징한다.

 

 

 

 

2. 패키징 시 고려사항

(1) 사용자의 시스템 환경, 즉 운영체제(OS), CPU, 메모리 등에 필요한 최소 환경을 정의한다.
(2) UI(User Interface)는 사용자가 눈으로 직접 확인할 수 있도록 시각적인 자료와 함께 제공하고 매뉴얼과 일치 시켜 패키징한다.
(3) 소프트웨어는 단순히 패키징하여 배포하는 것으로 끝 나는 것이 아니라 하드웨어와 함께 관리될 수 있도록 Managed Service 형태로 제공하는 것이 좋다.
(4) 사용자에게 배포되는 소프트웨어이므로 내부 콘텐츠에 대한 암호화 및 보안을 고려한다.
(5) 다른 여러 콘텐츠 및 단말기 간 DRM(디지털 저작권 관 리) 연동을 고려한다.
(6) 사용자의 편의성을 위한 복잡성 및 비효율성 문제를 고 려한다.

(7) 제품 소프트웨어 종류에 적합한 암호화 알고리즘을 적 용한다.

 

 

 

 

3. 릴리즈 노트(Release Note)

(1) 개발 과정에서 정리된 릴리즈 정보를 소프 트웨어의 최종 사용자인 고객과 공유하기 위한 문서이다.

(2) 릴리즈 노트를 통해 테스트 진행 방법에 대한 결과와 소프트웨어 사양에 대한 개발팀의 정확한 준수 여부를 확인할 수 있다.
(3) 소프트웨어에 포함된 전체 기능, 서비스의 내용, 개선 사항 등을 사용자와 공유할 수 있다.
(4) 릴리즈 노트를 이용해 소프트웨어의 버전 관리나 릴리 즈 정보를 체계적으로 관리할 수 있다.
(5) 릴리즈 노트는 소프트웨어의 초기 배포 시 또는 출시 후 개선 사항을 적용한 추가 배포 시에 제공한다.

 

 

 

 

4. 릴리즈 노트 초기 버전 작성 시 고려사항

(1) 릴리즈 노트는 정확하고 완전한 정보를 기반으로 개발 팀에서 직접 현재 시제로 작성해야 한다.
(2) 신규 소스, 빌드 등의 이력이 정확하게 관리되어 변경 또 는 개선된 항목에 대한 이력 정보들도 작성되어야 한다.
(3) 릴리즈 노트 작성에 대한 표준 형식은 없지만 일반적으 로 다음과 같은 항목이 포함된다.

 

---

 

1. 디지털 저작권 관리(DRM;Digital Right Management)

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

(2) 원본 콘텐츠가 아날로그인 경우에는 디지털로 변환한 후 패키저(Packager)에 의해 DRM 패키징을 수행한다.

(3) 콘텐츠의 크기에 따라 음원이나 문서와 같이 크기가 작 은 경우에는 사용자가 콘텐츠를 요청하는 시점에서 실 시간으로 패키징을 수행하고, 크기가 큰 경우에는 미리 패키징을 수행한 후 배포한다.
(4) 패키징을 수행하면 콘텐츠에는 암호화된 저작권자의 전자서명이 포함되고 저작권자가 설정한 라이선스 정 보가 클리어링 하우스(Clearing House)에 등록된다.

(5) 사용자가 콘텐츠를 사용하기 위해서는 클리어링 하우 스에 등록된 라이선스 정보를 통해 사용자 인증과 콘텐 츠 사용 권한 소유 여부를 확인받아야 한다.
(6) 종량제 방식을 적용한 소프트웨어의 경우 클리어링 하 우스를 통해 서비스의 실제 사용량을 측정하여 이용한 만큼의 요금을 부과한다.

 

 

 

 

 

2. 디지털 저작권 관리(DRM)의 구성 요소

(1) 클리어링 하우스(Clearing House) : 저작권에 대한 사용 권한, 라이선스 발급, 암호화된 키 관리, 사용량에 따른 결제 관리 등을 수행하는 곳

(2) 콘텐츠 제공자(Contents Provider)

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

(4) 콘텐츠 분배자(Contents Distributor)

(5) 콘텐츠 소비자(Customer)

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

 

 

 

 

 

3. 디지털 저작권 관리(DRM)의 기술 요소

(1) 암호화(Encryption)

(2) 키 관리(Key Management)

(3) 암호화 파일 생성(Packager)

(4) 식별 기술(Identification)

(5) 저작권 표현(Right Expression)

(6) 정책 관리(Policy Management)

(7) 크랙 방지(Tamper Resistance)

(8) 인증(Authentication)

 

 

 

 

4. 소프트웨어 설치 매뉴얼의 개요

(1) 설치 매뉴얼은 사용자 기준으로 작성한다.
(2) 설치 시작부터 완료할 때까지의 전 과정을 빠짐없이 순 서대로 설명한다.
(3) 설치 과정에서 표시될 수 있는 오류 메시지 및 예외 상 황에 관한 내용을 별도로 분류하여 설명한다.
(4) 소프트웨어 설치 매뉴얼에는 목차 및 개요, 서문, 기본 사항 등이 기본적으로 포함되어야 한다.
(5) 기능 식별 → UI 분류 → 설치 파일/백업 파일 확인 → Uninstall 절차 확인 → 이상 Case 확인 → 최종 매뉴 얼 적용

 

---

 

 

1. 소프트웨어 사용자 매뉴얼의 개요

(1) 사용자 매뉴얼은 사용자가 소프트웨어 사용에 필요한 절 차, 환경 등의 제반 사항이 모두 포함되도록 작성한다.

(2) 소프트웨어 배포 후 발생될 수 있는 오류에 대한 패치 나 기능에 대한 업그레이드를 위해 매뉴얼의 버전을 관 리한다.
(3) 개별적으로 동작이 가능한 컴포넌트 단위로 매뉴얼을 작성한다.
(4) 사용자 매뉴얼은 컴포넌트 명세서와 컴포넌트 구현 설 계서를 토대로 작성한다.
(5) 사용자 매뉴얼에는 목차 및 개요, 서문, 기본 사항 등이 기본적으로 포함되어야 한다.
(6) 작성 지침 정의 → 사용자 매뉴얼 구성 요소 정의 → 구 성 요소별 내용 작성 → 사용자 매뉴얼 검토

 

 

 

 

2. 소프트웨어 패키징의  형상 관리

(1) 형상 관리(SCM; Software Configuration Management) 는 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항 을 관리하기 위해 개발된 일련의 활동이다.

(2) 소프트웨어 변경의 원인을 알아내고 제어하며, 적절히 변경되고 있는지 확인하여 해당 담당자에게 통보한다.
(3) 형상 관리는 소프트웨어 개발의 전 단계에 적용되는 활 동이며, 유지보수 단계에서도 수행된다.
(4) 형상 관리는 소프트웨어 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 한다.
(5) 관리 항목에는 소스 코드뿐만 아니라 각종 정의서, 지 침서, 분석서 등이 포함된다.
(6) 형상 관리를 통해 가시성과 추적성을 보장함으로써 소 프트웨어의 생산성과 품질을 높일 수 있다.
(7) 대표적인 형상 관리 도구에는 Git, CVS, Subversion 등이 있다.

 

 

 

 

3. 형상 관리의 중요성

(1) 지속적인 소프트웨어의 변경 사항을 체계적으로 추적 하고 통제할 수 있다.
(2) 제품 소프트웨어에 대한 무절제한 변경을 방지할 수 있다.
(3) 제품 소프트웨어에서 발견된 버그나 수정 사항을 추적 할 수 있다.
(4) 소프트웨어는 형태가 없어 가시성이 결핍되므로 진행 정도를 확인하기 위한 기준으로 사용될 수 있다.
(5) 소프트웨어의 배포본을 효율적으로 관리할 수 있다.
(6) 소프트웨어를 여러 명의 개발자가 동시에 개발할 수 있다.