[정보처리기사] 필기 - 소프트웨어 개발(2)

⎮ 형상 관리

 소프트웨어 개발 생명주기 전반에 걸쳐 생성되는 소스 코드와 문서 등과 같은 산출물의 합 및 변경 과정을 체계적으로

관리하고 유지하는 일련의 개발 관리 활동.

 '구성 관리(Softward Configuration Management)'라고 하며, 소프트웨어에 가시성과 추적 가능성을 부여하여

제품의 품질과 안전성 높임

 형상 관리를 위해 구성된 팀은 '형상 통제 위원회(CCB : Configuration Control Board)'로 형상 항목의 변경을 수락 또는

거절하는 책임을 짐.

 이전 리비전이나 버전에 대한 정보에 접근 가능하여 배포본 관리에 유용

 불필요한 사용자의 소스 수정을 제한할 수 있음

 동일한 프로젝트에 대해 여러 개발자 동시 개발이 가능.

 - 형상 관리 도구 : CVS, SVN(Subversion), Git

 - 대표적인 소프트웨어 형상 항목

    프로젝트 요구 분석서

    운영 및 설치 지침서

    요구사항 명세서

    설계/인터페이스 명세서

    테스트 설계서

    소프트웨어 품질 보증

    형상 관리

    V&V 계획서와 같은 계획서

    코드 모듈(소스와 오브젝트 모두)

1. 소프트웨어 형상 관리에 대한 설명으로 거리가 먼 것은?
① 소프트웨어에 가해지는 변경을 제어하고 관리한다.
② 프로젝트 계획, 분석서, 설계서, 프로그램, 테스트 케이스 모두 관리 대상이다.
③ 대표적인 형상관리 도구로 Ant, Maven, Gradle 등이 있다.
④ 유지 보수 단계뿐 아니라 개발 단계에도 적용할 수 있다.
-> Ant, Maven, Gradle은 Build 도구

2. 형상 관리의 개념과 절차에 대한 설명으로 틀린 것은?
① 형상 식별은 형상 관리 계획을 근거로 형상 관리의 대상이 무엇인지 식별하는 과정이다.
② 형상 관리를 통해 가시성과 추적성을 보장함으로써 소프트웨어의 생산성과 품질을 높일 수 있다.
③ 형상 통제 과정에서는 형상 목록의 변경 요구를 즉시 수용 및 반영해야 한다.
④ 형상 감사는 형상 관리 계획대로 형상 관리가 진행되고 있는지, 형상 항목의 변경이 요구사항에 맞도록
     제대로 이루어졌는지 등을 살펴보는 활동이다.

3. 소프트웨어 형상 관리에서 관리 항목에 포함되지 않는 것은?
① 프로젝트 요구 분석서
② 소스 코드
③ 운영 및 설치 지침서
④ 프로젝트 개발 비용

 

⎮ 애플리케이션 패키징

 

  일련의 배포용 설치 파일을 만드는 작업(개발이 완료된 소프트웨어를 고객에 인도하기 위해 패키징하고, 설치 매뉴얼, 

사용 매뉴얼 등을 작성하는 작업)

 향후 관리 편의성을 위해 모듈화하여 패키징

 사용자를 중심으로 진행하며, 사용자의 다양한 환경에서 설치할 수 있도록 패키징

 사용자의 불편함을 줄이고 사용자의 편의성을 먼저 고려.

 패키징시 주의사항 : 전체 내용을 포함, 고객 중심, 모듈화, 버전 관리 및 릴리즈 노트 관리

 - 패키징 도구 활용 시 고려 사항

    제품 SW 종류에 적합한 암호화 알고리즘 적용

    패키징 도구를 활용하여 여러가지 이기종 콘텐츠 및 단말기간 DRM 연동을 고려

    사용자에게 배포되는 소프트웨어임을 고려, 반드시 내부 콘텐츠에 대한 암호화 및 보안을 고려 

1. 소프트웨어 패키징에 대한 설명으로 틀린 것은?
① 패키징은 개발자 중심으로 진행한다.
② 신규 및 변경 개발 소스를 식별하고, 이를 모듈화하여 상용 제품으로 패키징한다.
③ 고객의 편의성을 위해 매뉴얼 및 버전 관리를 지속적으로 한다.
④ 범용 환경에서 사용할 수 있도록 일반적인 배포 형태로 패키징이 진행된다.
-> 패키징은 사용자 중심

