정보처리기사 실기 문제 정리 240310

03. 현행 시스템 파악

 

1. 현행 시스템 분석의 정의, 목적

 -> 정의 : 현행 시스템이 어떤 하위 시스템으로 구성되어 있는지 파악하는 절차 의미. 현행 시스템의 제공 기능과 타 시스템과의 정보를 교환하여 분석하고 파악하는 시스템

 목적 : 현행 시스템의 기술 요소와 소프트웨어, 하드웨어를 파악. 개발 시스템의 개발 범위를 확인하고 이행 방향성 설정

 

2. 다음이 설명하는 것

 - 시스템 내 상위 시스템과 하위 시스템들이 어떤 관계로 상호작용하는지 각각 동작 원리, 구성을 표현한 것

 - 단위 업무별로 이것이 다른 경우 핵심 기간 업무 처리 시스템을 기준으로 함

 - 시스템의 전체 구조, 행위, 그리고 행위 원리를 나타내며 시스템이 어떻게 작동하는지 설명하는 틀

 -> 시스템 아키텍처

 

3. 현행 시스템 파악 절차 중 ( )

 - 1단계 : 시스템 구성 파악 -> 시스템 기능 파악 -> 시스템 인터페이스 현황 파악

 - 2단계 : ( ) -> 소프트웨어 구성파악

 - 3단계 : 시스템 하드웨어 현황 파악 -> 네트워크 구성 파악

 -> 아키텍처 파악

 

04. 개발 기술 환경 분석

 

1. 다음이 설명하는 것

 - 다양한 애플리케이션이 작동하는 기본이 되는 운영체제 소프트웨어 의미

 - '응용 소프트웨어 + 하드웨어 + 시스템 소프트웨어'로 구성

 -> 플랫폼(Platform)

 

2. 플랫폼 성능 특성 분석 항목 3가지

 -> 응답시간(Response Time), 가용성(Availability), 사용률(Utilization)

 

3. DBMS 분석 시 고려사항 중 다음 설명에 해당하는 고려사항

 - 장시간 DBMS 운영 시 장애 발생 가능성

 - DBMS 패치 설치를 위한 재기동 시간

 - DBMS 이중화 및 복제 지원, 백업 및 복구 편의성

 -> 가용성

 

4. 다음이 설명하는 것 명칭

 - 운영체제와 소프트웨어 애플리케이션 사이에 위치

 - 애플리케이션에 운영체제가 제공하는 서비스를 추가 및 확장하여 제공하는 컴퓨터 소프트웨어

 - 대표적으로 웹 애플리케이션 서버(WAS, Web Application Server)가 있음

 -> 미들웨어(Middleware)

 

CHAPTER 02. 요구사항 확인하기

01. 요구사항 개발

1. 소프트웨어 개발 과정 중 요구사항 확인 단계의 요구사항의 타당성 검증 사항에서 다음에 해당되는 요구조건

 - 사용자의 요구를 에러 없이 완전하게 반영하고 있는가?

-> 무결성(correctness), 완전성(completeness)

 

2. 애플리케이션 개발 단계에서 도출되는 프로그램, 문서, 데이터 등의 모든 자료를 형상 단위라고 하며, 이러한 자료의 변경을 관리함으로써 애플리케이션 버전 관리 등을 하는 활동

-> 형상관리(Configuration Management)

 

3. 애플리케이션 개발 단계에서 요구사항을 분석한 뒤 요구사항을 명세하는 명세 3종류

-> 시스템 정의서, 시스템 요구사항 명세서, 소프트웨어 요구사항 명세서

 

4. 요구사항의 타당성 검증 사항 중 추적 가능성에 대해 서술

-> 시스템 요구사항과. 시스템 설계 문서를 추적할 수 있는 정도를 의미한다.

 

5. 요구사항 개발 프로세스 중 가장 먼저 진행해야 할 단계

-> 요구사항 도출(Elicitation)

 

02. 요구사항 관리

1. 소프트웨어의 생성부터 소멸까지의 정의 단계, 개발 단계, 유지보수 단계로 구분한 요구사항 관리 절차

-> SDLC(Software Development Life Cycle, 소프트웨어 생명주기)

 

2 CMMi 5단계

-> 초기-관리-정의-정량적 관리-최적화

 

3. 다음은 무엇에 관한 내용

 - 구문(Syntax)과 형식적으로 정의된 의미(Semantics)를 지닌 언어로 요구사항을 표현

 - 정확하고 명확하게 표현하여 오해를 최소화

 - 요구사항 분석의 마지막 단계에서 이루어짐

->  정형 분석(Formal Analysis)

 

