< 문제 >
1. 화이트박스 테스트(White Box Test)와 블랙박스 테스트(Black Box Test)
2. 탐색적 테스팅(Exploratory testing)
3. SW 안전성 분석 기법
4. Lehman 의 SW 변화원리
5. ISO/IEC 25000
6. 노코드(no-code)
7. 정보시스템 감리기준 고시(2021-4 호, 2021.1.19)에 의거한 현장감리의 활동, 작업내용을
기술하고 PMO(Project Management Office)와의 차이점을 설명
8. 객체지향 프로그래밍의 캡슐화(Ecapsulation)
9. 소프트웨어 결합도(Coupling)의 종류
10. 마이크로서비스 아키텍처(Microservice Architecture)
11. 데브옵스(DevOps)
12. 소프트웨어 형상관리
13. 소프트웨어 아키텍처 평가 모델
14. 요구명세(Software Requirement Specification)
15. 상용 소프트웨어 직접구매 제도
16. UML (Unified Modeling Language)
17. McCabe 의 회전 복잡도(Cyclomatic Complexity)
18. Information Hiding
19. ISO/IEC/IEEE 42010
20. 운영감리와 유지보수 사업 감리
21. 테스트 커버리지(Test Coverage)와 코드 커버리지(Coverage)
22. 오버라이딩(Overriding)으로 함수를 재정의 하는 이유
23. 기능점수(Function Point)의 간이법과 정통법
24. 코드스멜 종류와 리펙토링 방법을 설명하시오
25. ATAM(Architecture Trade-off Analysis Method)
26. 무중단 배포의 문제점
27. 객체지향 설계 원리
28. 공통감리 절차와 감리보고서
29. CMMi(Capability Maturity Model Integration) V2.0
30. 민간투자형 SW 사업
31. 오버로딩(Overloading)과 오버라이딩(Overriding)
32. 재공학(Re-engineering), 역공학(Reverse Engineering)
33. 요구공학 프로세스와 도출기법
< 목차 >
1. 화이트박스 테스트(White Box Test)와 블랙박스 테스트(Black Box Test)
문 1) 화이트 박스 테스트와 블랙박스 테스트
답)
Ⅰ. 화이트 박스 테스트와 블랙박스 테스트의 개요
가. 구조 기반 테스트, 화이트 박스 테스트의 개요
- 컴포넌트 혹은 소프트웨어 내부구조 분석에
바탕을 두고 Test Case를 도출하는 기법
* 구문 커버리지, 결정 커버리지
나. 명세 기반 테스트, 블랙 박스 테스트의 개요
- 프로그램 내부 구조를 고려하지 않고 요구사항
명세서를 통해 Test Case를 도출하는 기법
* 동등 클래스 분할, 경계값 분석
Ⅱ. 화이트 박스 테스트와 블랙박스 테스트의 배교
* 관점, 장점, 단점, 활용
2. 탐색적 테스팅(Exploratory testing)
문 2) 탐색적 테스팅
답)
Ⅰ. 휴리스틱 테스팅 기법, 탐색적 테스팅의 개요
- 전문가의 경험 및 지식을 활용하여 테스트케이스를
사전 작성하지 않고 자유롭게 테스트를수행하는 방법
Ⅱ. 탐색적 테스팅의 구성도 및 구성요소
가. 탐색적 테스팅의 구성도
* 각 테스터 마다 버그 발견 시간이 다름을 표현
테스트 차터, 테스트 노트 표현
나. 탐색적 테스팅의 구성요소
* 테스트 차터, 테스트 노트, 시간제한, 세션시트, 요약보고
Ⅲ. 탐색적 테스팅과 테스트케이스 기반 테스팅 비교
* 특징, 테스트 방법, 커뮤니케이션, 프로세스
3. SW 안전성 분석 기법
문 3) SW 안전성 분석 기법
답)
Ⅰ. SW 위험원 도출 및 제거를 위한 SW 안전성 분석 기법
- 설계, 개발, 평가 등 과정을 통해 SW결함을 사전
예방하고 안전피해 최소화를 위한 분석 기법
Ⅱ. SW 안전성 분석 기법의 유형
가. 시스템 요구분석/설계 단계
* 상세 위험원 도출(HAZOP, STPA)
* 위험 평가 및 분석(FMEA, FTA)
나. 시스템 개발/검토 단계
* 개발단계 (Whitebox, Black Box)
* 검토단계 (요구사항 검토, 코드 검토)
Ⅲ. 기능안전성 표준 준수를 통한 SW 안전성 확보 방안
* IEC61508 하단에 트리구조로,
ISO26262(자동차), ISO62304(의료), DO-178C(항공), IEC60880(원자력)
4. Lehman 의 SW 변화원리
문 4) 리먼(Lehman)의 SW 변화 원리
답)
Ⅰ. SW 변화관리와 유지보수 핵심 개념, 리먼의 SW변화원리
- 실제 세계의 지속적 변화에 대응하여 소프트웨어가
진화해야하며 소프트웨어의 복잡성 관리를 강조하는 원칙
Ⅱ. 리먼의 SW 변화원리 분류 및 상세설명
가. 리먼의 SW 변화원리 분류
* S-Type(정적유형), P-Type(실용적 유형), E-Type(진화적 유형)
나. 리먼의 SW 변화원리 상세설명 // 계자 조친 피지 증감
1. 계속적 변경
2. 자가 규제
3. 조직적 안정화
4. 친근성 유지
5. 피드백 시스템
6. 지속적 성장
7. 증가 복잡도
8. 감소하는 품질
Ⅲ. 리먼 SW 변화원리의 유지보수 적용방안
* 조직(People), 조직적 안정화 유지, 시스템
5. ISO/IEC 25000
문 5) ISO/IEC 25000
답)
Ⅰ. 품질 평가 방안에 대한 표준, ISO/IEC 25000의 개요
- SW 개발 공정의 산출 제품이 요구사항을 만족하는지
검증하기 위한 품질측정 모델, 측정기법 평가방안 국제표준
Ⅱ. ISO/IEC 25000의 Framwork 구조도 및 구성요소
가. ISO/IEC 25000의 Framework 구조도 //요모관측병
* SQuaRE 구조 / SQuaRE 기대효과
나. ISO/IEC 25000의 구성요소
* 품질요구(2503n), 품질모델(2501n), 품질관리(2500n), 품질측정(2502n), 품질평가(2504n), Extension
6. 노코드(no-code)
문 6) 노코드 (no-code)
답)
Ⅰ. 디지털 전환 촉진을 위한 접근, 노코드의 개요
- 프로그래밍 언어에 대한 지식과 직접 코딩 없이
애플리케이션을 설계하고 직접 개발하는 기법
Ⅱ. 노코드(no-code) 개발 프로세스와 개발 기법
가. 노코드(no-code) 개발 프로세스
* ← User Interface → ← UI Builder → ← Codeless platform →
나. 노코드(no-code) 개발 기법
* 목적(목적중심 개발)
개발시간(30배 이상 빠른 속도)
개발범위(소형 앱 위주)
개발도구(IDE Tool 중심)
플랫폼(IDE Tool 의존적)
숙련도(업무 이해도 필요)
Ⅱ. 노코드(no-code) 도입 시 고려사항
* 디지털 전환도구(앱 생명주기 지원, 사용자 경험 지원, 사용자 협업 지원)
* 비즈니스 환경(기존 환경과의 호환성, 보안성, 투자대비 수익률)
7. 정보시스템 감리기준 고시(2021-4 호, 2021.1.19)에 의거한 현장감리의 활동, 작업내용을
기술하고 PMO(Project Management Office)와의 차이점을 설명
8. 객체지향 프로그래밍의 캡슐화(Ecapsulation)
문 8) 객체지향 프로그래밍의 캡슐화
답)
Ⅰ. 정보은닉을 위한 설계 원리, 캡슐화의 정의
- 객체의 속성과 행위를 하나로 묶고 실제 구현
내용 일부를 감추어 은닉하는 객체지향 특성
Ⅱ. 캡슐화의 개념도 및 접근제어자
가. 캡슐화의 개념도
* 메소드(함수) 안에 속성(DATA)와 외부 정보가 메시지로 통신
나. 캡슐화의 접근제어자
* Class (Default, public), Method (Private, Default, Protected, Public)
Ⅲ. 캡슐화의 구현 예시
* public class BackAccount {
private int balance; // 외부 직접 접근 불가
public void deposit(int amount) {
balance += amount; // 함수를 통해 접근
}
}
9. 소프트웨어 결합도(Coupling)의 종류
문 9) 소프트웨어 결합도(Coupling)의 종류
답)
Ⅰ. 외부 모듈과의 연관도, 소프트웨어 결합도 정의
- 다른 모듈이나 클래스와 얼마나 밀접하게 연결이 되었는지
SW 구성요소 간의 상호의존성을 나타내는 지표
Ⅱ. 소프트웨어 결합도의 종류
가. 강한 결합도
* 내용결합, 공통결합, 외부결합, 제어결합, 스탬프 결합
나. 약한 결합도
* 자료결합, 메시지 결합
Ⅲ. 소프트웨어 모듈의 응집도 //우논시 절통순기
* 우연적, 논리적, 시간적, 절차적, 통신적, 순차적, 기능적
10. 마이크로서비스 아키텍처(Microservice Architecture)
문 10) MSA (Microservice Architecture)
답)
Ⅰ. 서비스의 분할과 결합, MSA의 정의
- 소프트웨어 응용 프로그램을 독립적으로 배치 가능한
서비스 단위로 분리하고 이들의 조합으로 구성하는 아키텍처
Ⅱ. MSA의 구성도 및 기술요소
가. MSA의 구성도
* UI Layer, API Gateway Layer, Biz Logic Layer, DB Layer
나. MSA의 기술요소
* UI(웹서버, 모빌리티), 개발(HTML5, CSS3), API Gateway(Restful, Webservice),
Service(Fine Grained, Loosely Coupled)
Ⅲ. 실무기반 MSA 구축환경 최적화 방안
* 서비스, 조직
11. 데브옵스(DevOps)
문 11) 데브옵스(DevOps)
답)
Ⅰ. 개발과 상호의존적 대응 개발론, DevOps의 개요
- 시스템 개발자와 운영을 담당하는 정보기술 전문가
사이의 소통, 협업, 통합, 자동화 강조하는 개발방법론
Ⅱ. DevOps 개념도 및 구성요소
가. DevOps 개념도
* Dev와 OPS를 뫼비우스띄 처럼 구성
나. DevOps 구성요소
* 품질(품질기준, 테스트 자동화),
프로세스(사이클타임 축소, 완료시점 범위 확장, 지속 출시, 릴리즈와 배포의 분리),
도구(지속통합, 릴리즈 자동화, 프로비저닝)
Ⅲ. 애자일(Agile) 방법론과 데브옵스(DevOps) 비교
* 개념도, 개념, 목적
12. 소프트웨어 형상관리
문 12) 소프트웨어 형상관리
답)
Ⅰ. SDLC의 가시성과 추적성 확보, SW형상관리 개요
- 형상항목을 식벽하여 기능적, 물리적 특성을 문서화하고
특성에 대한 변경을 제어하고 검증하는 감시 활동
Ⅱ. 소프트웨어 형상관리의 구성도 및 형상관리 절차
가. 소프트웨어 형상관리의 구성도 // 식통감기
* 형상관리기법(형상식별, 형상통제, 형상감사, 형상기록)
형상항목, BaseLine, Configuration Management System ↔ Repo (SVN, GitHub, ..)
형상관리통제위원회(CCB) ↔ 변경 허용, 변경 실시
나. 형상관리 절차
* 형상관리 준비, 형상식별, 형상통제, 형상감사, 형상기록
Ⅲ. SDLC와 SW 형상관리의 단계별 기준선
* 계획단계 ↔ 기능적 기준선
요구분석 단계 ↔ 분배적 기준선
설계 단계 ↔ 설계 기준선
구현 단계 ↔ 시험 기준선
통합, 시험단계 ↔ 제품 기준선
설치, 운영단계 ↔ 운용 기준선
13. 소프트웨어 아키텍처 평가 모델
문 13) SW Architecture 평가모델
답)
Ⅰ. 아키텍처 설계의 검증 방법론, 평가모델의 개요
- SW Architecture 접근법이 품질 속성에 미치는
영향을 판단하고 아키텍처 적합성을 평가하는 모델
Ⅱ. SW Architecture 평가모델의 관계도 및 상세설명
가. SW Architecture 평가모델의 관계도
* SAAM ↔ ATAM ↔ ADR
EATM ↔ CBAM ↔ ARID
←시나리오 기반→ ←설계/혼합 기반→
나. SW Architecture 평가모델의 상세설명
* 시나리오 기반 평가모델(SAAM, ATAM, CBAM, EATM)
설계/혼합 기반 평가모델(ADR, ARID)
Ⅲ. SW Architecture 평가 기대효과 및 판단 시 고려사항
* 기대효과 (금전적 이익, 논리적 근거 파악)
고려사항 (평가 원칙, 복잡성 관리)
14. 요구명세(Software Requirement Specification)
문 14)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
15. 상용 소프트웨어 직접 구매 제도
문 15) 상용 소프트웨어 직접 구매 제도
답)
Ⅰ. 상용 소프트웨어 직접 구매 제도 개요
- 공공 정보화 사업 추진 시 H/W, S/W 통합 구축 사업에서
상용SW만을 별도로 발주, 평가, 선정하여 구매하는 제도
Ⅱ. 상용 소프트웨어 직접 구매 대상 및 제외 기준
가. 상용 소프트웨어 직접 구매 대상 사업 조건
* 1차 조건 : 총 사업 규모 3억원 이상
2차 조건 : 조달청 홈페이지 등록 SW
5천만원 이상 SW
국가정보원 검증/지정 SW
* 근거 : S/W 계약 및 관리 감독에 관한 지침 제 7조
나. 상용 SW 직접 구매 제외 기준
* 대상사업 (민간투자형 SW 사업)
대상SW(현저한 비용상승, 정보시스템 통합불가, 현저한 사업기간 지연, 비효율적 판단)
Ⅲ. 상용 SW 직접 구매 제도 활성화 방안
* 직접 구매를 위한 추가 업무 가중, 통합사업자와 상용SW 납품사업자간 업무범위 불명확
16. UML (Unified Modeling Language)
문 16)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
17. McCabe 의 회전 복잡도(Cyclomatic Complexity)
문 17) McCabe의 회전 복잡도
답)
Ⅰ. 대표적인 SW 복잡도 측정 매트릭스, McCave 회전복잡도
- 소프트웨어 제어흐름 그래프를 통해 회전 수를
구하여 소프트웨어의 복잡도를 정량적으로 나타낸 지표
Ⅱ. McCabe의 회전복잡도 측정요소와 측정기법
가. McCabe의 회전복잡도 측정요소
* 그래프 요소(Node, Edge), 제어 흐름(Sequence, while, do~while/until, If-else)
나. McCabe의 회전복잡도 측정기법
* 복잡도=폐구간+1, 복잡도=Edge-Node+2, 복잡도=의사결정수+1
Ⅲ. McCave의 회전복잡도 분석
* 5이하(매우간단), 5~10(안정적, 구조적), 20이상(매우 복잡, 필요이상 결정문)
18. Information Hiding
문 18)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
19. ISO/IEC/IEEE 42010
문 19)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
20. 운영감리와 유지보수 사업 감리
문 20)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
21. 테스트 커버리지(Test Coverage)와 코드 커버리지(Coverage)
문 21)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
22. 오버라이딩(Overriding)으로 함수를 재정의 하는 이유
문 22)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
23. 기능점수(Function Point)의 간이법과 정통법
문 23)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
24. 코드스멜 종류와 리펙토링 방법을 설명하시오
문 24)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
25. ATAM(Architecture Trade-off Analysis Method)
문 25)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
26. 무중단 배포의 문제점
문 26)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
27. 객체지향 설계 원리
문 27)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
28. 공통감리 절차와 감리보고서
문 28)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
29. CMMi(Capability Maturity Model Integration) V2.0
문 29)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
30. 민간투자형 SW 사업
문 30)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
31. 오버로딩(Overloading)과 오버라이딩(Overriding)
문 31)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
32. 재공학(Re-engineering), 역공학(Reverse Engineering)
문 32)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.
33. 요구공학 프로세스와 도출기법
문 33)
답)
Ⅰ.
Ⅱ.
가.
나.
Ⅲ.