2. 소프트웨어 패키징 도구 활용 시 고려 사항으로 틀린 것은?
① 반드시 내부 콘텐츠에 대한 암호화 및 보안을 고려한다.
② 보안을 위하여 이기종 연동을 고려하지 않아도 된다.
③ 사용자 편의성을 위한 복잡성 및 비효율성 문제를 고려한다.
④ 제품 소프트웨어 종류에 적합한 암호화 알고리즘을 적용한다.
-> 패키징 도구를 활용하여 여러가지 이기종 콘텐츠 및 단말기간 DRM 연동을 고려

 

 

⎮ DRM

 디지털 콘텐츠의 지식재산권 보호, 관리 기능 및 안전한 유통과 배포를 보장하는 솔루션

 - DRM 기술 요소

    사용 규칙 제어 기술 : 콘텐츠 식별 체계, 메타 데이터, 권리 표현 기술

    저작권 보호 기술 : 암호화(Encryption), 키 관리(Key Management), 암호화 파일 생성(Packager),

    식별 기술(Identification), 저작권 표현(Right Expression), 정책 관리(Policy Management),

    크랙 방지(Tamper Resistance), 인증(Authentication), 인터페이스(Interface), 이벤트 보고(Event Reporting),

    사용 권한(Permission)

  - DRM 구성 요소

    콘텐츠 제공자(Contents Provider) : 콘텐츠를 제공하는 저작권자

    콘텐츠 분배자(Contents Distributor) : 쇼핑몰 등으로써 암호화된 콘텐츠 제공

    패키저(Packager) : 콘텐츠를 메타 데이터와 함께 배포할 수 있는 단위로 묶는 기능

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

     DRM 컨트롤러 : 배포된 콘텐츠의 이용 권한을 통제

     클리어링 하우스(Clearing House) : 키 관리 및 라이센스 발급 관리

1. 디지털 저작권 관리(DRM) 기술과 거리가 먼 것은?
① 콘텐츠 암호화 및 키 관리
② 콘텐츠 식별 체계 표현
③ 콘텐츠 오류 감지 및 복구
④ 라이선스 발급 및 관리
-> 디지털 콘텐츠는 이미 개발이 된 상황이고, 오류 감지 및 복구는 개발할 때 확인하는 일.

2. 디지털 저작권 관리(DRM) 구성 요소가 아닌 것은?
① Data Warehouse
② DRM Controller
③ Packager
④ Contents Distributor

 

⎮ 소프트웨어 테스트의 원리

 - 결함 집중(Defect Clustering) : '파레토 법칙'이 좌우함.

    애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재 

    결함은 발생한 모듈에서 계속 추가로 발생할 가능성이 큼.

- 살충제 패러독스(Pesticide Paradox) : 동일한 테스트 케이스로 반복 테스트 시 어느 시점부터 더 이상 결함을 발견할 수

  없으므로 주기적으로 테스트 케이스를 리뷰하고 개선해야 함.

1. 다음 설명의 소프트웨어 테스트의 기본 원칙은?

- 파레토 법칙이 좌우한다. - 애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재한다. - 결함은 발생한 모듈에서 계속 추가로 발생할 가능성이 높다.

① 살충제 패러독스
② 결함 집중
③ 오류 부재의 궤변
④ 완벽한 테스팅은 불가능

 

⎮ SW 테스트

 - 테스트 단계(V-모델)

   Perry에 의해 제안된 개발 작업과 검증 작업 사이의 관계를 명확히 들어내 놓은 폭포수 모델의 변형

   폭포수 모델이 산출물 중심이라면, V모델은 작업과 결과의 검증에 초점을 둠

   테스트 레벨 : 단위 테스트 → 통합 테스트 → 시스템 테스트 → 인수 테스트

 

⎮ 통합 테스트

 - 통합 테스트 : 단위 테스트를 통과한 개발 소프트웨어/하드웨어 컴포넌트 간 인터페이스 및 연동 기능 등을

    구조적으로  접근하여 테스트

 - 시각에 따른 테스트

    검증(Verification) 테스트 : 개발자의 시각에서 제품의 생산 과정을 테스트하는 것

                                              (제품이 명세서대로 완성되었는지 검증하는 단계)

    확인(Validation) 테스트 : 사용자의 요구사항을 잘 수행하고 있는지, 사용자의 시각에서 제품의 결과를 테스트

1. 통합 테스트(Integration Test)와 관련한 설명으로 틀린 것은?
① 시스템을 구성하는 모듈의 인터페이스와 결합을 테스트하는 것이다.
② 하향식 통합 테스트의 경우 너비 우선(Breadth First) 방식으로 테스트를 할 모듈을 선택할 수 있다.
③ 상향식 통합 테스트의 경우 시스템 구조도의 최상위에 있는 모듈을 먼저 구현하고 테스트한다.
④ 모듈 간의 인터페이스와 시스템의 동작이 정상적으로 잘 되고 있는지를 빨리 파악하고자 할 때는 상향식보다는
하향식 통합 테스트를 사용하는 것이 좋다.
-> 최하위에서 위로 가는 것이 상향식 통합 테스트