4. 다음 내용에 해당하는 애플리케이션 개발 단계

 - 사용자 측 관점에서 소프트웨어가 요구사항을 충족시키는지 평가하는 절차

 - 소프트웨어가 고객의 합리적인 기대에 따라 제 기능을 발휘하는지 여부 테스트

 - 인수 시 각 요구사항의 확인 절차를 계획

-> 인수 테스트

 

 

Chapter 03. 분석 모델 확인하기

01. 분석(참고)모델

1. 프로세스 마이닝의 가장 기본이 되는 프로세스 모델로, 가장 간단한 형태로 프로세스를 나타낼 수 있는 도구

-> Petri-Net

 

2. 다음이 설명하는 분석 모델

 - 사용자의 요구분석 사항을 파악하기 위하여 자료의 흐름과 가공 절차를 그림 중심으로 표현하는 방법

 - 하향식(Top-Down Partitioning) 원리를 적용

 - 사용자의 업무 요구사항을 쉽게 문서화하여 사용자와 분석자 간의 의사소통을 위한 공용어이며 실체의 모형(추상적 표현)을 추출

-> 구조적 분석 모델

 

3. 자료 사전 표기법 중 자료의 선택(택일)을 표현하는 기호

-> [ | ]

 

02. 객체지향 분석 모델

1. 다음 내용이 설명하는 객체지향 설계 원칙

 - 클라이언트는 자신이 사용하지 않는 메소드와 의존 관계를 맺으면 안 됨

 - 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안 됨

-> 인터페이스 분리 원칙(ISP : Interface Segregation Principle)

 

2. 객체지향 설계 원칙 중, 서브 타입(상속받은 하위 클래스)은 어디에서나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 함을 의미하는 원칙

-> 리스코프 치환 원칙

 

3. 객체지향 기법에서 클래스들 사이의 '부분전체(part-whole)' 관계 또는 '부분(is-part-of)'의 관계로 설명되는 연관성을 나타내는 용어

-> 집단화(Aggregation)

 

03. 분석 모델 검증

1. 다음 분석 모델 검증 절차에서 빈칸에 알맞은 절차

( )

스테레오 타입

경계 및 제어 클래스 도출

관계 및 상세화 정도

-> 분석 클래스 검증

 

2. 다음 분석 클래스의 스테레오 타입에서 빈칸에 알맞은 클래스 유형

( ) 내용 : 액터와의 상호작용을 제공하는 클래스

-> 경계 클래스

 

3. 다음이 설명하는 도구

 - 요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발된 도구

 - 소프트웨어 개발과정 일부 또는 전체를 자동화하기 위한 도구

 - 계획 수립에서부터 요구분석, 설계, 개발, 유지보수에 이르는 소프트웨어 생명주기의 모든 과정을 자동화하도록 지원

-> CASE(Computer Aided Software Engineering)

 

04. 개념 모델링

1. 요구사항을 이해하기 쉽도록 실세계의 상황을 단순화하여 개념적으로 표현한 것을 모델이라고 하고, 이렇게 표현된 모델을 생성해 나가는 과정을 의미하는 것

-> 개념 모델링

 

2. Use Case Diagram 작성 단계 중 다음 설명에 해당하는 단계

 - 모든 사용자 역할을 식별

 - 상호작용하는 타 시스템 식별

 - 정보를 주고받는 하드웨어 및 지능형 장치를 식별

-> 액터 식별

 

3. Use Case Diagram 요소 중 다음 설명에 해당하는 요소

 - 시스템이 제공해야 하는 사례(Use Case)들의 범위가 됨

 - 큰 규모의 객체로 구현되는 존재

-> 시스템 경계

 

4. UML 관계 중 부분 객체가 전체 객체에 속하는 강한 집합 연관의 관계를 표현하는 클래스이며, '부분' 객체를 다른 객체와 공유 불가하고, '전체' 객체 방향에 채워진 마름모로 표시한 관계

-> UML 포함 관계(Composition Relation)

 

05. 디자인 패턴

1. 디자인 패턴 구조 중 다음이 설명하는 것

 - 패턴이 적용되어 해결될 필요가 있다는 여러 디자인 이슈들을 작성

 - 여러 제약 사항과 영향력도 문제 해결을 위해 고려

-> 문제

 

2. 반복적으로 사용되는 객체들의 상호작용을 패턴화한 것으로, 클래스나 객체들이 상호작용하는 방법과 책임을 분산하는 방법을 정의하는 디자인 패턴

-> 행위 패턴

 

3. 다음 디자인 패턴 중 구조 패턴이 아닌 것

 - Adapter, Brigdge, Composite, Template Method, Visitor, Decorator

-> Template Method, Visitor

 

4. 생성 패턴 중 다음이 설명하는 패턴

 - 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 함

 - 생성된 객체를 어디에서든지 참조할 수 있도록 함

-> Singleton