2. 소프트웨어 테스트에서 검증(Verification)과 확인(Validation)에 대한 설명으로 틀린 것은?
① 소프트웨어 테스트에서 검증과 확인을 구별하면 찾고자 하는 결함 유형을 명확하게 하는데 도움이 된다.
② 검증은 소프트웨어 개발 과정을 테스트하는 것이고, 확인은 소프트웨어 결과를 테스트하는 것이다.
③ 검증은 작업 제품이 요구 명세의 기능, 비기능 요구사항을 얼마나 잘 준수하는지 측정하는 작업이다.
④ 검증은 작업 제품이 사용자의 요구에 적합한지 측정하며, 확인은 작업 제품이 개발자의 기대를 충족시키는지를 
측정한다.

 

⎮ 통합테스트 - 테스트 스텁과 테스트

 - Test Stub (위에서 밑으로)

   상위 모듈에서 하위 모듈 방향으로 통합 테스트를 진행하는 하향식 테스트에서 사용

   상위 모듈에서 하위 모듈로의 테스트를 진행하는 과정 중 하위 시스템 컴포넌트의 개발이 완료되지 않은 상황에서 사용

   테스트를 진행하기 위하여 임시로 생성된 가상의 더미 컴포넌트(Dummy Component).

 

 - Test Driver (밑에서 위로)

   하위 모듈에서 상위 모듈로 통합하면서 테스트하는 상향식 테스트에서 사용

   테스트할 소프트웨어 또는 시스템을 제어하고 동작시키는데 사용되는 도구를 의미

   시스템이나 시스템 컴포넌트를 시험하는 환경 일부분으로 시험을 지원하는 목적 하에 생성된 코드와 데이터

1. 하향식 통합에 있어서 모듈 간의 통합 시험을 위해 일시적으로 필요한 조건만을 가지고 임시로 제공되는 시험용 모듈을 무엇이라고 하는가?
① Stub
② Driver
③ Procedure
④ Function

2. 테스트 드라이버(Test Driver)에 대한 설명으로 틀린 것은?
① 시험 대상 모듈을 호출하는 간이 소프트웨어이다.
② 필요에 따라 매개 변수를 전달하고 모듈을 수행한 후의 결과를 보여줄 수 있다.
③ 상향식 통합 테스트에서 사용된다.
④ 테스트 대상 모듈이 호출하는 하위 모듈의 역할을 한다.

 

⎮ 인수 테스트

 일반적인 테스트 레벨의 가장 마지막 상위 레벨. SW제품에 대한 요구사항이 제대로 이행되었는지 확인하는 단계

 테스팅 환경을 실사용자 환경에서 진행하며 수행하는 주체가 사용자

 알파, 베타 테스트와 가장 밀접한 연관이 있음

 - 알파 테스트 : 베타 테스트 전에 프로그램 개발 시 내부에서 미리 평가하고 버그를 찾아 수정하기 위해 검사

 - 베타 테스트 : 정식으로 프로그램을 공개하기 전에 한정된 집단 또는 일반인에게 공개하여 기능을 시험하는 검사

1. 필드 테스팅(Field Testing)이라고도 불리며 개발자 없이 고객의 사용 환경에 소프트웨어를 설치하여
검사를 수행하는 인수 검사 기법은?
① 베타 검사
② 알파 검사
③ 형상 검사
④ 복구 검사
-> 최하위에서 위로 가는 것이 상향식 통합 테스트

2. 검증 검사 기법 중 개발자의 장소에서 사용자가 개발자 앞에서 행하는 기법이며, 일반적으로 통제된 환경에서
사용자와 개발자가 함께 확인하면서 수행되는 검사는?
① 동치 분할 검사
② 형상 검사
③ 알파 검사
④ 베타 검사

 

 

⎮ 테스트 케이스

 테스트 케이스 : 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지 확인하기 위해 설계된 입력값,

 실행조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서

 테스트의 목표 및 방법을 결정하고 테스트 케이스를 작성

 테스트 케이스 자동 생성

 자료 흐름도 → 테스트 경로 관리

 입력 도메인 분석  → 테스트 데이터 산출

 랜덤 테스트  → 무작위 값 입력, 신뢰성 검사

1. 테스트 케이스와 관련한 설명으로 틀린 것은?
① 테스트의 목표 및 테스트 방법을 결정하기 전에 테스트 케이스를 작성해야 한다.
② 프로그램에 결합이 있더라도 입력에 대해 정상적인 결과를 낼 수 있기 때문에 결함을 검사할 수 있는
테스트 케이스를 찾는 것이 중요하다.
③ 개발된 서비스가 정의된 요구사항을 준수하는지 확인하기 위한 입력값과 실행 조건, 예상 결과의 집합으로 볼 수 있다.
④ 테스트 케이스 실행이 통과되었는지 실패하였는지 판단하기 위한 기준을 '테스트 오라클(Test Oracle)'이라고
한다.
-> 테스트의 목표 및 방법을 결정한 다음 테스트 케이스 작성

2. 테스트 케이스 자동 생성 도구를 이용하여 테스트 데이터를 찾아내는 방법이 아닌 것은?
① 스터브(Stub)와 드라이버(Driver)
② 입력 도메인 분석
③ 랜덤(Random) 테스트
④ 자료 흐름도
-> 스터브와 드라이버는 통합 테스트

 

⎮ 알고리즘 순환 복잡도

 - 알고리즘 순환 복잡도

구 분	설 명
O(1)	상수 시간의 복잡도를 의미. 입력 값 n이 주어졌을 때, 문제를 해결하는 데 오직 한 단계만 거침(해시 함수)
O(log₂n)	로그 시간의 복잡도를 의미. 입력 값 n이 주어졌을 때, 문제를 해결하는 데 필요한 단계들이 연산마다 특정 요인에 의해 줄어듦(이진 탐색)
O(nlog₂n)	선형 로그 시간의 복잡도를 의미. 문제 해결을 위한 단계수는 nlog₂n번의 수행 시간을 갖음(퀵 정렬, 병합(합병) 정렬)
O(n)	선형 시간의 복잡도를 의미. 문제를 해결하기 위한 단계의 수와 입력값 n이 1 : 1 관계(순차 탐색)
O(n²)	제곱 시간의 복잡도를 의미. 문제를 해결하기 위한 단계의 수는 입력값 n의 제곱근(버블 정렬, 삽입 정렬, 선택 정렬)
O(Cⁿ)	지수 시간의 복잡도를 의미. 문제를 해결하기 위한 단계의 수는 주어진 상수값 C의 n제곱

1. 정렬된 n개의 데이터를 처리하는데 (nlog₂n)의 시간이 소요되는 정렬 알고리즘은?
① 선택 정렬
② 삽입 정렬
③ 버블 정렬
④ 합병 정렬

2. 알고리즘 시간 복잡도 O(1)이 의미하는 것은?
① 컴퓨터 처리가 불가
② 알고리즘 입력 데이터 수가 1개
③ 알고리즘 수행 시간이 입력 데이터 수와 관계없이 일정
④ 알고리즘 길이가 입력 데이터보다 작음

 

⎮ 소스 코드 최적화

 - 클린 코드(Clean Code) : 깔끔하게 잘 정리된 코드

    중복 코드 제거로 애플리케이션의 설계가 개선

    가독성이 높아짐.

    버그를 찾기 쉬워지며, 프로그래밍 속도가 빨라짐

 

 - 외계인 코드(Alien Code)

    아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램을 의미

 

 - 소스 코드 품질 분석 기법

구 분	설명
정적 분석 도구	소프트웨어를 분석하는 방법의 하나.  소프트웨어를 실행하지 않고 코드 레벨에서 분석하는 방법  - 종류 : pmd, cppcheck, checkstyle, FindBugs
동적 분석 도구	애플리케이션을 실행하여 코드에 존재하는 메모리 누수 현황을 발견. 발생한 스레드의 결함 등을 분석하기 위한 도구 - 종류 : Avalanche, Valgrind, ValMeter

1. 클린 코드(Clean Code)를 작성하기 위한 원칙으로 틀린 것은?
① 추상화 : 하위 클래스/메소드/함수를 통해 애플리케이션의 특성을 간략하게 나타내고, 상세 내용은 상위 클래스/
메소드/함수에서 구현한다.
② 의존성 : 다른 모듈에 미치는 영향을 최소화하도록 작성한다
③ 가독성 : 누구든지 읽기 쉽게 코드를 작성한다.
④ 중복성 : 중복을 최소화할 수 있는 코드를 작성한다.
-> 상위 클래스를 추상화하고, 상세 내용은 하위 클래스에서 구현

2. 소스 코드 품질 분석 도구 중 정적 분석 도구가 아닌 것은?
① pmd
② cppcheck
③ valMeter
④ checkstyle
-> valMeter는 동적 분석 도구